Notifications
Clear all
Topic starter
25/06/2026 2:51 pm
TL;DR: Unsigned or tampered container images can enter production through poisoned registries, compromised CI/CD systems, stolen signing keys, and inconsistent team practices, according to Keyfactor. Code signing turns identity and integrity into verifiable controls, but trust still depends on key protection, policy enforcement, and lifecycle discipline.
NHIMG editorial — based on content published by Keyfactor: Code Signing Zero Trust in Action: How Code Signing Benefits Container Security
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Enforce signature verification at admission Block unsigned or untrusted images before they reach registries, cluster admission controllers, or deployment stages.
- 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.
What's in the full article
Keyfactor's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step container signing workflow examples for build and release pipelines.
- Operational guidance on protecting signing keys with hardware-backed storage or vault controls.
- Policy enforcement patterns that help teams keep unsigned artifacts out of production.
- Lifecycle automation detail for certificate issuance, rotation, and revocation at scale.
👉 Read Keyfactor's analysis of code signing for container security →
Container image signing: what it means for IAM and DevSecOps?
Explore further
25/06/2026 4:02 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Code signing for containers closes zero trust gaps in supply chains
