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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Keyfactor's blog post: Kubernetes workflows need code signing because unsigned or mutable images can still slip into production when trust is anchored to tags instead of verified artifact identity.
Why it matters: It matters because platform, IAM, and NHI teams need enforcement points that bind build identity to deployment trust, not just pipeline speed and registry access.
Context
Kubernetes code signing is the practice of binding container images and related build artifacts to a verified identity so the platform can tell what was built, by whom, and under what authority. The governance problem is simple: if a cluster only trusts a tag, it is trusting a pointer, not the software itself.
In modern CI/CD-driven delivery, that gap matters because mutable images, ad hoc signing scripts, and scattered signing keys weaken the chain of custody between build and runtime. For identity programmes, the question is no longer limited to human access or service accounts; it extends to build identities, signing certificates, and the policy that decides what Kubernetes will run.
The article frames this as a trust and lifecycle problem rather than a pure infrastructure issue. That is typical for platform teams now using Kubernetes at production scale, because integrity controls have to move with the workload.
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. That means a deployment can be approved against one image and later run another if registry access or tag replacement occurs. Digest pinning and signature verification are the controls that stop that substitution path.
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. That matters because CI/CD speed does not equal trust. Signing turns provenance into an auditable control, while admission policy decides whether the runtime will accept the workload.
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. If deployments still rely on manual review or ad hoc scripts, the control is present in theory but not enforced in practice.
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.
Technical breakdown
Why mutable image tags break Kubernetes trust
A Kubernetes deployment trusts what the registry presents unless a stronger policy checks the artifact itself. Mutable tags make that trust fragile because the same tag can be repointed to a different image after scanning, which means provenance can be severed without changing the deployment manifest. Code signing counters that by binding a specific build output to a cryptographic identity, while immutable digests preserve the exact artifact reference. The operational issue is not only malware; it is substitution after approval, which is a governance failure as much as a technical one.
Practical implication: require immutable digests and signature verification so deployment policy evaluates the artifact, not the tag.
How build identities and signing keys become governance controls
Code signing shifts the question from whether a pipeline exists to whether the signing identity is governed. If a build system can request a certificate, sign artifacts, and store the corresponding private key without lifecycle control, then the signature proves little beyond access to the signing path. In this model, certificate issuance, rotation, revocation, and secure key storage are part of the identity fabric, not a separate hygiene task. That is why HSMs, key vaults, and certificate automation matter: they keep the signing authority auditable and reduce the chance that a compromised key becomes a standing trust root.
Practical implication: treat signing certificates and private keys as governed NHI assets with explicit issuance, rotation, and revocation rules.
Why Kubernetes admission control is the real enforcement point
Verification only changes outcomes when the cluster refuses to run untrusted images. Admission controllers and policy engines provide that enforcement layer by checking signature validity, trust bundles, certificate status, and policy conditions before a pod is scheduled. This matters because a signed image that is never checked at runtime still relies on human discipline, while an admission policy converts trust into an executable rule. The article also points to multi-cluster consistency, which is essential because manual trust drift across environments can quietly undo the value of signing.
Practical implication: move signature validation into admission control so enforcement happens before scheduling, not after deployment.
Threat narrative
Attacker objective: The attacker wants an unverified or tampered container image to execute in Kubernetes as if it were approved software.
- Entry occurs when a developer builds an image and the pipeline pushes it to a registry without cryptographic proof of origin.
- Escalation happens when a registry-access holder or compromised pipeline can replace or re-push the same mutable tag and still pass downstream trust checks.
- Impact follows when Kubernetes schedules the wrong image into production, turning a provenance failure into a live workload compromise.
Breaches seen in the wild
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
- 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
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.
Signing key sprawl creates an identity problem inside the build system: The article is really describing a machine identity lifecycle issue, because the signing authority itself must be issued, protected, rotated, and revoked like any other privileged non-human identity. If that lifecycle is ad hoc, the signature becomes a weak proxy for trust instead of a governed proof of origin. Practitioners should treat build signing credentials as controlled identity assets with auditable ownership.
Immutable digests and runtime verification define the minimum viable trust boundary: A digest locks the artifact reference, while admission control decides whether the cluster will accept it. That combination matters because scanning alone cannot stop substitution after approval. The practical implication is that Kubernetes security programmes need both provenance and enforcement, or they remain vulnerable to tag-based bypass.
Trust bundles are a cross-cluster consistency problem: The article surfaces a common governance failure where different environments quietly enforce different trust rules. That inconsistency weakens compliance, complicates incident response, and creates hidden exceptions that attackers can exploit. The practitioner conclusion is to standardise trust distribution across clusters so verification means the same thing everywhere.
Crypto-agility is part of workload identity maturity: Signing systems cannot be frozen around one algorithm or one certificate lifecycle assumption. As cryptography evolves, organisations need a process that can update trust without breaking deployments or creating emergency exceptions. The implication for identity teams is that workload trust has to be managed as a living control plane, not a one-time configuration.
From our research library:
- 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.
- Read next: CI/CD Pipeline Identity Security Guide
What this signals
Artifact trust is becoming a workload identity problem: Kubernetes teams increasingly have to decide whether the platform is validating a package label or a governed build identity. That distinction matters because signature verification only works when the same trust rule follows the image from build to registry to cluster.
Supply chain controls now sit on the same path as IAM controls: If the build system can sign artifacts, then signing certificates, key storage, and revocation belong in the same governance conversation as privileged access and workload identity. The programme risk is not just compromise, but inconsistent enforcement across environments.
Code signing and admission policy are complementary controls: One proves origin, the other decides whether the cluster will execute the image. Together they narrow the attack surface that mutable tags and registry access create; without both, the trust boundary remains too easy to bypass.
For practitioners
- 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.
- Centralise signing key protection Store private signing keys in HSMs or integrated vaults and rotate them on a defined schedule so compromise does not become persistent trust.
- Standardise trust bundles across clusters Distribute the same trust anchors and certificate metadata to every cluster so verification policy stays consistent across on-premise, cloud, and hybrid environments.
Key takeaways
- Unsigned or mutable images create a provenance gap that Kubernetes cannot close by registry trust alone.
- The control problem is both technical and governance-driven because build identities, signing keys, and cluster policy all affect runtime trust.
- Immutable digests, governed signing identities, and admission control together shift Kubernetes from assumed trust to enforced verification.
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 SP 800-53 Rev 5, 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-02 — Secret Leakage | Signing keys and trust material are treated as protected identity assets in this workflow. |
| NHI-05 — Overprivileged NHI | Build systems that can sign and publish artifacts need tightly bounded authority. | |
| NHI-07 — Long-Lived Secrets | The article stresses certificate rotation and revocation to prevent stale signing trust. | |
| Recommendation — Scan build and registry paths for exposed signing material and revoke any leaked credentials immediately. Restrict signing and publishing rights to the smallest build identities that actually need them. Rotate signing credentials on a defined lifecycle and retire expired trust before deployment use. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Signing credentials and certificates need lifecycle management consistent with authenticator controls. |
| Recommendation — Apply authenticator lifecycle controls to issue, rotate, and revoke signing credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Cluster enforcement depends on restricting which identities may produce trusted artifacts. |
| Recommendation — Use authorization policy to ensure only approved build identities can create deployable artifacts. | ||
| CIS Controls v8 | CIS-5 — Account Management | The workflow depends on managing the build and signing accounts that create release trust. |
| Recommendation — Inventory and govern build accounts so signing authority does not become uncontrolled access. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Compromise of CI/CD or signing credentials can enable downstream deployment abuse. |
| Recommendation — Map pipeline and signing compromise paths to credential access and lateral movement detection. | ||
Key terms
- Code signing: Code signing is the process of attaching cryptographic proof to software so recipients can verify origin and integrity. In CI/CD, it turns release trust into an enforceable control instead of a human promise, and it only works when the signing step is mandatory and protected.
- Immutable Digest: An immutable digest is a content-based identifier for a container image that cannot be repointed to a different binary. It reduces substitution risk by making the deployment reference describe the exact artifact rather than a mutable tag or label.
- Admission Controller: An admission controller is a Kubernetes control that validates or changes workload requests before the cluster admits them. It acts as a deployment-time policy layer, which makes it useful for blocking unsafe images, rejecting risky configuration, and enforcing runtime standards that build-time scans may miss.
- Signing Credential Lifecycle: The signing credential lifecycle covers issuance, storage, use, monitoring, rotation, revocation, and retirement of certificates, keys, and related authenticators. For document trust, lifecycle control determines whether a signature remains reliable after the original signing event.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 25, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org