Container security scanning closes visibility gaps in Docker images

At a glance

What this is: This is a practical analysis of container security scanning and the common vulnerabilities found in Docker images, including secrets, misconfigurations, and dependency exposure.

Why it matters: It matters to IAM and NHI practitioners because containers often carry credentials and identity-adjacent trust assumptions that can outlive the build that created them.

By the numbers:

• 4.6% of all public GitHub repositories contain at least one hardcoded secret.
• 38% of secrets incidents in collaboration and project management tools like Slack, Jira, and Confluence are classified as highly critical or urgent.
• 15% of commit authors have leaked at least one secret in their contribution history.

👉 Read GitGuardian's analysis of container vulnerabilities, scanning, and runtime security

Context

Container security scanning is the practice of inspecting images, filesystems, and runtime behaviour for weaknesses before or after deployment. For IAM and NHI teams, the issue is larger than software defects because images can also embed secrets, inherited permissions, and deployment assumptions that create durable identity exposure inside ephemeral infrastructure.

The article argues that build-time scanning and runtime detection should be part of DevSecOps rather than separate tools. That framing is typical for modern container programs: most teams need both static inspection of image contents and behavioural monitoring once the workload is live.

Key questions

Q: How should security teams handle secrets that may be embedded in container images?

A: Teams should treat embedded secrets as an identity exposure problem, not just a scanning finding. The right response is to locate the secret in build history, revoke or rotate it, remove it from the image source, and prevent recurrence with pre-build checks on Dockerfiles, arguments, and layer contents. Secret removal alone is not enough if the credential remains valid.

Q: What is the difference between container secret scanning and vulnerability scanning?

A: Secret scanning looks for credentials such as API keys, tokens, certificates, and hard-coded passwords. Vulnerability scanning looks for known weaknesses in packages, libraries, and operating system components. Both are needed because a container can be free of CVEs and still leak an NHI secret, or can contain no secrets while still shipping known software flaws.

Q: Why is runtime monitoring still necessary if containers are scanned before deployment?

A: Build-time scanning can confirm what was present in an image, but it cannot see how the container behaves after launch. Runtime monitoring is necessary because shell access, unexpected network traffic, and configuration drift are live signals of compromise. Without runtime detection, teams miss the moment a valid workload becomes an attacker-controlled foothold.

Q: How do container images affect NHI governance?

A: Container images can carry secrets, service credentials, and other identity material that function like non-human identities inside the delivery pipeline. That makes them part of NHI governance because they require inventory, lifecycle control, rotation, and revocation discipline. Teams should manage them as identity-bearing artifacts, not only as software packages.

Technical breakdown

Why Docker image layers hide secrets and misconfigurations

Container images are built from layers, and each layer can preserve content that is no longer visible in the final filesystem state. That means a secret removed from a later step may still exist in an earlier layer, and a configuration mistake can be inherited across image rebuilds. Scanners therefore need to inspect both the current image contents and the history of how the image was assembled. This is one reason NHI secrets in build pipelines are risky: the exposure is often persistent even when the runtime container looks clean.

Practical implication: Inspect image layers, build arguments, and Dockerfile history, not just the running container.

How secret and vulnerability scanners differ in container security

Secret scanning looks for credential-like material such as keys, tokens, and certificates, while vulnerability scanning matches installed packages and libraries against known CVEs. These are different problems. A container can be free of known CVEs and still contain a hard-coded API key, or it can be secret-free but inherit an exposed library issue from the base image or dependency tree. In practice, both scan types are needed because they answer different governance questions: what identity material is embedded, and what known software weaknesses are present.

Practical implication: Run secret and vulnerability scans as separate control checks in the build pipeline.

What runtime container security detects that build-time scanning misses

Runtime security watches for behaviour that is unusual for the workload, such as an interactive shell, unexpected network traffic, or configuration changes after deployment. This matters because some threats only become visible when the container is executing. Build-time scanning cannot tell you whether a container has been hijacked after launch, and image inspection cannot observe live misuse of a service account or token. Runtime controls therefore complement, rather than replace, image scanning by adding detection after the image has left the registry.

Practical implication: Use runtime rules to detect drift, shell access, and other live indicators of compromise.

Threat narrative

Attacker objective: The objective is to turn a container foothold into broader environment access by abusing embedded secrets or runtime weaknesses.

1. Entry begins when an attacker finds a hard-coded secret or misconfiguration inside a container image or its build history.
2. Escalation occurs when that credential or flaw is used to access internal systems, pivot into adjacent services, or escape the container boundary.
3. Impact follows when the attacker uses the compromised workload to reach data, infrastructure, or higher-privilege identities.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Container security scanning is really an NHI discovery problem. Images, build layers, and deployed workloads often contain secrets that function as non-human identities, even when teams think they are only shipping application code. Once those secrets are embedded, the control challenge becomes identifying where they live, how long they persist, and who can use them. Practitioners should treat image scanning as part of identity inventory, not just vulnerability management.

Layered container builds create identity blast radius when secrets are reused. A secret in a Dockerfile, build argument, or intermediate layer can be copied into every derived image and every environment that consumes it. That widens the blast radius beyond a single deployment. The practical conclusion is straightforward: reduce secret reuse, minimise layer persistence, and assume that every build artifact can become an identity carrier.

Runtime monitoring is the missing control when static scanning is not enough. Build-time checks can tell you what was present in an image, but they cannot prove how the container behaves after launch. Shell spawning, unexpected outbound traffic, and post-deploy configuration drift are all signs that the workload has crossed from ordinary execution into misuse. Teams should pair image scanning with runtime detection if they want meaningful containment.

The control gap is not tooling coverage alone, it is lifecycle discipline. Container programs fail when teams scan images once and then assume the risk is resolved. Identity material moves through build, registry, deployment, and runtime stages, so the governance model has to follow the artifact across its whole lifecycle. Security teams should align container controls with secret rotation, workload identity review, and access boundaries.

Container security should be evaluated as a trust chain, not a point-in-time test. The article’s real message is that images can be clean at one stage and dangerous at another, which is exactly how NHI risk behaves in modern delivery pipelines. Practitioners should stop asking whether a container is scanned and start asking whether the identity-bearing contents of that container are controlled end to end.

From our research:

• Around 100,000 valid secrets were found in public Docker images, with ENV instructions alone accounting for 65% of all secret leaks in containers, according to the State of Secrets Sprawl 2025.
• From our research: 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to the State of Secrets Sprawl 2025.
• For a broader view of where these exposures fit in the NHI lifecycle, see Ultimate Guide to NHIs - Key Challenges and Risks and the practical control patterns they inform.

What this signals

Container scanning should now be treated as an identity-control extension, not a standalone security check. Once secrets are embedded in images or pipelines, they become durable non-human identities that outlive a single deployment. With 4.6% of public GitHub repositories containing at least one hardcoded secret, the governance problem begins long before runtime and must include build hygiene, source control review, and secret revocation.

Ephemeral workloads still create persistent trust debt when their image layers retain credentials. The lifecycle question is not whether a container disappears after termination, but whether the credential it carried can still be abused elsewhere. Teams that rely on image scanning without access review and revocation will keep finding the same exposure pattern in new deployments.

If your programme already maps service accounts and API keys, extend that inventory to containers, image registries, and build artifacts. The operational win is better blast-radius control, especially when the same secret can be copied across multiple environments before anyone notices.

For practitioners

• Scan image layers for embedded secrets Inspect Dockerfile history, build arguments, and intermediate layers so that removed secrets do not survive in older image layers.
• Separate secret scanning from vulnerability scanning Run controls for credentials, tokens, and certificates in parallel with CVE scanning so that identity exposure and software risk are both covered.
• Add runtime detection for container abuse Alert on interactive shells, unexpected outbound connections, and post-deployment configuration changes because these behaviours often indicate compromise.
• Tie container reviews to secret lifecycle controls Rotate or revoke secrets that appear in builds, and include service accounts and API keys in offboarding and access-review workflows.

Key takeaways

• Container security scanning is essential because images can embed both software flaws and identity material.
• Build-time inspection and runtime detection solve different parts of the same governance problem, so teams need both.
• For IAM and NHI teams, the real control objective is lifecycle discipline across build, registry, deployment, and runtime stages.

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.
• Runtime Container Security: Runtime container security is the monitoring and control of workloads while they are executing. It focuses on live behaviour such as shell spawning, unusual network traffic, and configuration drift, which often reveal compromise after build-time scanning has already finished.
• Secret Scanning: Secret scanning is the process of detecting credentials such as API keys, tokens, certificates, and passwords in code, images, or filesystems. In NHI governance, it helps identify identity material that should be rotated, revoked, or removed before it can be abused.
• Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.

What's in the full article

GitGuardian's full blog post covers the implementation detail this analysis intentionally leaves at the control level:

• Specific command examples for ggshield, SecretScanner, and Trivy across images and filesystems
• Dockerfile misconfiguration checks, including non-root execution, pinned base images, and health checks
• Runtime detection examples for shell spawning and abnormal container behaviour using Falco
• Step-by-step comparisons of secret scanning, SCA, and runtime security across the SDLC

👉 GitGuardian's full post includes tool examples, scan outputs, and Dockerfile misconfiguration details

Deepen your knowledge

Container security scanning and secret lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to govern image-borne credentials in a DevSecOps environment, it is worth exploring.