Automated seccomp filters for containers strengthen runtime containment

At a glance

What this is: This guest post explains how Seccomp-BPF can restrict container syscalls and how CI can automate filter generation from tested application behavior.

Why it matters: For IAM and NHI practitioners, syscall whitelisting is a runtime containment control that limits blast radius after an application or workload is exploited.

By the numbers:

• There are around 400 syscalls available in the Linux kernel, and even a basic Hello World program written in C makes 2 of them.

👉 Read GitGuardian's walkthrough on automating seccomp filters for containers

Context

Container security often focuses on preventing vulnerable code from reaching production, but post-exploitation containment is the harder problem. Once an application inside a container is compromised, the question becomes how much kernel access the process still has, how far that process can pivot, and whether secrets exposed to the container can be misused as machine identities. That is the governance gap this article addresses for containerised workloads.

Seccomp-BPF is a Linux control that limits which system calls a process can make. In NHI terms, it constrains what a compromised workload can do with its runtime authority, which matters because containers often carry secrets, tokens, and service access that should not be broadly reusable. The article’s starting position is typical for modern container adoption: strong portability, weak runtime containment, and too much trust in the application layer.

Key questions

Q: How should teams apply seccomp to containerised workloads without breaking applications?

A: Start with representative test runs that exercise the workload’s real behaviour, then generate a syscall allow list from that evidence. Validate the profile in pre-production and treat permission-denied errors as signals that a code path was missed. The control works best when the application’s test suite is good enough to mirror production execution.

Q: What is the difference between seccomp and IAM for workload security?

A: IAM governs who or what can obtain access, while seccomp governs what a running process can do with that access at the kernel boundary. IAM reduces exposure before execution, but seccomp reduces blast radius after execution. Mature container governance needs both because identity control alone does not stop a compromised process from abusing runtime capabilities.

Q: When does seccomp create more risk than it reduces?

A: Seccomp becomes risky when the generated profile is based on incomplete testing or when teams cannot maintain it as the application changes. In that case, the filter can block legitimate syscalls and disrupt production, or worse, create false confidence if major paths were never exercised. The control only works when evidence quality is high.

Q: Why do containerised applications need runtime containment if secrets are already rotated?

A: Secrets rotation lowers reuse risk, but it does not stop an exploited workload from using valid access during the current session. Runtime containment limits what the process can do if compromise happens before rotation can help. That is why seccomp, least privilege, and secrets lifecycle controls should be treated as complementary controls, not substitutes.

Technical breakdown

How Seccomp-BPF constrains syscall-level execution

Seccomp-BPF is a kernel filtering mechanism that sits between a process and the Linux system call interface. A process in user space cannot open files, spawn processes, inspect memory, or query the system without issuing syscalls, so the filter becomes a policy gate on capability. In the article’s example, the allow list is generated from observed runtime behavior and then reused to block anything outside that observed set. That makes the container behave as if it only has the kernel privileges needed for the tested workload. The important limitation is that the filter is only as complete as the behavior you captured.

Practical implication: Treat the syscall allow list as a least-privilege runtime boundary that must be kept aligned with real application behavior.

Why CI is the right place to generate seccomp profiles

The article argues for generation during continuous integration because CI already exercises the application through repeatable tests. That matters for container governance because manual seccomp maintenance does not scale when features change, dependencies shift, or code paths expand. If tests drive the workload through its expected behavior, the generated profile reflects the current syscall footprint. The quality of the filter therefore depends on test coverage, not just on the tool. This is closer to evidence-based policy generation than static hardening, and it reduces the need for deep kernel knowledge in each development team.

Practical implication: Use CI test coverage as the control point for keeping runtime restrictions current.

How seccomp changes post-exploitation options in containers

Seccomp does not prevent code execution, but it can sharply reduce what an attacker can do after compromise. Many container breakout and privilege-escalation paths depend on a process being able to make new syscalls, probe the filesystem, or launch additional processes. A restrictive profile can break that chain by causing denied operations at the kernel boundary. This is why seccomp belongs in a broader containment model alongside image hardening, secret minimisation, and workload identity controls. The mechanism is narrow, but that narrowness is the point: it reduces the attacker’s room to manoeuvre even when application-layer controls have failed.

Practical implication: Use seccomp as a blast-radius control, not as a replacement for application security or secrets governance.

Threat narrative

Attacker objective: The attacker wants to turn a single application compromise into broader host or workload control.

1. Entry occurs when an attacker exploits the containerised application and gains code execution inside the process.
2. Escalation is attempted through additional syscalls, process spawning, file enumeration, or runtime probing that expand what the compromised workload can do.
3. Impact is limited when the seccomp profile blocks the needed syscall path, preventing common post-exploitation actions from succeeding.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime containment is becoming a first-class NHI control, not a niche hardening trick. Containers often carry service credentials, API tokens, and workload access that function as non-human identities in practice. When those identities are exposed through a compromised process, the real question is how much the attacker can still do. Seccomp-BPF answers that question at the syscall layer, which makes it relevant to NHI governance wherever workloads have execution authority.

Automated seccomp generation is a governance pattern because it ties policy to evidence. Static allow lists tend to drift as applications evolve, while CI-based generation keeps containment closer to actual runtime behavior. That is useful, but only if test coverage is strong enough to exercise real code paths. Practitioners should treat insufficient test coverage as a security blind spot, not a QA detail.

Identity controls and runtime controls need to be paired. Even tightly scoped workload access can be abused if the process still has broad kernel privileges or unnecessary syscalls. Seccomp reduces the attacker’s room to move after initial compromise, while IAM and secrets controls reduce what can be stolen or reused. The practical conclusion is that least privilege has to extend beyond authentication into execution boundaries.

Ephemeral access without containment is incomplete governance. Many teams focus on short-lived credentials, but a short-lived token can still enable meaningful damage if the workload environment is permissive. Seccomp helps narrow that damage window by restricting what the process can do once it is running. NHI governance should therefore include both credential lifecycle controls and runtime enforcement.

Test-driven policy generation introduces a new operational dependency: security now depends on functional fidelity. If tests miss a code path, the generated profile misses a syscall, and production failures become security failures. That creates a measurable control quality issue that belongs in release governance. Teams should only adopt this pattern when they can prove that test coverage is sufficient for the workload’s real behavior.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• For runtime containment and lifecycle governance, see NHI Lifecycle Management Guide for how identity controls and operational discipline fit together.

What this signals

Ephemeral credentials do not solve runtime exposure by themselves. If a container or workload is compromised, the process can still act within the permissions it already has until a control like seccomp constrains execution. That is why container governance should pair identity lifecycle controls with kernel-level containment and keep both tied to release automation.

When security teams treat build-time scanning as the whole control story, they leave a gap between clean code and dangerous execution. The better model is to connect artifact approval, test coverage, and runtime policy enforcement so that the workload cannot exceed its intended syscall profile. For broader identity context, the NIST Cybersecurity Framework 2.0 remains useful for mapping these controls into govern and protect functions.

Identity blast radius: the real exposure is not only whether a workload can authenticate, but how much it can still do after authentication succeeds. Teams should watch for containers that carry persistent secrets, broad filesystem access, or unmanaged runtime privileges, because those conditions turn a single compromise into a wider NHI governance problem. Security programs should prioritise containment where credentials and execution authority intersect.

For practitioners

• Define syscall allow lists from real workload behavior Record runtime syscalls from representative test runs and generate seccomp profiles from the observed set rather than hand-writing kernel rules.
• Gate seccomp regeneration in CI Rebuild the profile whenever application code, dependencies, or startup paths change so the container’s runtime policy stays aligned with current behavior.
• Use test coverage as a security control Require functional tests to exercise the major execution paths before promoting a new profile, and treat untested features as potential syscall gaps.
• Validate denied syscalls during pre-production testing Run the workload with the generated profile in a controlled environment and inspect permission-denied errors to find missed execution paths before release.

Key takeaways

• Seccomp-BPF gives container teams a practical way to restrict what a running process can do after compromise.
• CI-driven profile generation works only when tests cover the application’s real execution paths and not just the happy path.
• For NHI governance, runtime containment should be treated as a complement to secrets management and least privilege, not an optional extra.

Key terms

• Seccomp-BPF: A Linux kernel filtering mechanism that restricts which system calls a process can make. It allows defenders to define a tight runtime policy for a workload, reducing what an attacker can do after application compromise. In container environments, it is a practical way to enforce syscall-level least privilege.
• System Call: A system call is the interface a program uses to ask the Linux kernel to perform privileged operations such as reading files, opening sockets, or creating processes. Because almost every meaningful action in user space depends on syscalls, controlling them gives security teams a powerful runtime containment point.
• Runtime Containment: Runtime containment is the practice of limiting what a running workload can do even after it has been launched successfully. It focuses on reducing post-exploitation damage by constraining system access, process behaviour, and available kernel capabilities rather than only trying to prevent initial compromise.
• Syscall Allow List: A syscall allow list is a policy that permits only the kernel calls a workload demonstrably needs. It is built from observed behaviour or formal policy and used to block unexpected operations, which helps prevent a compromised container from escalating its actions beyond the tested application path.

What's in the full article

GitGuardian's full post covers the operational detail this post intentionally leaves for the source:

• Step-by-step Podman and OCI hook commands for capturing container syscalls during test runs
• A worked GitHub Actions workflow that regenerates a seccomp profile on each code change
• The exact demo container, test script, and commit flow used to push updated filters back to the repository
• Practical error messages to watch for when a syscall is missing from the generated allow list

👉 The full GitGuardian post shows the command examples, CI workflow, and seccomp regeneration flow.

Deepen your knowledge

Seccomp-BPF for container runtime containment is a topic covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a controls programme around workload identities and ephemeral access, it is worth exploring.