Code signing for containers closes zero trust gaps in supply chains

At a glance

What this is: This article argues that code signing for containers reduces supply chain risk by binding image identity and integrity to verifiable signatures.

Why it matters: It matters because IAM, PAM, NHI, and DevSecOps teams all need provable provenance, key governance, and consistent enforcement before container trust can scale.

👉 Read Keyfactor's analysis of code signing for container security

Context

Container security breaks down when teams treat registry content as trustworthy by default. In practice, the issue is not just image volume. It is whether the organisation can verify that a container image, chart, or manifest really came from the expected source and was not altered in transit or in the registry.

That is an identity governance problem as much as a software supply chain problem. Signing moves the control point from implicit trust to cryptographic proof, which affects NHI governance for signing keys, PAM for high-risk key access, and zero trust enforcement in CI/CD and deployment pipelines.

Key questions

Q: How should security teams enforce code signing for container images?

A: Security teams should enforce signature verification at registry admission and deployment time, not just in the build stage. The control only works when unsigned or altered artifacts are blocked before they can run. Teams should pair enforcement with clear ownership, exception handling, and audit logs so provenance is consistently provable across delivery pipelines.

Q: Why do signing keys need the same governance as other privileged secrets?

A: Signing keys can authorise code that downstream systems treat as trusted, which gives them privileged blast radius. If those keys are exposed or loosely managed, attackers can generate rogue but authentic-looking artifacts. Treat them as high-value secrets with restricted access, strong storage, and full auditability.

Q: What breaks when container signing is optional across teams?

A: Optional signing creates patchwork policy, which lets unsigned images reach production through the least disciplined pipeline. That fragment is enough to undermine organisation-wide provenance. Central enforcement matters because trust at scale depends on one standard, not on isolated team habits.

Q: How do organisations know if container signing is actually working?

A: They should look for consistent signature verification at admission, complete audit trails for signing events, and a low number of policy exceptions. If unsigned images still reach production or key usage is hard to trace, the control exists in theory but not in practice.

Technical breakdown

Container image signing and provenance

Container image signing attaches a cryptographic signature to an image, chart, or manifest so downstream systems can verify origin and integrity. The private key creates the signature and the public key verifies it. In governance terms, the signature is only useful if the signing identity is controlled, the key is protected, and validation happens before the artifact is admitted into the environment. That is why signing is not just a build step. It is a provenance control that helps distinguish approved artifacts from tampered or forged ones.

Practical implication: require signature verification at registry admission and deployment time, not just during build.

Why key protection is the control point

The security value of signing depends on the signing key remaining under strict control. If a key lives on a developer laptop or in an exposed workflow, an attacker can create rogue but apparently authentic images. That turns signing into a false assurance layer. This is where NHI governance and PAM intersect: signing keys are privileged non-human credentials and should be handled like other high-value secrets, with strong storage, limited access, and auditable use.

Practical implication: move signing keys into controlled secret storage or hardware-backed protection with restricted operator access.

Policy enforcement across DevOps teams

Code signing fails as a governance model when one team signs and another skips the step. Patchwork adoption creates blind spots because unsigned artifacts can still reach production if enforcement is inconsistent. Central policy is what turns signing from a best effort into a control. Frequent audits matter because they reveal whether the same rules apply across teams, pipelines, and environments. Without that consistency, the organisation cannot prove provenance at scale.

Practical implication: centralise signing policy and audit exceptions so unsigned images cannot drift into production.

Threat narrative

Attacker objective: The attacker aims to distribute malicious workloads that look legitimate enough to bypass trust controls and execute inside production.

1. Entry occurs when an attacker slips a poisoned image into a public registry or alters build artifacts inside a CI/CD server before release.
2. Escalation occurs when the unsigned or falsely trusted artifact is propagated into multiple services, or when stolen signing keys are used to mint rogue images that appear authentic.
3. Impact is the spread of compromised workloads across production, increasing the chance of data theft, malware execution, or operational disruption.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• 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

Code signing is a provenance control, not a substitute for governance. The article correctly frames the problem as trust in artifacts, but that trust only holds when signing keys, verification points, and policy enforcement are all governed together. A signed image that no one verifies is still an unaudited risk path. The practitioner conclusion is simple: treat signing as part of the identity control plane for software delivery, not as a stand-alone security feature.

Signing keys are non-human identities with privileged blast radius. Once a signing key can authorise code that downstream systems trust, it behaves like a high-value NHI credential. That means the same governance questions apply as with any sensitive secret: where the key lives, who can use it, how use is logged, and how quickly it can be revoked if exposed. The implication is that signing infrastructure belongs in the same control conversation as secrets management and PAM.

Patchwork signing policies create governance gaps that attackers can exploit. The article’s team-by-team example shows how inconsistent controls let unsigned images creep into production even when some teams are disciplined. That is not just a process weakness. It is a policy fragmentation problem that undermines central assurance. The practitioner conclusion is that container trust must be enforceable across the organisation, not optional within individual DevOps teams.

Zero trust for containers depends on verification at the point of use. The zero trust principle only works here if every deployment decision can verify the artifact’s identity and integrity before it is admitted. Relying on repository trust, developer reputation, or upstream assumptions recreates the same blind spots zero trust is meant to remove. The implication is that provenance checks need to sit where workload admission actually happens.

Automated certificate lifecycle is where trust at scale becomes operational. The article’s lifecycle point is the right one: manual signing can protect a pilot, but not a modern delivery pipeline. Trust at scale depends on automation that preserves control while reducing deployment friction. The practitioner conclusion is that certificate lifecycle governance has to be built into the workflow, or container signing will remain inconsistent and slow.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which shows how easily key handling can drift away from policy.
• For a broader control-plane view, Guide to SPIFFE and SPIRE explains how workload identity and attestation support trust boundaries beyond container signing.

What this signals

Signing controls will keep failing wherever key governance is treated as a build concern rather than an identity concern. In practice, the organisations that mature fastest are the ones that manage signing keys as privileged non-human credentials, with lifecycle discipline and access logging. The same governance pattern that protects workload identity also protects software provenance, which is why Guide to SPIFFE and SPIRE is relevant for teams designing trust at runtime.

Container trust is moving toward stronger admission control, not softer developer trust. That shift matters because provenance checks have to survive team variation, pipeline sprawl, and emergency releases. When certificate handling is weak, the control becomes ceremonial instead of preventive, which is why the operational focus should stay on verification, revocation, and exception control rather than on the signing event itself.

Secret-handling maturity remains a leading indicator for whether code signing will work at scale. Our research shows a 27-day average time to remediate a leaked secret, and that delay is the kind of operational gap that can expose signing infrastructure as well. When secret response is slow, provenance controls inherit the same weakness, so container programmes need to improve key governance and workflow discipline together.

For practitioners

• Enforce signature verification at admission Block unsigned or untrusted images before they reach registries, cluster admission controllers, or deployment stages. Verification has to happen where workload trust is decided, not after the container is already running.
• Protect signing keys as privileged secrets Store signing keys in hardened secret systems or hardware-backed protection, limit access to a small operator set, and log every signing event for review.
• Centralise policy across DevOps teams Apply one signing standard across all delivery teams, then audit exceptions so unsigned artifacts cannot enter production through inconsistent local practice.
• Automate certificate lifecycle governance Automate issuance, rotation, revocation, and expiry handling so signing remains reliable at pipeline speed and does not depend on manual handling.

Key takeaways

• Container code signing reduces supply chain risk only when identity, integrity, and policy enforcement are governed together.
• Signing keys behave like privileged non-human identities, which means weak key storage can turn provenance controls into a false assurance layer.
• Teams should enforce verification at admission, centralise policy, and automate certificate lifecycle handling before unsigned artifacts become an operational norm.

Key terms

• Code Signing: Code signing is the process of attaching a cryptographic signature to software so others can verify its origin and integrity. In container workflows, it helps prove that an image, chart, or manifest came from the expected source and was not altered after signing.
• Signing Key: A signing key is the private credential used to create a code signature. It is a privileged non-human identity asset because whoever controls it can authorise code that downstream systems may trust, so access, storage, and revocation need strict governance.
• Artifact Provenance: Artifact provenance is the evidence that shows where a piece of software came from and how it was produced. It becomes operationally useful when organisations can verify origin, integrity, and chain of custody before the artifact is deployed.
• Admission Control: Admission control is the decision point that determines whether software or workloads are allowed into an environment. For signed containers, it is the gate where verification should happen so untrusted artifacts are blocked before execution.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Keyfactor: Code Signing Zero Trust in Action: How Code Signing Benefits Container Security. Read the original.