Notifications
Clear all
Topic starter
02/08/2026 12:28 pm
TL;DR: Container security risks increase across build, deployment, and runtime when teams rely on repo scanning alone, trust public base images, or treat misconfigurations as secondary issues, according to Checkmarx. The governance gap is not visibility in code, but failure to assess the fully built artifact and its identity and access exposure before production.
NHIMG editorial — based on content published by Checkmarx: container security misconceptions and smarter layered controls
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: What breaks when teams scan container code but not the built image?
A: They miss the actual security state of what will run.
Q: Why do containers increase the blast radius of identity mistakes?
A: Containers often rely on service accounts, registry tokens, and cluster roles that act like non-human identities.
Q: What do security teams get wrong about base image trust?
A: They treat trusted labels as proof of safety.
Practitioner guidance
- Implement built-image scanning as a release gate Make the fully built container image the policy checkpoint before promotion, because repo-only scanning misses packages, layers, and build-time dependencies that alter the final risk profile.
- Create an approved base image library Maintain a small, continuously revalidated set of base images with known provenance, owner, and update cadence.
- Remove secrets from images and config files Scan Dockerfiles, Kubernetes manifests, and application configs for hardcoded secrets, then replace them with external secret storage and short-lived access patterns.
What's in the full article
Checkmarx's full webinar covers the operational detail this post intentionally leaves for the source:
- A walkthrough of the KICS and 2MS workflow for scanning Terraform, Kubernetes, Docker, and collaboration tools for risk.
- Practical examples of how container misconfigurations map to privilege escalation, secrets exposure, and runtime abuse.
- The specific checks and pipeline points Checkmarx recommends for catching issues before production.
- The webinar's examples of how layered scanning reduces false negatives across build and runtime stages.
👉 Read Checkmarx's webinar on container security misconceptions and pipeline controls →
Container security is not just code scanning, are your controls enough?
Explore further
02/08/2026 1:27 pm
Container security failures are really trust boundary failures. The article shows that teams still place too much trust in repository scanning, base image labels, and runtime detection. Those controls matter, but they do not verify the security of the built artefact or the identities that assemble it. In practice, the control boundary has moved into the pipeline, and teams that do not govern that boundary will keep finding surprises in production.
A question worth separating out:
Q: How should organisations govern container security across build and runtime?
A: They should treat container security as a lifecycle, not a point-in-time scan. That means checking source, image, infrastructure-as-code, and runtime separately, while using least privilege and secrets separation to keep one failure from becoming an environment-wide compromise.
👉 Read our full editorial: Container security fails when teams scan code but not images
