Topic starter
25/06/2026 2:44 pm
TL;DR: Kubernetes security gaps persist when unsigned or mutable images can still reach production, even as CI/CD and registry controls expand, according to Keyfactor. Code signing, immutable digests, and runtime signature verification shift trust from assumed pipeline integrity to governed, auditable identity.
Editorial analysis by NHI Mgmt Group, based on content published by Keyfactor: “Code Signing and Kubernetes Security Workflows: What You Need to Know”.
Key questions
Q: What breaks when Kubernetes trusts mutable image tags?
A: Mutable tags break provenance because the same reference can point to different content over time.
Q: Why do signed container images reduce risk in Kubernetes?
A: Signed images let the cluster verify that an artifact came from a governed build identity and was not changed after release.
Q: How can teams tell whether code signing is actually working in Kubernetes?
A: It is working when the cluster rejects unsigned, expired, or untrusted images before pods are scheduled, and when audit logs show which key signed each build.
Practitioner guidance
- Enforce immutable artifact references Require immutable digests for Kubernetes deployments so the cluster verifies the exact image that was built, not a tag that can be repointed later.
- Bind signing to governed build identity Issue signing certificates to controlled build systems, track ownership, and make revocation part of the build identity lifecycle.
- Move verification into admission control Configure admission controllers or policy engines to reject images with missing, expired, or untrusted signatures before scheduling.
Bottom line: Unsigned or mutable images create a provenance gap that Kubernetes cannot close by registry trust alone.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 3:50 pm
Code signing is now a governance control, not a packaging extra: Kubernetes security depends on being able to prove artifact origin at the point of execution. When tags are mutable and images are unsigned, the platform is trusting the delivery path rather than the software identity. The practitioner conclusion is that deployment trust must be enforced as policy, not assumed from pipeline success.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams manage signing certificates for build systems?
A: Treat signing certificates as governed non-human identities with clear ownership, issuance, rotation, revocation, and secure storage. If the private key is loose or the certificate lifecycle is unmanaged, the signature proves access to the key rather than trustworthy origin. HSMs and vaults reduce that exposure.
👉 Read our full editorial: Code signing and Kubernetes security workflows need stronger trust