Witness records a software build, signs the evidence and checks whether the resulting file meets a release policy. Anamarija Pogorelec’s October 26 overview explains a concrete use: stop a release when its build records fail verification.

Provenance is a record of how an artifact was produced. Witness collects attestations, signed statements about build inputs, commands and outputs. A release gate can require particular records and trusted signers before accepting that artifact.

Recording a build and approving it are separate jobs

The project’s getting-started tutorial wraps a build command with witness run. The resulting signed record can travel with the compiled file or be stored in Archivista, a companion service for attestations.

A policy names the required build steps, attestation types and authorized signing keys. It can also apply Rego, the Open Policy Agent’s rule language, to fields inside those records. The tutorial says verification returns a nonzero exit status and a reason on failure.

That creates a usable release control only when the surrounding pipeline treats rejection as a hard stop. Recording evidence in one job while deployment proceeds independently leaves the approval decision unenforced.

Protect the authority that writes the rules

The introductory tutorial uses the same demonstration key for build evidence and policy signing. Pogorelec points out the consequence: someone who steals that key can sign both the evidence and the rules evaluating it.

The project’s more detailed artifact-policy tutorial creates a separate policy-signing key. Its verifier receives that policy’s public key, while the policy identifies the authorized build signer.

For a real release process:

  • Separate build signing from policy approval. Keep the policy-signing authority outside the build job’s write access. Two key files on the same compromised runner provide little separation.
  • Require specific evidence. Name the expected steps, signers and relevant constraints, rather than accepting any signed record.
  • Verify the file being shipped. Supply the release artifact, its matching attestations, the signed policy and a trusted policy-verification key.
  • Test rejection before relying on the gate. Missing evidence, an untrusted signer or a changed artifact should prevent promotion through the normal release path.
  • Review examples before adapting them. The introductory policy contains an expiration date in 2023. It is teaching material, not a ready-to-deploy production policy.

These are controls for teams that build or accept software artifacts. The October 26 article introduces an existing project; it announces neither a new vulnerability nor a newly fixed release.

Signed evidence still depends on the builder

A valid signature authenticates a statement from a trusted key. A compromised builder or stolen signing identity can still produce misleading evidence. Independent policy control, restricted build credentials and isolated runners remain part of the design.

Evidence status: documented tool behavior and example workflows. The reviewed sources provide no measured reduction in supply-chain compromises or independent production effectiveness study. The project’s README still labels process tracing and tampering prevention experimental.

Caveat: Witness originated at TestifySec, which sells managed hosting and support; it is now community-maintained within the in-toto ecosystem. Provenance verification does not certify that the source code is safe.