TL;DR: GitGuardian shows that Docker images can hide hard-coded secrets, misconfigurations, vulnerable packages, and runtime abuse paths, while layered scanning across build and runtime phases helps expose what is embedded, inherited, and executed in the container lifecycle. The real control problem is continuous visibility, because a container image can remain risky long after it looks clean at the top layer.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on GitGuardian's blog post: Container security scanning must cover image contents and runtime behaviour to surface secrets, misconfigurations, and vulnerable dependencies hidden inside Docker images.
Why it matters: For IAM, PAM, and NHI practitioners, the key lesson is that containerised workloads carry identity and secret risk that cannot be governed by build-time checks alone.
👉 Read GitGuardian's analysis of container security scanning for Docker images
Context
Container images are mutable security containers, not just deployment artefacts. They can embed code, dependencies, configuration files, and secrets that persist into production even when the running container looks normal on the surface.
The governance gap is visibility across the image lifecycle. Build-time scanning can catch some issues before deployment, but runtime scanning is needed when the question becomes what the container actually does after start, especially in environments where workloads run with privileged access or interact with sensitive services.
Key questions
Q: What breaks when container security stops at image scanning?
A: You miss the risks that emerge after the image is approved. Production drift, runtime abuse, cluster misconfiguration, and compromised pipeline credentials can all undermine an otherwise clean image. Scanning still matters, but it cannot tell you whether the container is behaving normally, whether it can reach sensitive cloud resources, or whether the build system itself has been subverted.
Q: Why do secrets embedded in container images create supply chain risk?
A: Secrets in container images create supply chain risk because images are often copied into registries, shared across teams, and reused in downstream builds. If credentials are exposed in layers or manifests, anyone who can pull the image can inspect them. That turns a local developer mistake into a broader compromise path across build systems, registries, and connected services.
Q: What are the signs that runtime container controls are failing?
A: Warning signs include unexplained shells inside running containers, abnormal outbound connections, process changes that do not match the workload, and alerts that never fire during tests. If runtime controls only inspect startup files and never live behaviour, they are not covering the attack surface that appears after deployment.
Q: Should teams rely on image scanning or runtime monitoring for container security?
A: They need both, but they solve different problems. Image scanning reduces known build-time risk, while runtime monitoring catches code that appears only after deployment. If the threat involves downloaded payloads, credential theft, or post-start behaviour, runtime monitoring is the control that actually sees the compromise.
Technical breakdown
Why layered images hide secrets and misconfiguration
Docker images are built from stacked layers, and each layer can retain content that is no longer visible in the final filesystem view. That makes hard-coded secrets, build arguments, and earlier configuration mistakes recoverable even when the last image layer looks clean. Static scanning has to inspect the full layer history, not just the final artefact, because the security issue is persistence of embedded material. In identity terms, the image can carry credentials or trust assumptions forward long after developers believe they removed them. Practical implication: scan every image layer and build input before promotion, not just the final container filesystem.
Practical implication: inspect image layers and build inputs, not only the final container state.
How dependency scanning reduces hidden attack surface
Container image scanning also checks operating-system packages and language dependencies against vulnerability databases. That matters because the application code may never import a package directly, yet the package still expands the image attack surface once it is present. This is why container security scanning sits at the intersection of software composition analysis and image governance: it discovers what the image includes, not just what the application calls. The result is better control over inherited risk from base images, transitive libraries, and stale system packages. Practical implication: maintain an approved base-image and dependency review process tied to image promotion.
Practical implication: govern base images and transitive dependencies before image promotion.
Why runtime detection remains necessary after build-time checks
Build-time scanning cannot see every live abuse path. Runtime controls look for suspicious behaviour such as unexpected network traffic or an interactive shell inside a running container. That matters because compromise often appears as a change in execution pattern rather than a known vulnerable file. Runtime scanning therefore complements, rather than replaces, image analysis by detecting what static inspection cannot infer at build time. In practice, the security question becomes whether the container is behaving within its expected boundary after deployment. Practical implication: pair image scanning with runtime detection rules that flag shell access and unexpected egress.
Practical implication: add runtime rules for shell spawning and unexpected network activity.
Threat narrative
Attacker objective: The attacker aims to use content embedded in a container image to gain reuseable access, extend compromise beyond the container, or reach adjacent infrastructure.
- Entry begins when a malicious or neglected image contains hard-coded secrets, misconfigurations, or vulnerable dependencies that move into production with the container.
- Credential access occurs when exposed secrets inside image layers or configuration files can be extracted and reused against downstream systems.
- Escalation follows when weak container settings or vulnerable packages let an attacker move from container access toward host impact or broader service compromise.
- Impact is the exposure of sensitive systems, environment abuse, or container escape risk once the image content is trusted without full-layer inspection.
Breaches seen in the wild
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
- Carbonato botnet 2026: A botnet puts a Hermes AI agent on exposed Docker hosts to steal AI API keys, SSH keys and tokens, powering the operators' own LLM gateway.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Layer visibility, not just container runtime, is the governance gap: container images can preserve secrets and misconfigurations in layers that are no longer obvious in the final filesystem. That means the control failure is not simply weak scanning, but incomplete inspection of what the image actually contains. For NHI governance, that matters because leaked credentials and build arguments can survive packaging and outlive developer intent. Practitioners should treat the image as an identity-bearing artefact, not a neutral deployment package.
Container security scanning is really lifecycle control for embedded trust: the article is strongest when it shows that vulnerabilities arrive through base images, dependencies, and build configuration, then remain available to the runtime. That makes container governance a question of what was inherited, what was introduced, and what was never removed. In identity terms, the trust boundary sits at the image supply chain as much as at the running workload. Practitioners need continuous governance across build inputs, not isolated checks at release time.
Runtime detection closes the part of the problem static analysis cannot see: unexpected shells, network behaviour, and process changes reveal misuse after deployment. Static scanning can tell you what might be inside the image, but it cannot reliably prove how the container will behave once running. That gap matters because many container compromises are operational, not just artefact-based. The practical conclusion is that runtime controls must validate behaviour against the image's intended identity and function.
Container security scanning is a control family, not a single tool choice: the article compares secret scanning, misconfiguration scanning, vulnerability scanning, and runtime detection because each catches a different failure mode. That is the right model for modern container governance. No single scan type resolves identity leakage, package risk, and behavioural abuse at once. Practitioners should structure their programme around the failure mode they need to catch, not the scanner they already have.
Secret leakage inside images is a persistent identity risk, not a transient code issue: once a secret is embedded in a layer, the image can remain dangerous even after the application code changes. That makes container images a long-tail exposure surface for service credentials and API keys. The implication for teams is that cleanup has to happen at the artefact level, not only in source control or application code.
From our research library:
- Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
What this signals
Container governance is a lifecycle problem: the image can carry risk from build to runtime, which means teams need to review both the artefact and the behaviour it produces. The practical shift is away from one-time scanning toward continuous inspection of what enters the image and what the container does after launch.
Image-level secrets are especially dangerous because they survive packaging: once a credential is embedded in a layer, the container can remain exploitable long after the obvious source file is changed. That is why revocation, not just detection, has to be part of the workflow.
Runtime controls should focus on behaviour that reveals misuse: interactive shells, unexpected egress, and process anomalies are the operational signals that a container has moved outside its intended boundary. Teams that only scan artefacts will miss that live abuse path.
For practitioners
- Scan image layers before promotion Inspect Dockerfile instructions, build arguments, and every image layer for hidden secrets and insecure configuration before allowing a container into a release pipeline.
- Approve and standardise base images Maintain a short list of trusted base images and review package contents so inherited operating-system vulnerabilities do not enter the container estate by default.
- Treat secrets in images as incident material Revoke any credential found in a container image immediately, then trace where it was built, copied, and referenced across the build chain.
- Add runtime rules for container abuse Alert on interactive shells, unusual outbound network traffic, and unexpected process changes so live misuse is detected after deployment.
Key takeaways
- Container security scanning is necessary because Docker images can hide secrets, misconfigurations, and vulnerable packages that become production risk.
- The article's core lesson is that layered images and live containers require different control points, because static scanning and runtime detection answer different questions.
- Practitioners need both artefact governance and behavioural monitoring if they want containerised workloads to stay within their intended trust boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article focuses on secrets embedded in Docker image layers and build inputs. |
| NHI-06 — Insecure Cloud Deployment Configurations | Misconfigured Dockerfiles and image settings create the deployment risks discussed here. | |
| NHI-07 — Long-Lived Secrets | Hidden secrets remain exploitable after image build and deployment. | |
| Recommendation — Scan images for exposed secrets and revoke any credential found in the build chain. Review container build configuration before promotion and block insecure defaults from release. Eliminate embedded secrets from images and move credentials out of container artefacts. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Image secrets are authenticators that need lifecycle control and revocation. |
| Recommendation — Apply authenticator management to detect, rotate, and revoke credentials discovered in images. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article's secret exposure and runtime abuse paths depend on poor account and credential control. |
| Recommendation — Audit account and credential inventory for containerised workloads and remove stale access paths. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The breach pattern here is credential extraction from images followed by broader compromise. |
| Recommendation — Map exposed image secrets to credential access and lateral movement detections in your threat 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.
- Container Runtime Security: Container runtime security is the set of controls that monitor and limit what a container does after it starts running. It focuses on live process activity, file access, network behaviour, and privilege use, which is where many real attacks surface even when the image looked clean at deployment time.
- Image Scanning: Image scanning is the process of inspecting container images before deployment for known vulnerabilities, malware, misconfigurations, and risky dependencies. It helps teams catch problems early in the pipeline, before a flawed image reaches production and becomes harder to contain or remediate.
- Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
What's in the full article
GitGuardian's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of scanning Docker images for hard-coded secrets and misconfigurations
- Tool comparisons across ggshield, SecretScanner, trivy, clair, grype, and Falco
- Concrete command-line examples for image scanning and runtime alerting in container environments
- Practical notes on why layered images can hide secrets from the final filesystem view
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 1, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org