The industry's investment in artifact signing has been substantial. Sigstore, in-toto, SLSA, and various vendor-specific signing systems have made it cheap to attach cryptographic evidence to a built artifact. Most teams now sign at least some of what they produce. The harder question, the one that determines whether signing actually prevents harm, is what the verifier does with the signature when an artifact arrives.
A signature with no verification is paperwork. A verification with no policy is a yes-or-no check that misses the surrounding context. A policy with no shared definition across gates is a verification that succeeds at one gate and fails at another for reasons nobody documented. The state of the art in 2026 is to treat signature verification as an instance of unified policy: a rule that runs at every gate, references a versioned set of trust roots, evaluates accompanying attestations, and produces a structured verdict.
What signing alone does and does not give you
Signing an artifact gives the verifier confidence that the artifact has not been tampered with since the moment of signing, and that the signing identity controlled the corresponding key. That is genuinely useful. It does not, on its own, tell the verifier:
- Whether the signing identity is one the verifier trusts for this artifact's purpose.
- Whether the signing happened at a moment in the build process the verifier considers legitimate.
- What was inside the artifact at the moment of signing, beyond the artifact's own content hash.
- Whether the build pipeline that produced the artifact satisfies the verifier's pipeline requirements.
- Whether the signing key has since been revoked or compromised.
Each of these questions is answered by combining signature verification with attestations and trust-root policy. The signature is the entry point; the policy is what makes it meaningful.
Trust roots as policy
A trust root is a versioned, declarative list of which signing identities are trusted for which purposes. Production container images for service X may be signed only by identities A, B, or C, where each identity is bound to a specific build pipeline OIDC issuer and subject pattern. This is the kind of statement a trust root encodes.
The temptation, when standing up a verification system, is to start with a permissive trust root — accept anything signed by anything in our organization — and tighten over time. This is the same warn-to-block pattern that applies to other policies, and it should follow the same phased rollout discipline. Begin in observe mode against current traffic. Move to warn against production. Move to block against the most sensitive artifacts first. Expand the block scope as the trust root catches up to actual signing practices.
Trust roots also need rotation. Signing identities change, build pipelines move, and key compromises happen. A trust root with no rotation procedure becomes a single point of failure. The policy needs a documented process for adding identities, removing identities, and handling the gap when a previously trusted identity must be revoked between scheduled updates.
Attestation policy
Beyond signature verification, the verifier should evaluate the attestations that accompany the artifact. Common attestation types include:
- Provenance. Who built the artifact, in what pipeline, from what source, at what commit.
- SBOM. What the artifact contains.
- Vulnerability scan result. What the build-time scan found.
- Test result. What tests passed at build time.
- Signed VEX. Statements about how the artifact's known vulnerabilities apply.
Each attestation is itself a signed document. The policy decides which attestations are required, which are merely encouraged, and what their content must satisfy. A policy might require provenance attestation from a trusted builder, an SBOM that passes the active SBOM policy, and a vulnerability scan result no older than seven days. An artifact missing any required attestation fails verification, even if its primary signature is valid.
Attestation policy also needs to handle revisions. An attestation produced last week may be invalidated by a vulnerability disclosed today. The verifier needs to fetch current vulnerability data when evaluating an SBOM attestation, not rely on the scanner's verdict from build time. This pushes some recomputation to verification time, which has performance implications, but the alternative — accepting stale verdicts at admission — defeats the purpose of attestation.
Failure modes
Several failure modes of signature verification policy are worth designing around explicitly.
Stale trust roots. A verifier that has not refreshed its trust root in days will reject newly authorized signers and accept revoked ones. The trust root has to be a live, refreshed artifact, not a config file frozen at deploy.
Asymmetric tooling. A signing identity used by the build pipeline must be one the verifier knows about. When a new pipeline comes online, the trust root update needs to land before the pipeline starts producing artifacts that need to be admitted.
Bootstrap problems. The systems that fetch and evaluate trust roots are themselves images that must be admitted. A policy that requires a perfectly current trust root to admit any image cannot admit the image that fetches the trust root. Bootstrap exemptions need narrow, documented, and audited.
Performance. Verification at admission time has hard latency budgets. Signature verification, attestation fetching, and SBOM evaluation can each take seconds. Pre-computation, caching, and parallel evaluation are not optional.
Verification of the verifier. The verifier itself is part of the supply chain. The build of the verifier, its trust root, and its policy definitions need to be signed, attested, and protected with the same rigor it applies to everything else.
What good policy looks like in this domain
A mature signed-artifact policy at PR time evaluates the proposed change to ensure the build pipeline being added or modified is in the trusted builder set. At build time, it ensures the pipeline produces a signed artifact with the required attestations and the SBOM passes intermediate checks. At admission time, it verifies the signature against the current trust root, checks attestation completeness and freshness, and refuses workloads whose signature or attestation profile fails. At runtime, drift detection compares running container content against the signed SBOM and flags divergence as a signal worth investigating.
Each gate operates on the same trust root and the same attestation policy. A change to the trust root flows through the same versioned, source-controlled change process as any other policy change. A new signing identity is added with a justification, an expiry date for review, and a named owner. An identity removed because of compromise immediately stops authorizing new admissions across all gates.
Common pitfalls in 2026
Three pitfalls remain common.
The first is treating signing as the goal. Teams sometimes celebrate hitting a 100% of artifacts signed metric without ever standing up policy that does anything with the signatures. The signature without verification gives no security benefit; it just creates audit pressure to keep signing.
The second is treating verification as a single yes-or-no. The signature is valid is a small fraction of the question. The signer is trusted for this artifact's purpose, the build pipeline is on the allowed builder list, the attestations are complete and current, the SBOM satisfies policy is the rest of the question.
The third is leaving verification at the cluster boundary. A policy that verifies at admission but not at PR or build time misses the chance to catch problems early and gives developers no signal during the cycle they can affect. Distributing verification across all four gates is the path to durable enforcement.
How Safeguard Helps
Safeguard implements signature and attestation policy as part of the unified policy set across all four supply chain gates.
At PR time, Safeguard checks proposed pipeline changes against the trusted builder set and verifies that build configurations declare signing and attestation steps that satisfy policy. Pipeline drift that would reduce signing rigor surfaces as a structured PR comment.
At build time, Safeguard performs the signing and attestation, producing artifacts that ship with provenance, SBOM, and scan-result attestations bound to identities the trust root recognizes. Builds that fail to produce required attestations fail the pipeline.
At admission time, Safeguard's Kubernetes webhook fetches the artifact's signatures, verifies them against the current trust root, evaluates attestation completeness and freshness, and either admits or refuses with a structured rejection naming the missing or invalid evidence. Trust root updates propagate to all admission decisions in near real time.
At runtime, Safeguard compares observed container state against the signed SBOM that was admitted, surfacing drift as a signal that travels back into PR-time and admission-time decisions for the artifact in question.
The trust root, the attestation policy, the override workflow, and the audit log are shared across the gates. A change to which identities can sign for production flows through the same review process as any other policy change, and the signed artifact claim becomes an enforced precondition rather than a metric on a dashboard.