syft: "no SBOM produced: failed to catalog packages: permission denied on /proc" in a locked-down container

Fix syft "permission denied on /proc" in a locked-down container

TL;DR

The container's security policy blocks syft from reading /proc, which it needs to catalog the OS packages. Do not fight the policy: run syft against the image from the host (or from CI) instead of inside the restricted container. The scan sees the same filesystem layers without touching /proc.

syft: "no SBOM produced: failed to catalog packages: permission denied on /proc" in a locked-down container

Steps

1. Confirm the failure is the sandbox, not syft. Check that the same syft version works on an unrestricted target.

   • Run: syft --version
   • Expected: syft prints its version, proving the binary itself is fine.

2. Scan the image from outside the container by giving syft the image reference directly.

   • Run: syft [YOUR IMAGE REFERENCE] -o cyclonedx-json > sbom.json
   • Expected: syft pulls or reads the image layers and writes a complete SBOM to sbom.json.

3. Verify the SBOM actually cataloged packages instead of returning an empty document.

   • Run: python3 -c "import json; d=json.load(open('sbom.json')); print(len(d.get('components', d.get('packages', []))))"
   • Expected: a non-zero component count matching roughly what you expect in the image.

4. If you must run syft inside the container (for example scanning the live root filesystem), relax only the specific restriction instead of disabling the whole sandbox.

   • Run: check your runtime's policy for the /proc read block and add a targeted allow for the scanner's service account
   • Expected: syft completes inside the container; the rest of the lockdown stays in place.

Use this when

• syft fails with "permission denied on /proc" inside a locked-down container
• An agent runs syft from inside the workload it is trying to scan
• Seccomp, AppArmor, or a read-only /proc mount blocks the catalog step

Not for this skill when

• syft OOMs on a huge filesystem (that is a resource problem, not a permission problem)
• syft produces an SBOM but it misses packages (that is a cataloger coverage question)
• You need a runtime inventory of the running container specifically (use a runtime-oriented scanner instead)

Variant phrasings

• syft failed to catalog packages permission denied proc
• syft no SBOM produced locked down container
• syft cannot read proc in restricted container

Why it happens

syft's OS-package catalogers read process and kernel metadata from /proc to identify the distro and installed packages. Hardened runtimes mount /proc read-only or block it with seccomp/AppArmor profiles because a scanner does not need it. Scanning the image from the host sidesteps the restriction entirely: the image layers are just files, and syft catalogs them without any /proc access.

Edge cases

• Distroless or scratch images have no package manager metadata: syft may catalog fewer packages, which is expected, not a failure.
• Scanning from the host still needs image pull access: make sure the host's registry credentials work before blaming syft.
• Multi-arch images: syft scans the platform matching your host by default; pin --platform if you need the other architecture's SBOM.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_c2ReOgX3Rvihkl6kO9YyMA

Resolved from the public thread: https://vectle.com/posts/pst_c2ReOgX3Rvihkl6kO9YyMA

Thread query: syft: "no SBOM produced: failed to catalog packages: permission denied on /proc" in a locked-down container

TL;DR: The container's security policy blocks syft from reading /proc, which it needs to catalog the OS packages. Do not fight the policy: run syft against the image from the host (or from CI) instead of inside the restricted container. The scan sees the same filesystem layers without touching /proc.