Notifications
Clear all
Topic starter
01/08/2026 8:55 pm
TL;DR: How analyzer platforms use per-language Docker images, bind mounts or docker cp, and Linux filesystem permissions can be broken by POSIX ownership and mode bits on Linux hosts, according to Semgrep. The security lesson is that execution context, file transfer paths, and least-privilege assumptions all matter when tools move data between containers and host systems.
NHIMG editorial — based on content published by Semgrep: an analysis of analyzer containers and Linux filesystem permissions
Questions worth separating out
Q: How should security teams handle file permissions in containerised analysis pipelines?
A: Teams should treat file permissions as part of the access model for the pipeline, not as an implementation detail.
Q: Where do container workflows fail when host and runtime identities do not match?
A: They fail at the handoff points: mounting input paths, writing output artefacts, and creating temporary files.
Q: Why do Linux permissions create problems for security tooling in CI environments?
A: CI often introduces a different runtime context from local development, especially when remote daemons or docker cp are involved.
Practitioner guidance
- Standardise runtime user identities Run analyzer containers with a predictable non-root user and align that user with the ownership of shared input and output paths across Linux hosts and CI runners.
- Validate shared-volume permissions early Test bind-mounted directories for read, write, and execute access before rollout so permission mismatches surface during build validation rather than in production analysis runs.
- Document copy and mount fallbacks Define when the pipeline should use docker cp instead of bind mounts, and record how that fallback changes ownership, latency, and failure handling.
What's in the full article
Semgrep's full article covers the operational detail this post intentionally leaves for the source:
- The exact analyzer input and output flow used by the platform, including how manifest-driven inputs are staged.
- The differences between bind mounts and docker cp in the CI environment, including why remote Docker changes the file-handling model.
- A step-by-step explanation of POSIX user, group, and mode-bit behaviour on Linux hosts.
- The specific permission failure pattern observed when the workflow moved from one runtime context to another.
👉 Read Semgrep's analysis of analyzer containers and Linux filesystem permissions →
Linux container filesystem permissions: what IAM teams should notice?
Explore further
01/08/2026 9:03 pm
Filesystem permissions are an identity problem as much as an OS problem. The article shows that the same pipeline can work in one environment and fail in another because the effective identity context changes. That is a familiar governance pattern for workload access and NHI-adjacent tooling, where runtime identity, file ownership, and execution location all shape whether access is legitimate. The practitioner takeaway is to treat container file exchange as an access-control design choice, not a convenience detail.
A question worth separating out:
Q: What should teams do before relying on bind mounts for containerised jobs?
A: They should confirm the job can read inputs, write outputs, and preserve the required ownership model under the exact host and daemon arrangement they will use in production. If that is not stable, use an explicit copy-based handoff and document the control change so operators know what identity boundary they are crossing.
👉 Read our full editorial: Filesystem permissions in Linux containers and analyzer workflows
