Container security profile disabled
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 15 points from that category, once per scan, no matter how many places it turns up.
What it detects
security_opt entries like seccomp:unconfined, apparmor:unconfined, or label:disable turn off the kernel sandboxes that constrain syscalls and mandatory access control.
Why it matters
security_opt entries like seccomp:unconfined, apparmor:unconfined, or label:disable switch off the kernel sandboxes that normally restrict which syscalls a container can make and what it can access. With them off, a compromised process has a far wider attack surface against the kernel. These are usually pasted in to silence an error rather than to meet a real need.
How to fix it
Remove the unconfined or disabled security_opt entries so the default seccomp and AppArmor/SELinux profiles apply again. If the default profile blocks a syscall the workload genuinely needs, supply a custom profile that allows only that syscall instead of turning protection off entirely. Verify the container still runs under the restored profile.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo