What breaks when container signing is optional across teams?

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.

Why This Matters for Security Teams

When container signing is optional, trust becomes a team-by-team preference instead of a platform property. That is not a minor governance gap. It means one pipeline can enforce provenance while another quietly admits unsigned images, leaving production risk determined by the weakest process. The result is inconsistent attestation, weaker incident response, and no reliable way to prove what actually shipped.

Security teams often discover this only after a build path has already bypassed the stronger controls. That is why central policy matters more than local discipline. The problem is similar to what NIST treats as a baseline governance issue in the NIST Cybersecurity Framework 2.0: if an organisation cannot establish consistent control enforcement, it cannot claim consistent trust. NHIMG research on DeepSeek breach shows how quickly sensitive artefacts can spread once controls fail at the source. In practice, many security teams encounter unsigned images only after a lower-maturity pipeline has already promoted them into a shared runtime.

How It Works in Practice

Container signing is meant to create a verifiable chain from build to deployment. The build system signs the image, the registry stores the signature or attestation, and admission control checks that proof before the workload starts. If signing is optional, that chain fractures. Some teams enforce signature verification, some only warn, and some skip it entirely. The business effect is simple: the organisation no longer knows whether an image was produced by a trusted build process or by an uncontrolled one.

Operationally, the weakest path usually wins. A team with release pressure can route around signing, and once that exception exists, it becomes difficult to reject similar exceptions elsewhere. Mature programmes pair signing with mandatory policy checks, immutable registries, and deployment gates tied to provenance, not developer preference. That aligns with current guidance in the NIST Cybersecurity Framework 2.0 and with broader supply chain discipline discussed in NHIMG’s The State of Secrets in AppSec, where fragmented controls are shown to undermine centralised oversight. A useful implementation pattern is:

• Require signatures for all production and staging admissions.
• Reject unsigned images by default, with no team-level exceptions outside a formal break-glass process.
• Bind signatures to build identity and artifact digest, not just to a repository label.
• Verify provenance at deploy time, not only during CI.

These controls tend to break down when multiple clusters, registries, or platform teams apply different admission rules because policy drift quickly creates an unsigned-image back door.

Common Variations and Edge Cases

Tighter signing enforcement often increases release friction, requiring organisations to balance delivery speed against supply chain assurance. That tradeoff is real, especially during migration from legacy pipelines or when external vendors deliver images that cannot yet be signed consistently. Current guidance suggests treating those cases as exceptions with expiry dates, not as permanent policy gaps.

There is no universal standard for every signing stack, but the control objective is stable: the platform should reject untrusted artifacts by default. Teams sometimes confuse optional signing with gradual adoption, yet gradual adoption only works if the enforcement target is already defined. Otherwise, optional becomes permanent. NHIMG’s The State of Secrets in AppSec highlights how fragmentation across multiple control points erodes confidence even when teams believe they are secure. For that reason, optional signing is most dangerous in multi-team environments, shared registries, and federated platform models where one group’s shortcut becomes another group’s production dependency. Best practice is evolving toward policy that is centrally defined and locally non-negotiable, with temporary exceptions tracked as risk rather than accepted as normal operations.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• What breaks when signing keys are spread across teams and regions?
• What breaks when identity data is split across multiple tools?
• How should security teams measure identity security maturity across human and machine identities?