Container security and software supply chain trust: IAM implications

At a glance

What this is: This is an analysis of container security at scale, with a focus on how software supply chain trust breaks down when builds, dependencies, and runtime controls are not tightly governed.

Why it matters: It matters because NHI and IAM teams increasingly have to govern signing keys, build identities, and deployment policies across containerized delivery pipelines.

👉 Read CyberArk's analysis of container security and software supply chain trust

Context

Container security now sits at the intersection of software supply chain assurance, identity, and operational control. As containerized delivery becomes the default, the core issue is no longer only whether code runs, but whether the artifact being deployed can be trusted across build, distribution, and runtime stages. That makes the topic directly relevant to NHI governance because signing keys, pipeline identities, and automated deployment actors all behave like non-human identities with access authority.

The article frames a familiar problem in a newer shape: faster development, broader open-source reuse, and AI-generated code expand the number of places where trust can fail. That is not unusual anymore. What is unusual is how quickly those trust decisions now propagate into production, which means container security decisions increasingly belong in IAM, PAM, and policy governance conversations, not only in application security reviews.

Key questions

Q: How should security teams govern signing keys in container pipelines?

A: Security teams should treat signing keys as privileged NHI assets. Restrict who can use them, separate signing from deployment authority, store keys in controlled systems, and rotate or revoke them on a defined schedule. Without key governance, signing only proves that a trusted identity was compromised or misused.

Q: Why do signed containers still need runtime policy checks?

A: Signed containers still need runtime checks because a valid signature does not guarantee the artifact is appropriate for the target environment. Runtime policy enforces context, provenance, and deployment rules at the moment of execution. That closes the gap between build-time trust and operational trust, which is where many supply chain failures occur.

Q: What is the difference between provenance and integrity in container security?

A: Integrity means the artifact has not been altered since it was signed or produced. Provenance means you can trace where it came from, who approved it, and which controls were applied. Both matter, but provenance is stronger for governance because it helps teams decide whether a container should be trusted, not just whether it was changed.

Q: How can teams reduce risk from AI-generated code in supply chains?

A: Teams should apply the same provenance and review expectations to AI-generated code as they do to third-party dependencies. That means verifying source, tightening review on generated changes, and blocking untrusted artifacts from reaching deployment. The goal is to prevent automation from scaling uncertainty faster than governance can absorb it.

Technical breakdown

Cryptographic signing in container supply chains

Cryptographic signing creates a verifiable link between an artifact and the identity that approved it. In container workflows, a signature does not make code safe by itself. It proves origin and detects tampering after the fact, which is useful only when trust policies are enforced at admission or deployment time. The real control point is not the signature alone, but the policy that decides whether a signed image may move from build to runtime. In practice, signing also depends on protecting the keys or certificates used to generate signatures, because compromised signing identities collapse the whole trust model.

Practical implication: Treat signing identities and their keys as high-value NHI assets, not as build tooling details.

Runtime verification versus build-time assurance

Build-time controls tell you what should have been produced. Runtime verification tells you what is actually allowed to execute. Those are different security questions, and container environments need both because the gap between build and deployment is where tampering, process drift, and policy exceptions often enter. A signed artifact can still be deployed in the wrong context if runtime policy is weak. Conversely, strict runtime controls without trustworthy build provenance create blind confidence. The architectural pattern that matters is admission control tied to verified provenance, with continuous policy enforcement as containers move through environments.

Practical implication: Require deployment gates that validate provenance at the moment of release, not only during CI.

Why open-source and AI-generated code expand supply chain risk

Open-source reuse broadens dependency chains, while AI-generated code adds a second layer of uncertainty because its origin, review history, and intent can be harder to trace. Both increase the number of component-level trust decisions made before software reaches production. That creates a governance problem for enterprises: the more automated the pipeline, the easier it is for unverified code to slip through if controls rely on developer discretion alone. The technical risk is cumulative. Each dependency, generated snippet, and transitive package becomes another place where artifact integrity must be proven, not assumed.

Practical implication: Extend review, provenance, and policy checks to generated code and transitive dependencies, not just first-party code.

Threat narrative

Attacker objective: The attacker wants to turn a trusted delivery pipeline into a distribution channel for malicious or tampered container artifacts.

1. Entry occurs through compromised or unverified build inputs, including open-source dependencies or generated code that enters the pipeline without strong provenance checks.
2. Escalation happens when a tampered artifact is signed, blessed, or promoted by a trusted pipeline identity that has standing authority.
3. Impact is achieved when the altered container is deployed into runtime environments that trust signatures more than they verify context.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 trust is now an identity problem disguised as a build problem. The article is correct to focus on signing and policy, but the deeper issue is who or what is allowed to authorise a container artifact at each stage. Build systems, CI/CD runners, signing services, and deployment controllers are all non-human identities with delegated power. Practitioners should govern those identities with the same scrutiny they apply to privileged human accounts.

Cryptographic signing only works when the signing identity is protected. A signed image is not a security outcome if the keys, certificates, or signing service are over-privileged or poorly monitored. This is where NHI governance becomes practical: limit signing authority, separate duties, and make revocation routine. The decision point for teams is whether signatures are treated as evidence or as a substitute for control.

Runtime policy closes the trust gap that build-time controls cannot. Container pipelines create multiple handoff points, and each handoff can weaken provenance unless deployment policy enforces it. That is why admission control, runtime verification, and exception handling must be governed as one chain. Practitioners should align security policy with the moment of execution, not just the moment of build.

AI-generated code adds provenance ambiguity that traditional software controls were not designed to absorb. The issue is not simply that generated code may contain defects. It is that its lineage, review depth, and dependency inheritance can be opaque, which complicates trust decisions in both the pipeline and runtime. Teams should assume that AI-assisted development increases the volume of untrusted material that must be verified before deployment.

Container supply chain security will increasingly converge with NHI governance and compliance. The article points in the right direction by linking signing to auditability and policy, but the operational reality is broader. Organisations will need inventory, ownership, lifecycle, and revocation models for machine-held trust assets. Practitioners should expect supply chain governance to become a board-level identity issue, not just a release engineering concern.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, showing how quickly new interfaces create new credential exposure points.
• 52 NHI breaches Analysis shows that identity and secret failures repeatedly turn supply chain issues into enterprise incidents.

What this signals

Ephemeral trust does not remove trust debt. Container teams often assume that short-lived build or deploy credentials are safer by default, but the operating reality is that revocation and attribution still matter after the artifact moves. With 64% of valid secrets leaked in 2022 still exploitable today, per The State of Secrets Sprawl 2026, the programme risk is not just leakage but persistence.

Security leaders should expect container governance to merge with broader machine-identity controls. Signing services, CI/CD runners, deployment controllers, and policy engines are all part of the same trust chain, and weaknesses in one stage will be inherited by the next. Aligning with the OWASP Non-Human Identity Top 10 gives teams a practical way to prioritise those controls.

Identity blast radius: the real unit of measure in container supply chains is how far one compromised signing or deployment identity can move. Practitioners should prepare for tighter separation of duties, narrower privileges, and faster revocation workflows across build and runtime systems.

For practitioners

• Inventory signing identities and artifact authorities Map every service, key, certificate, and pipeline actor that can approve or promote container artifacts. Classify which ones can sign, which ones can only attest, and which ones can deploy to production. Reduce standing authority where possible and require named ownership for each identity.
• Enforce provenance checks at admission time Require cluster or platform policies that validate signatures, source provenance, and environment rules before deployment. Do not rely on CI success as proof that a container may run. Tie policy to the actual release boundary so unverified images are blocked at the point of execution.
• Separate signing from deployment authority Make sure the identity that creates a signature is not the same identity that can override deployment controls. Use distinct roles for build, sign, approve, and release, and log every exception. Separation of duties lowers the chance that one compromised NHI can push a malicious artifact end to end.
• Extend governance to AI-generated and third-party code Require additional review for generated code, transitive packages, and dependency updates before they enter the release path. Add policy checks for source provenance and maintain a revocation process when a dependency, token, or signing key is suspected of compromise.

Key takeaways

• Container supply chain security is increasingly a governance problem because build, sign, and deploy actions are performed by non-human identities with delegated authority.
• Cryptographic signing helps only when keys, certificates, and runtime policy are managed as part of one trust chain rather than as isolated technical controls.
• Teams should focus on provenance, separation of duties, and runtime enforcement to reduce the blast radius of compromised artifacts and pipeline identities.

Key terms

• Cryptographic Signing: Cryptographic signing attaches a verifiable identity to a container image or artifact. It lets systems detect tampering and confirm origin, but it only creates security value when the signing identity is protected and runtime policy decides whether the artifact may deploy.
• Provenance: Provenance is the traceable history of where a software artifact came from, who approved it, and what controls were applied along the way. In container security, provenance supports trust decisions because it links delivery steps to accountable identities and review points.
• Runtime Verification: Runtime verification is the control layer that checks whether a container is allowed to execute in a specific environment. It goes beyond build assurance by enforcing context, policy, and admission rules at deployment time, which is essential when pipelines handle many automated identities.
• Signing Identity: A signing identity is the non-human identity, key, or certificate used to authorise an artifact. It is a privileged trust asset because whoever controls it can influence what downstream systems accept as legitimate, so its lifecycle must be tightly governed.

Deepen your knowledge

Container supply chain trust and signing governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are mapping build, sign, and deploy identities into a control model, it is worth exploring.

This post draws on content published by CyberArk: Container security at scale, strengthening software supply chains. Read the original.