Container security fails when teams scan code but not images

At a glance

What this is: This is an analysis of common container security misconceptions, with the central finding that repo scanning alone misses build-time, image-level, and runtime risks.

Why it matters: It matters because containerised workloads often inherit secrets, privileges, and dependencies after code review, which means IAM, PAM, and NHI controls have to extend into the build and deployment pipeline.

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.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read Checkmarx's webinar on container security misconceptions and pipeline controls

Context

Container security breaks down when teams assume that scanning source code tells them what will actually run in production. In practice, containers can inherit vulnerable packages, unsafe configuration, over-permissive identities, and exposed secrets after the code review stage, so the real control boundary sits at the built image and its runtime permissions, not the repository alone.

That distinction matters for IAM and NHI governance because container pipelines often create service accounts, tokens, and image access paths that outlive the code review that approved them. When the build pipeline becomes the place where trust is established, security teams need to govern both the artefact and the identities that produce and consume it.

Key questions

Q: What breaks when teams scan container code but not the built image?

A: They miss the actual security state of what will run. A clean repository can still produce a vulnerable image through build-time dependencies, outdated base layers, or malicious packages. The result is false confidence, because the repository no longer matches the deployable artefact and production risk is discovered too late.

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. If those identities are overprivileged or embedded in configs, an attacker can move from a single workload to broader infrastructure access much faster than in a tightly segmented environment.

Q: What do security teams get wrong about base image trust?

A: They treat trusted labels as proof of safety. In reality, an official-looking image can still be stale, vulnerable, or altered in ways that create risk downstream. Security teams need provenance checks, vulnerability review, and a controlled approval process before any base image is reused.

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.

Technical breakdown

Why repo scanning misses container risk

Source code scanners inspect files in the repository, but containers are assembled from layers, package managers, base images, and build-time dependencies that may never appear in the repo. That means a clean codebase can still produce a vulnerable image if a Dockerfile pulls an outdated package, a transitive dependency, or a malicious layer. The security problem is not just what developers wrote, but what the build process resolved and embedded. In containerised environments, the final image is the executable security boundary, so visibility has to shift from source to artefact.

Practical implication: scan the built image as the control point, not just the source repository.

Base images, trust, and supply chain exposure

Public registries create an implicit trust problem because an image can look official, familiar, or widely used while still containing stale packages, unmaintained components, or hidden malicious content. That makes the base image part of the software supply chain, not a neutral starting point. Security teams should think about provenance, maintenance cadence, and vulnerability density before they build on top of an image. Pre-approved image libraries reduce variability, but only when they are continuously refreshed and enforced across teams.

Practical implication: govern base images as approved dependencies with provenance checks and regular revalidation.

Misconfigurations create privilege and secrets exposure

Container and Kubernetes risk often comes from configuration drift rather than unpatched vulnerabilities. Running as root, over-broad cluster roles, hardcoded secrets, and missing resource limits give attackers a direct path to privilege escalation, credential theft, lateral movement, and service abuse. This is where the identity angle becomes concrete: service accounts, tokens, and secrets inside orchestration platforms behave like non-human identities, and if they are overprivileged or embedded in files, the blast radius expands quickly. Runtime tools can detect abuse, but they cannot undo a design that granted too much access up front.

Practical implication: enforce least privilege, secret separation, and configuration checks before deployment.

Threat narrative

Attacker objective: The attacker aims to turn a container trust failure into broader access, data exposure, or resource abuse across the environment.

1. Entry begins when an attacker or risky dependency is introduced through a vulnerable base image, exposed configuration, or a build pipeline that pulls untrusted layers and packages.
2. Escalation occurs when the container runs with root privileges, over-permissive cluster roles, or embedded secrets that let the attacker access internal services and infrastructure.
3. Impact follows as the attacker moves laterally, steals data, abuses compute resources, or turns the environment into a platform for persistence and service disruption.

NHI Mgmt Group analysis

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.

Build-time identity is the hidden control plane in container security. A container pipeline creates service accounts, registry permissions, signing workflows, and secret access paths that can become non-human identity sprawl if they are not lifecycle-managed. That is where OWASP Non-Human Identity Top 10 guidance becomes relevant, because image build and delivery depend on credentials that are often over-scoped and poorly rotated. Practitioners should treat build identities as first-class assets, not implementation detail.

Misconfiguration is now the dominant container failure mode because it bypasses patch-centric thinking. The article correctly separates vulnerability management from configuration governance. Running as root, hardcoding secrets, and granting unnecessary cluster rights all create exploit paths that CVE remediation cannot solve on its own. A mature programme needs both container security posture management and identity controls that reduce the blast radius of every workload.

Pre-approved base images are a governance mechanism, not a comfort blanket. Trusting Docker Hub labels or vendor verification badges without a continuous approval process creates false assurance. The real issue is whether the image source, dependency set, and update cadence are controlled enough to support secure reuse. Teams should view base image governance as a supply chain control tied to policy enforcement, not a convenience list.

Continuous container security only works when the programme aligns code, image, and runtime decisions. The strongest signal in this article is that no single scan point is sufficient. Code review, image scanning, infrastructure-as-code checks, and runtime monitoring each close different gaps, but none replaces the others. Practitioners should use the article as evidence that container security has to be managed as a lifecycle, with identity and secrets controls embedded throughout.

What this signals

Container security programmes are becoming identity programmes whether teams label them that way or not. Build agents, registry access, secret injection, and deployment credentials all behave like non-human identities that need lifecycle control, not just scanning. The practical shift is toward governing who or what can assemble, sign, and deploy artefacts, then binding that to policy and review.

Container security posture management only works when it is paired with secret lifecycle controls. Visibility into misconfigurations is useful, but it does not fix leaked credentials or stale access paths. The operational priority is to connect image policy, secret rotation, and build permission reviews so that one control does not simply reveal the next failure point.

Identity teams should expect more overlap between appsec, platform engineering, and NHI governance. As container estates mature, the most useful controls will sit where image provenance, workload identity, and secrets management intersect. That is why resources such as the OWASP Non-Human Identity Top 10 matter for teams modernising their pipeline governance.

For practitioners

• 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. Use the built artefact as the authoritative object for vulnerability and malware inspection.
• Create an approved base image library Maintain a small, continuously revalidated set of base images with known provenance, owner, and update cadence. Block unapproved public images in CI/CD so developers cannot inherit unknown package states or stale vulnerable layers from convenience pulls.
• 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. Treat secrets in files as a deployment blocker because they turn every copied artefact into a credential exposure event.

Key takeaways

• Container risk often starts after code review, when build-time dependencies, base layers, and pipeline credentials change the final artefact.
• Misconfigurations such as root execution, over-broad roles, and hardcoded secrets create more immediate compromise paths than many patched CVEs.
• Teams need lifecycle controls across source, image, deployment, and runtime, with non-human identity and secrets governance built into the pipeline.

Key terms

• Container Image Layer: A container image layer is one step in the stacked filesystem that makes up an image. Layers can preserve files, secrets, and configuration from earlier build steps even when those items are no longer visible in the final image state. That persistence is why layer-level inspection matters for identity and secret governance.
• Build-time dependency: A build-time dependency is any package, library, or component introduced while assembling software rather than in the original source tree. These dependencies can change the final security posture without appearing in code review, which is why image and pipeline scanning matter alongside repository analysis.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Container misconfiguration: Container misconfiguration is a security weakness created by incorrect settings rather than a code flaw, such as running as root, granting excessive cluster permissions, or exposing secrets in files. These issues are dangerous because they often create direct paths to privilege escalation and lateral movement.

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.

👉 Checkmarx's full webinar covers the build-time checks, runtime gaps, and pipeline controls behind these container risks.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the operational realities of modern delivery pipelines.