A valid signature is not a deployment decision. It proves that a particular key or identity signed particular bytes, provided the verifier checks the right artifact and trust material. It does not establish that the signer was authorized for this service, that the artifact came from the approved repository, that the build used the expected source revision, or that required security checks ran. A software artifact admission policy supplies those missing expectations and blocks a workload before unverified code begins executing.
The practical unit of control is an immutable artifact digest joined to authenticated evidence and local policy. Tags are useful for people but can move; filenames can collide; registry paths can be copied. Resolve every deployment reference to a digest, verify evidence against that digest, evaluate the workload context, and record one decision. This complements Edilec's SBOM consumption guide: component knowledge informs risk, while admission determines whether this exact release may run here and now.
Define the admission outcome before choosing a tool
Write the control claim in operational language: production workloads may execute only artifacts whose digest is authenticated by an approved release identity, whose provenance satisfies service-specific source and builder expectations, and whose mandatory attestations meet current policy. State covered resource types, registries, clusters, namespaces, deployment routes, and direct node access. If batch jobs, functions, Helm hooks, operators, init containers, or emergency consoles escape the controller, the assurance claim must say so until those paths are closed.
Keep authentication, authorization, and evidence evaluation separate. Authentication validates the signature or certificate chain. Authorization decides whether that authenticated signer may release this artifact family. Evidence evaluation checks signed predicates such as provenance, test results, scanning, or review. A policy that stops after authentication turns every trusted key into a universal publisher. A policy that reads unsigned labels as evidence lets the submitter award itself compliance.
| Question | Policy input | Failure meaning | Default action |
|---|---|---|---|
| Are these the intended bytes? | Resolved digest and attestation subject digest | Evidence refers to another artifact | Deny |
| Who vouched for them? | Signature, certificate identity, issuer, trust root | Signer is unknown or proof is invalid | Deny |
| Was that signer authorized? | Service, repository and environment allowlist | Valid identity acted outside its remit | Deny |
| How were they produced? | Provenance source, builder, parameters and dependencies | Build does not meet release expectations | Deny or route to approved exception |
| May they run here? | Namespace, account, region, data class and release channel | Artifact is inappropriate for destination | Deny |
Model the policy inputs as a trust contract
Start with an artifact class rather than one global rule. For each service or product family, record accepted registry prefixes, release repositories, source organizations, protected branches or tags, build platform identities, provenance predicate types, allowed build definitions, and required security evidence. The current SLSA specification describes provenance as verifiable information about where, when, and how an artifact was produced. Verification becomes useful only when that information is compared with producer-defined expectations.
Treat trust roots and issuer rules as versioned configuration. Keyless signing still has roots, certificate authorities, identity providers, certificate claims, transparency services, and time semantics. Pin the issuer and exact identity form; avoid matching a broad email domain or organization when the intended principal is one protected workflow. For key-based signing, assign keys to bounded release roles, protect private material, publish rotation procedures, and retain enough historical trust information to investigate old releases without silently authorizing new ones.
Verify the signature, subject, and provenance expectations
The verifier should first canonicalize the deployment reference and obtain the registry digest. It then retrieves signatures and attestations from an authenticated location, validates their envelopes, checks the subject digest, validates signer identity and signing time under the configured trust model, and evaluates each predicate. The in-toto Attestation Framework provides a common envelope-and-predicate model; the policy must still define which predicate types, versions, and producers are acceptable.
Provenance policy should constrain the source repository and revision, builder identity, build type, and relevant external parameters. Decide whether a release revision must be reachable from a protected branch or correspond to an approved tag. Check that the provenance subject matches the artifact exactly. Reject unknown predicate versions unless there is an explicit compatibility rule. Do not infer that a high SLSA build level means the application is vulnerability-free: SLSA addresses supply-chain integrity properties, not every software security outcome.
| Evidence | Useful claim | Does not establish | Example policy |
|---|---|---|---|
| Artifact signature | An accepted identity authenticated these bytes | Source, tests, safety or authorization by itself | Release workflow identity must sign the resolved digest |
| Build provenance | Artifact was produced from described inputs on a named platform | That source is benign or every dependency is safe | Source repo and builder must match service expectations |
| SBOM attestation | A signer associated a component inventory with the artifact | Inventory completeness or current exploitability | Approved generator and schema; subject digest must match |
| Vulnerability result | A named scanner observed results at a stated time | Absence of unknown flaws or future safety | Fresh result, policy version and documented threshold |
| Approval attestation | An authorized process recorded a release decision | That upstream evidence was correct | Distinct approver role and unexpired decision |
Enforce at every deployment path
Kubernetes admission is a common enforcement point because it can reject workload objects before persistence or mutation. Sigstore's policy-controller documentation supports image-pattern matching, signature and attestation authorities, policy evaluation, and warn or enforce behavior. Its configuration semantics are important: understand whether multiple authorities are alternatives or cumulative requirements, what resources are matched, how images are resolved, and what happens when evidence stores or trust services are unavailable.
Admission is not complete if an attacker can bypass the API server, create unmanaged compute, alter a node runtime, or deploy through another control plane. Apply equivalent checks at serverless deployment APIs, VM image promotion, package repositories, device update services, and desktop management. Restrict who can modify policies, exemptions, registry aliases, and trust roots. Sign and review the policy bundle itself, deploy it through a protected path, and monitor the gap between declared workload state and what runtimes actually execute.
Roll out policy with measured failure modes
Begin in observation mode and collect decisions without changing workload outcomes. Classify failures into genuinely untrusted artifacts, missing producer evidence, incorrect expectations, unsupported legacy formats, and verifier availability problems. Remediate the production pipeline rather than adding a blanket namespace exemption. Move a low-risk service to enforcement, then expand by artifact class. Measure digest-resolution success, evidence coverage, decision latency, denial reasons, exception volume, and bypass attempts.
Choose availability behavior explicitly. Fail-closed protects integrity when the verifier or evidence service is unavailable but can stop urgent deployments. Fail-open preserves delivery but permits unverified code precisely when controls are impaired. A defensible design uses local caches of bounded-age trust data and attestations, highly available verification, tested controller timeouts, and a narrow emergency mechanism. The NIST SSDF emphasizes protecting software releases and preserving provenance; admission is one consumer-side enforcement layer, not a substitute for secure development.
Design exceptions and rollback without opening a permanent bypass
An exception should name one artifact digest, one destination scope, one reason, one approver, and one expiry. Never exempt a mutable tag, entire registry, or all workloads owned by a team. Require a compensating control such as isolation, reduced privileges, additional monitoring, or blocked egress. Store the exception as an auditable policy object and alert when used. Expiry should deny subsequent deployments, not terminate a running production process unexpectedly unless the incident plan calls for it.
Rollback artifacts need the same verification as forward releases. Pre-authorize known-good digests and keep their evidence available so an outage does not force an exemption. If a signing identity is compromised, revoke future authority, identify every artifact it authenticated, evaluate provenance and release records, and quarantine affected digests. Signature revocation alone may be ambiguous for historical artifacts, so decision records should preserve the policy version, trust material references, verifier version, evidence digests, and result used at admission time.
Operate and test the control continuously
- Attempt a validly signed artifact from an unauthorized repository and confirm denial.
- Modify an attestation subject digest and verify that envelope validation cannot authorize different bytes.
- Exercise moving tags, registry mirrors, deleted evidence, expired identities, rotated roots, and clock skew.
- Test controller outage, evidence-store latency, cache expiry, emergency approval, rollback, and revocation paths.
- Reconcile runtime digests with admission records and alert on any workload without a decision identifier.
- Review policy changes and exceptions with the same separation of duties used for production release authority.
Key takeaways
- Bind every decision to an immutable artifact digest.
- Treat signature validity, signer authorization, provenance expectations, and destination policy as distinct checks.
- Use artifact-specific exceptions with owners and expiry rather than broad bypasses.
- Cover every deployment control plane and reconcile admitted state with runtime state.
- Preserve the complete decision record so incidents and audits can reproduce why execution was allowed.
Frequently asked questions
Is a signed container automatically trusted?
No. The signature must validate for the resolved digest, and policy must authorize the signer for that artifact family. Provenance and other evidence must independently satisfy local expectations. A valid signature from an unrelated workflow is authenticated but unauthorized.
Should admission fail closed?
Production integrity usually favors fail-closed, but the availability consequence must be engineered. Use redundant verifiers, bounded local caches, pre-verified rollback artifacts, short timeouts, and a narrow audited emergency route rather than an undocumented global fail-open switch.
Can vulnerability scanning replace provenance verification?
No. A scan evaluates detectable conditions in an artifact at a time; provenance checks whether the artifact came through the intended source and build path. Both can inform admission, but they answer different questions and have different failure modes.
Conclusion
Deployment admission turns supply-chain evidence into a control only when it evaluates exact bytes against explicit expectations. Build the policy around artifact identity, bounded release authority, verified provenance, destination context, and reproducible decisions. Then test outages, bypasses, exceptions, revocation, and rollback as seriously as the happy path. The result is not a claim that admitted software is flawless; it is a defensible guarantee that unrecognized or improperly produced artifacts do not quietly become production workloads.