TL;DR: Container security has moved beyond image scanning to build-to-runtime context, with OXSecurity arguing that the riskiest issues usually begin in pipelines, registries, or code and only matter when they are reachable in production. The practical shift is toward provenance, exploitability, and runtime correlation rather than raw CVE volume.
At a glance
What this is: OXSecurity argues that container security is shifting from image-only scanning to build-to-runtime context, because the most consequential risks are often introduced before deployment and only become meaningful when they are reachable at runtime.
Why it matters: This matters to IAM, PAM, AppSec, and platform teams because container risk increasingly sits in pipeline integrity, secrets handling, and runtime reachability, not just in the presence of vulnerable packages.
Context
Container security is the practice of protecting how container images are built, deployed, and run. The article argues that image scanning alone is too narrow because it misses where risk is introduced, whether a flaw is reachable, and how issues propagate through the pipeline into production.
That creates a direct governance problem for cloud and application teams, and a real identity angle where build systems, registries, service accounts, and secrets now shape the attack surface. In practice, the control gap is not just vulnerability discovery, but traceability across code, build, and runtime.
The article's starting position is typical of modern containerised estates: teams have many alerts but limited context, so they struggle to separate exploitable findings from background noise.
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 pipeline credentials and registry trust matter so much for container security?
A: Because build systems are now part of the attack surface, and they can introduce secrets, altered images, or unverified dependencies long before runtime controls see anything. If pipeline identities are overprivileged or poorly governed, attackers can turn the software delivery chain into a production compromise path.
Q: How do you know if a container vulnerability is actually exploitable?
A: Look for runtime evidence that the affected component is loaded, the vulnerable path is reachable, or the workload exposure makes exploitation plausible. If the issue exists only in a dormant layer or an unused dependency, it is lower priority than a finding that is active in a production service.
Q: Should container teams prioritise provenance or runtime detection first?
A: They need both, but provenance should come first when the source of the artifact is uncertain, while runtime detection becomes decisive once workloads are deployed. Provenance tells you who created the risk, and runtime telemetry tells you whether it has become operationally relevant.
Technical breakdown
Why image scanning misses exploitable container risk
Image scanners answer a limited question: what vulnerabilities are present in a packaged artifact. They do not show whether the vulnerable component is loaded, whether the code path is reachable, or whether the flaw exists in a base layer, a Dockerfile instruction, or a dependency added later in the build. That means two images with the same CVE can have very different operational risk. The article's core point is that context has to travel with the finding, from commit to build step to workload. In security terms, this is the difference between inventory and exploitability.
Practical implication: prioritise reachability and runtime exposure before treating a container finding as production risk.
How pipeline provenance changes container governance
Build provenance records where a container came from, who produced it, and which pipeline steps touched it. That matters because many container issues begin upstream, where secrets leak into Dockerfiles, insecure changes enter CI/CD, or third-party images are pulled without strong verification. Without provenance, teams can see a vulnerable image but cannot confidently trace ownership or remediation path. Provenance also supports better change accountability, because the fix belongs to the build chain as much as to the runtime environment. In a mature programme, provenance is not documentation after the fact, but an input to security decision-making.
Practical implication: tie each container finding back to commit, build step, and owner so remediation can happen at source.
Why runtime context outperforms pre-deploy noise
Runtime context tells you whether a vulnerability or misconfiguration is actually active in a live workload. A container that never starts the affected process, never exposes the risky port, or never reaches the vulnerable library path is materially different from one that does. This is why scheduling scans alone fails in fast-moving environments: the environment changes before the next scan cycle. Runtime signals also reveal behaviour that static scanning cannot, such as unexpected outbound connections or lateral communication between pods. The article's underlying message is that security value rises sharply when detection is connected to operational context, not just artifact state.
Practical implication: combine runtime telemetry with build findings so teams can focus on active exposure rather than theoretical weakness.
Threat narrative
Attacker objective: The attacker aims to turn trusted build machinery and container distribution into a route for secret theft, workload compromise, or production-level abuse.
- Entry begins in the build and delivery pipeline, where leaked secrets, unsafe image changes, or unverified dependencies can be introduced before deployment.
- Credential access and persistence can follow when attacker-controlled pipeline changes expose tokens, registry trust, or build-time secrets that survive into images.
- Impact occurs when a malicious or misconfigured container reaches production with reachable vulnerabilities, exposed services, or altered behaviour that affects workloads.
Breaches seen in the wild
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
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
Build-to-runtime context is the real container security control boundary. Image scanning still matters, but it is no longer sufficient because it cannot tell teams whether a flaw is reachable, active, or introduced by an upstream build decision. The decisive governance question is now provenance plus exploitability, not just vulnerability inventory. Practitioners should treat container security as a continuous chain of custody problem, not a one-time scan problem.
Pipeline identity is now part of container risk governance. The article's most important identity implication is that CI/CD systems, registry credentials, and build service accounts sit on the path to production. That makes non-human identity governance central to container assurance, because a weak build principal can introduce secrets, malicious images, or configuration drift before any runtime control sees it. Teams should govern pipeline identities with the same discipline they apply to production access.
Alert fatigue is not a tooling nuisance, it is a prioritisation failure. When every scan produces thousands of findings, teams lose the ability to separate exploitable exposure from background noise. The named concept here is container context collapse, where disconnected findings, missing provenance, and absent runtime linkage erase the evidence needed to act. Practitioners should reduce this collapse by insisting on reachability, ownership, and workload context for every high-priority finding.
Supply-chain controls are now part of container runtime defence. The article shows that pulling images from registries without provenance or signature verification leaves organisations exposed to upstream compromise. That makes registry trust, image integrity, and dependency provenance operational controls, not just compliance concerns. Security teams should fold container supply-chain review into their standard governance model rather than treating it as a separate specialist check.
Modern container security is converging with application and identity governance. The boundary between AppSec, platform security, and IAM has thinned because images, pipelines, secrets, and workloads now form one attack path. That means governance models that isolate these teams will miss the combined risk. Practitioners should organise control ownership around the container lifecycle, not around tool silos.
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 context collapse: when build, registry, and runtime signals are disconnected, teams cannot separate genuine exposure from scanner noise. The practical response is to collapse those layers back into one governance view, with ownership, provenance, and workload context attached to each finding.
Pipeline identities now deserve the same lifecycle discipline as privileged human accounts because they can create, sign, promote, or alter container artefacts at scale. For IAM and PAM teams, that means treating CI/CD service accounts as governed production identities rather than engineering conveniences.
For practitioners
- Prioritise reachable container findings Rank vulnerabilities by runtime exposure, active process use, and business-critical workload impact before assigning remediation effort.
- Trace findings back to build provenance Require every high-severity image issue to map to the commit, pipeline stage, and owner that introduced it.
- Harden CI/CD service account controls Limit pipeline credentials to the minimum build and registry actions needed, and rotate them like any other production-grade NHI secret.
- Verify registry trust before promotion Block image promotion when signatures, source lineage, or dependency origin cannot be confirmed for the artifact.
- Correlate runtime behaviour with build findings Use runtime telemetry to confirm whether a reported vulnerability, port, or library is actually active in deployed workloads.
Key takeaways
- The article argues that container security fails when teams stop at image scanning and ignore build provenance, registry trust, and runtime reachability.
- The main risk is not the existence of vulnerabilities alone, but the inability to tell which findings are active in production and which are background noise.
- Practitioners should organise container governance around provenance, pipeline identity, and runtime evidence so remediation targets the issues that can actually affect workloads.
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 CSF 2.0 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-03 — Vulnerable Third-Party NHI | Build pipelines and registries are third-party trust paths that can introduce compromised container artefacts. |
| NHI-02 — Secret Leakage | The article repeatedly cites leaked secrets in Dockerfiles and pipelines as a container entry risk. | |
| Recommendation — Inventory and verify third-party build inputs before promoting container images into production. Scan build pipelines and image layers for exposed secrets and revoke any leaked credentials immediately. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The source describes pipeline compromise, secret theft, and malicious image propagation as the attack pattern. |
| Recommendation — Map container build abuse to credential access and exfiltration techniques so detections cover both theft and propagation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Pipeline service accounts and registry access need tight entitlement control across the container lifecycle. |
| Recommendation — Apply least-privilege entitlements to build, registry, and deployment identities that can alter container artefacts. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article's identity angle centers on managing container pipeline accounts and their access scope. |
| Recommendation — Review and remove standing access from CI/CD and registry accounts that create or promote container images. | ||
Key terms
- Build-to-Runtime Context: Build-to-runtime context is the security view that connects how an image was created, what it contains, and how it behaves after deployment. It helps teams separate theoretical vulnerability lists from findings that are actually reachable, traceable, and relevant in production.
- Build provenance: Build provenance is the evidence chain showing where a software artefact came from, how it was assembled, and which identities and keys were used. It is essential when teams need to prove that an embedded release was produced from trusted source and controlled inputs.
- Runtime Reach: The total set of identities, repositories, tools, memory paths, and services an autonomous system can actually access while executing a task. It is broader than the workflow that was originally approved, and it determines the real governance boundary for agent behaviour.
- Pipeline identity: A pipeline identity is the non-human identity a CI/CD workflow uses to authenticate to cloud, source control, secrets systems, and deployment targets. These identities are often overprivileged because they must automate multiple steps. That makes them high-value targets and a central concern in supply chain security.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives IAM, PAM, and security practitioners a common foundation for governing the identities that drive modern delivery pipelines and workloads.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org