Container security fails when teams scan code but not images

At a glance

What this is: Checkmarx argues that container security breaks down when teams scan source code but ignore the built image, base images, and runtime configuration risks that determine what actually runs.

Why it matters: For IAM and security teams, the key issue is that containerised workloads inherit identity, privilege, and secret exposure risks that code-only scanning cannot see, so governance has to extend into build, deployment, and runtime control points.

By the numbers:

• Modern development now powers nearly 90% of cloud-native applications globally.

Context

Containers change the security question from what was written in code to what actually ships, runs, and connects to internal systems. A repository scan can miss packages, layers, credentials, and configuration choices introduced during build, which means the final container image can diverge sharply from the code review view.

That gap matters because container misconfigurations often become access problems. Root execution, overly permissive roles, hardcoded secrets, and exposed files create identity and privilege exposure that sits close to NHI governance, even when the original issue looks like application or platform security.

The article’s starting point is typical for modern cloud-native teams: they have code scanning in place, but not enough control over the full container lifecycle.

Key questions

Q: Where do container security controls fail when teams scan only source code?

A: They fail at the point where the build process changes the software state. Dependencies, layers, and configuration can be introduced after the repo scan, so the final image may contain risks that were never reviewed. Teams need to assess the artefact that will run, not only the code that was committed.

Q: Why do misconfigured permissions and exposed secrets make container environments easier to exploit?

A: Containers often move quickly and run at scale, so small mistakes can create broad exposure. Overly permissive access lets attackers pivot laterally, while secrets baked into images can be reused for unauthorized access to services and data. If runtime protections are weak, those initial mistakes can turn into privilege escalation, data theft, or host compromise.

Q: What are the signs that container security controls are failing in production?

A: Warning signs include repeated image drift, unexpected processes, abnormal network flows, replicas that no longer match expected behavior, and suspicious access to Kubernetes APIs or etcd. You should also treat delayed vulnerability remediation and overly broad permissions as failure signals. These indicators usually mean monitoring, policy enforcement, or runtime detection is not keeping pace.

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 code scanning misses container risk

Source-code scanning looks at the repository state, but containers are assembled from additional inputs at build time. Package managers fetch dependencies, Dockerfiles layer in base images, and CI systems inject configuration that may never exist in the repo. That means the security boundary shifts from source to artifact. If teams only assess SAST or SCA results, they can miss malicious layers, vulnerable packages, or runtime-only behaviours that become part of the deployed image. In practice, the container image is the security object that matters, because it is what the orchestrator actually runs.

Practical implication: Scan the built image as a separate control point, not just the source repository.

Base image trust and supply chain exposure

Public registries are not equivalent to trusted provenance. A base image can be outdated, poorly maintained, or intentionally deceptive, and a familiar name does not guarantee acceptable security. Container builds also inherit all the risk in that image, including embedded packages, old libraries, and known vulnerabilities that developers did not author themselves. This is a supply chain problem as much as a vulnerability problem, because each upstream layer becomes part of the operational trust model. Once a weak base image is reused widely, the exposure scales across teams and services.

Practical implication: Treat base images like governed dependencies and verify them before reuse.

Misconfiguration turns containers into identity and access risk

Container breaches often emerge from control failures rather than unpatched CVEs. Running as root, granting excessive roles, leaving secrets in code or config, and exposing services without limits all create conditions for privilege escalation and data access. In Kubernetes and adjacent platforms, misconfiguration can collapse the intended separation between workload identity, secret access, and network reachability. That is why container security overlaps with NHI governance: a workload with too much privilege or a leaked secret behaves like an over-privileged identity, even if no human account is involved.

Practical implication: Review workload privilege, secret handling, and access scope as one governance problem.

Threat narrative

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

1. Entry begins when attackers exploit a trusted but weak container supply chain input, such as an outdated base image or an exposed secret embedded in build material.
2. Credential or privilege abuse follows when a container runs as root or inherits excessive permissions, allowing the attacker to expand access beyond the initial workload.
3. Impact occurs when the attacker reaches internal services, databases, or compute resources, enabling data exposure, service abuse, or resource hijacking such as cryptomining.

Breaches seen in the wild

• Millions of Misconfigured Git Servers Leaking Secrets: Nearly 5 million misconfigured Git servers expose sensitive secrets and credentials online.
• Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Container security has become a lifecycle governance problem, not a scan problem. Code scanning is only one checkpoint in a chain that now includes image assembly, registry trust, deployment policy, and runtime observation. If the fully built image is not assessed, teams are governing source code while leaving the production artefact outside control. Practitioners should treat the container image as the real security boundary.

Artifact trust drift: is the right concept for this risk. The build pipeline often introduces dependencies and configuration that do not exist in the repository view, so security assumptions drift between commit and runtime. That drift is especially dangerous in cloud-native estates where the same image may be promoted repeatedly across environments. Practitioners should control trust at the artifact layer, not assume source review is enough.

Misconfiguration is the dominant container identity failure mode. Root execution, excessive roles, and leaked secrets all convert a workload into an access vector. This is where container security intersects directly with NHI governance, because service credentials and workload permissions create machine identity behaviour even when teams do not label them that way. Practitioners should govern workload privilege and secret exposure as first-class identity controls.

Layered controls are now the minimum viable container model. No single scanner can compensate for weak provenance, unsafe defaults, or runtime drift. The article reinforces a broader pattern in cloud security: detection without preventive controls simply shortens the time between exposure and exploitation. Practitioners should align build, registry, deployment, and runtime controls into one operating model.

From our research library:

• Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.
• Read next: Secrets Management Guide

What this signals

Artifact trust drift: container teams often believe source review is equivalent to deployment review, but the build step changes the security object. Once packages, layers, and environment settings are introduced after code scanning, the programme needs image-level governance rather than repository-level assurance.

Container security programmes should expect the identity risk to sit inside workload permissions and secret handling as much as inside code quality. That means build controls, registry hygiene, and deployment policy need to be managed as one system, not as disconnected tools.

The strongest signal of maturity is whether a team can explain why a particular image is allowed to run, where its trust came from, and what would trigger revocation or rebuild.

For practitioners

• Scan the built container image before deployment Assess the fully assembled image, not only the repository or Dockerfile, so hidden packages, inherited layers, and runtime-only risks are visible before release.
• Maintain a pre-approved base image library Allow teams to build only from curated images that have been reviewed for age, provenance, and vulnerability exposure, then refresh that library on a defined schedule.
• Treat container misconfigurations as access issues Review root execution, role scope, exposed services, and hardcoded secrets together, because each of these can turn a workload into an identity and access weakness.
• Rescan registry images after deployment changes Trigger fresh analysis when base images, infrastructure, or service configurations change so drift does not turn an approved image into a newly risky one.

Key takeaways

• Container risk is introduced across the pipeline, not only in source code, because the build process can add dependencies, layers, and secrets that scanning the repo never sees.
• Misconfiguration is a primary failure mode in container environments, especially when root execution, over-permissive roles, and exposed secrets combine to create access paths.
• The practical response is lifecycle governance: inspect the built image, control base image trust, and align deployment and runtime checks with the artefact that actually runs.

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.
• Image-Level Scanning: Image-level scanning inspects the assembled container artefact rather than only source code or a Dockerfile. It is used to reveal inherited packages, hidden dependencies, and vulnerable layers that appear during build time and would otherwise be invisible to code-only security checks.
• 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.
• Agent Trust-Chain Drift: The gradual gap between the agent behaviour an enterprise intends and the access, dependencies, and runtime conditions that actually shape what the agent can do. It matters because trusted inputs such as connectors, extensions, and prompts can expand authority without a deliberate governance decision.

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course covers NHI governance, machine identity security, and secrets management in practical operational terms. It is designed for practitioners who need to connect identity controls to real-world security programmes.