Seccomp Filters Should Validate Architecture Before Checking Syscall Numbers

A seccomp policy can appear complete yet leave an alternate syscall path open, because filters see only a syscall number and architecture identifier rather than semantic function names. The same integer can mean different things under different ABIs, so a policy checking only the syscall number can be bypassed. Architecture validation should therefore occur at the start of the filter, as shown in Linux seccomp(2) documentation, with unknown architectures rejected. The article recommends choosing default actions matching the risk level, maintaining separate filters and tests for each ABI, and failing closed when instructions cannot be classified. Seccomp is also limited because it cannot inspect pointer contents, so it is usually paired with namespaces, file permissions, and capabilities.