RuntimeDefault applies the container runtime’s built-in seccomp policy, which is convenient but may not match a specific application’s needs. A custom profile is written for a particular workload and can allow or block system calls with greater precision. The trade-off is management effort: custom profiles require testing, maintenance, and distribution across nodes.
How RuntimeDefault and a Custom seccomp Profile Differ in Practice
RuntimeDefault is the baseline security posture because it defers syscall filtering to the container runtime’s shipped profile, which is usually designed to be safe across many workloads. A custom seccomp profile changes the question from “what is generally allowed?” to “what does this workload actually need?”, so the policy becomes narrower, more precise, and easier to align to a known application behaviour.
That precision matters when the workload has a stable syscall pattern or when you want to reduce the attack surface beyond the runtime default. It also means the profile becomes part of application engineering, not just cluster configuration, because the workload, image, runtime version, and host kernel can all affect whether a syscall decision is acceptable.
For container runtime context, the NIST SP 800-190 Container Security guidance is the right external reference for understanding how runtime controls fit into the broader container defence model.
The trade-off is straightforward: RuntimeDefault is easier to adopt and maintain, while a custom profile can reduce unnecessary syscall exposure if you are willing to own the lifecycle. In operational terms, custom profiles usually pay off only when the workload is important enough to justify testing, versioning, and rollout discipline.
When a Custom seccomp Profile Is Worth the Operational Cost
Custom profiles are most useful when you have a workload that is well understood, relatively stable, and worth hardening beyond the baseline. They are also useful when the default profile blocks a syscall the application genuinely needs, because a tailored policy can preserve functionality while still denying everything else that is not required.
That tuning should be driven by evidence, not intuition. The safest approach is to observe the workload’s real syscall behaviour under test, compare that against the minimum required set, and then treat the resulting profile as application security configuration that must be reviewed whenever the application, runtime, or kernel changes.
- Use RuntimeDefault first when you need a fast, low-maintenance baseline.
- Use a custom profile when the workload is important enough that syscall minimisation justifies ongoing ownership.
- Re-test custom profiles after application upgrades, runtime upgrades, or major dependency changes.
A practical point many teams miss is that “more restrictive” is not automatically “better” if it breaks observability or core application functions. A custom profile is only an improvement when it is both tighter and demonstrably compatible with the workload you are protecting.
For teams building container hardening around the baseline, the OWASP API Security Top 10 is also useful as a reminder that the surrounding application surface still needs separate authorisation and abuse resistance.
Risk and Threat Considerations
seccomp is a containment control, not a complete isolation boundary. If the profile is too permissive, an exploit that reaches a container may gain access to unnecessary kernel interfaces; if it is too restrictive or poorly tested, the likely failure mode is application breakage, fragile deployments, or teams silently relaxing the policy until it provides little protection.
Failure mechanism: Attackers benefit when a container retains broad syscall access after compromise, because that can support exploit chaining, escape attempts, or post-exploitation actions that should not be available to the workload. On the defensive side, custom profiles fail when they are copied without validating the application’s actual behaviour or when node/runtime drift changes syscall expectations.
Impact: The result can be either increased blast radius from an over-permissive profile or repeated availability issues from an over-tight profile. In both cases, the organisation loses confidence in the control and may end up treating seccomp as a checkbox rather than a meaningful hardening layer.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access Control | seccomp restricts what the container process may do at runtime |
| PR.IP-1 — Baseline Configuration | RuntimeDefault versus custom profiles is a baseline-versus-tailored configuration decision | |
| PR.DS-1 — Data-at-Rest Protection | seccomp contributes to limiting exploitation paths that could reach sensitive data | |
| Recommendation — Apply least-privilege runtime restrictions to container processes. Define and manage container runtime baselines, then document approved deviations. Reduce exposed execution paths that could lead to sensitive-data access. | ||
| CIS Controls v8 | 4.1 — Establish and Maintain a Secure Configuration Process | custom seccomp profiles need testing, versioning, and controlled rollout |
| Recommendation — Maintain and validate hardened container runtime profiles as secure configurations. | ||
Practitioner Guidance
What to verify: Before moving from RuntimeDefault to a custom profile, confirm that the application has a stable syscall footprint and that the team can test it against the exact runtime and kernel combinations used in production. If those dependencies are not controlled, the profile will be brittle.
Implementation sequence: Start with RuntimeDefault, observe the workload, tighten only where there is clear evidence of needed deviation, and then roll the custom profile through non-production environments before broad deployment. Treat the profile as versioned security code, not as a one-time YAML change.
Common mistake: Teams often assume a custom profile is automatically safer because it is narrower. In practice, an unmaintained custom profile can become outdated, get bypassed during emergency changes, or break in ways that cause operators to disable it entirely.
Practitioner takeaway: RuntimeDefault is the safer default when you want consistency and low overhead; a custom profile is the better control only when you can prove the workload needs it and you can sustain its maintenance.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
