Witness attests and verifies software supply chain provenance

Two verbs, and what the difference buys you

The README describes Witness as a pluggable framework for software supply chain risk management that automates, normalizes and verifies software artifact provenance, and then splits that into two capabilities.

The first is attesting. Witness is a dynamic CLI tool that integrates into pipelines and infrastructure to create an audit trail for your software's entire journey through the software development lifecycle using the in-toto specification.

The second is verifying. Witness also features its own policy engine with embedded support for OPA Rego, so you can ensure that your software was handled safely from source to deployment.

The split matters because the two halves are useful on opposite sides of a release. The attesting side runs inside the build pipeline, where it has access to the materials being consumed and the steps being performed. The verifying side runs where a decision is made, often by a party that does not build the software at all, and its job is to decide whether the recorded history satisfies a rule.

The word normalizes in the description is doing work as well. Different pipelines record different things, and the in-toto specification gives them a common shape so that a policy written once applies across them.

The list of what you can do with it is more concrete. You can verify how your software was produced and what tools were used. You can ensure that each step of the supply chain was completed by authorized users and machines. You can detect potential tampering or malicious activity. And you can distribute attestations and policy across air gaps, which is the case that closed networks with strict data egress rules hit first.

The project originated at TestifySec and was later donated to the CNCF in-toto ecosystem, where it is now maintained by the open community. The homepage is witness.dev and the primary language is Go.

Installing the binary

To install Witness, all you will need is the Witness binary. You can download this from the releases page or use the install script to download the latest release:

bash <(curl -s https://raw.githubusercontent.com/in-toto/witness/main/install-witness.sh)

That one-liner is what the README puts at the top of the file, in the centre of the header, and it is also repeated in the Installation section.

For anyone with a supply chain security function, the obvious observation is that piping a downloaded script into bash is the exact practice this tool exists to make unnecessary. The README anticipates that and points to an alternative: if you want install it manually and verify its integrity follow the instructions in the INSTALL.md file, which is at the root of the repository alongside SECURITY.md and DEPENDENCY.md.

The distinction the project draws between the two routes is the same distinction it asks you to enforce on your own builds. The script is convenient and it fetches the current release; the manual route is slower and it lets you check that the binary you run is the binary that was published.

The repository root has the artifacts to support both routes. There is a .goreleaser.yaml, which is what produces the release binaries, an install-witness.sh script at the root, a Makefile with a build target that uses CGO_ENABLED=0 and the -trimpath flag, and a SECURITY.md describing how to report a vulnerability.

There is also a Makefile target worth knowing about for anyone automating the build. The build target is:

CGO_ENABLED=0 go build $(BUILDFLAGS) -o $(BINDIR)/$(BINNAME) ./main.go

Setting CGO_ENABLED to 0 produces a static binary with no libc dependency, which is what makes it usable in a scratch container or a distroless build stage, and -trimpath strips the local filesystem paths out of the binary.

The key features and what each one costs you

The key features list is short, and each entry is a decision about how the attestation gets signed and stored.

There are integrations with GitLab, GitHub, AWS and GCP. It implements the in-toto specification, including ITE-5, ITE-6 and ITE-7, which are the in-toto enhancement proposals covering attestation formats for different artifact types. There is an embedded OPA Rego policy engine for policy enforcement, which is the Open Policy Agent, the same engine used by Gatekeeper and other Kubernetes policy projects, embedded in the binary rather than run as a service.

Keyless signing with Sigstore and SPIFFE/SPIRE is the entry that most affects deployment. Keyless means the signing identity comes from an ambient credential rather than a key you store, and the two mechanisms named are Sigstore's Fulcio for short-lived certificates based on an identity provider, and SPIRE for workload identity in a cluster. The tutorials list a Getting Started guide, a Verify an Artifact Policy guide, and a Using Fulcio as a Key Provider guide, and the go.mod confirms the dependency on sigstore/fulcio at v1.8.8.

Integration with RFC3161 compatible timestamp authorities is there for the long-lived case. A keyless certificate expires in minutes, so a timestamp authority lets you prove that a signature existed at a point in time well after the certificate expired, which is what makes the attestation usable as evidence months later.

Two entries carry caveats. Process tracing and process tampering prevention is marked Experimental, and it is the feature that would catch a compromised build step that produces a correct-looking artifact by doing something extra along the way. And attestation storage with Archivista is a link to a separate project rather than a built-in store, so the storage layer is a choice you make.

The design constraint worth noting is that it is designed to run in both containerized and non-containerized environments without elevated privileges, which is unusual for a security tool and matters in CI runners where you do not control the permissions.

The dependency footprint tells you what it really is

The go.mod is where the shape of the tool becomes clear, because the dependency list is dominated by cloud and identity providers rather than by cryptographic libraries.

The direct requirements are go-witness at v0.12.0, which is the in-toto attestation library this project sits on, the Open Policy Agent at v1.19.0 for the policy engine, sigstore/fulcio at v1.8.8 for keyless certificate issuance, cobra with pflag and viper for the command line, logrus for logging, tablewriter for output formatting, gobwas/glob for pattern matching, invopop/jsonschema for JSON schema handling, testify for assertions and k8s.io/apimachinery.

Then the indirect list shows how many ways there are to prove identity. There is go-spiffe for SPIFFE identity, coreos/go-oidc for OpenID Connect, and the full set of Google Cloud packages: cloud.google.com/go with auth, compute metadata, iam, kms and longrunning. There is the Azure SDK with azcore, azidentity and the keyvault azkeys package for Azure key management, and the AzureAD Microsoft authentication library.

The KMS and key vault entries are the ones to note. They are there so that a signing key can live in a cloud key management service rather than on a disk, which is the difference between an attestation you can trust in a regulated environment and one you cannot. The presence of cloud KMS on both Google and Azure means the keyless path and the keyed path are both first-class.

The cyclonedx-go dependency appears as an indirect requirement, which connects the project to the SBOM world even though the project is not itself an SBOM tool.

The module requires Go 1.26.5, and the tools are spf13 cobra based with viper for configuration, which is the conventional choice for a CLI with this many subcommands and configuration sources.

Where Witness fits, and where it stops

The comparison worth making is with Sigstore alone and with an SBOM tool, because all three answer adjacent questions and the distinction matters when you are choosing what to add.

Against Sigstore, the difference is what is being signed. Sigstore signs artifacts, typically a container image or a binary, and proves that a known identity produced that artifact. Witness signs the record of how the artifact was produced, which is the materials and the steps, so the question the attestation answers is not who published this binary but what went into building it and on which machines.

Against an SBOM tool, the difference is what the artefact describes. An SBOM lists the components inside a piece of software, which tells you what you are exposed to. An attestation describes the process that produced it, which tells you whether the build was trustworthy. Those are complementary, and the usual pairing is to generate both, because a vulnerability in a dependency and a compromised build step are different risks with different responses.

The limits are worth stating plainly. The process tracing and tampering prevention is the feature that would detect the most sophisticated attack, and it is marked Experimental, so a team whose threat model is a malicious build step rather than a compromised dependency is relying on the least settled part of the tool. The storage layer is a separate project, Archivista, rather than something built in, so deploying Witness means deploying or running that too, unless you keep the attestations somewhere else. And the policy engine is embedded, which means the Rego policies you write are the only policy surface: there is no separate evaluation service, which is simpler to operate and less flexible if you want to share policy across many tools.

The air gap point deserves emphasis because it is unusual. Being able to distribute attestations and policy across air gaps means the verification side can run in a network that cannot reach the build side, and the attestation is the only thing that has to cross. For environments that cannot allow outbound connections from a build system, that is the property that makes the whole approach work.

On maintenance, the releases are v0.12.0 from 2026-07-10, v0.11.0 from 2026-04-14 and v0.10.2 from 2026-01-13, the last push was on 2026-10-19, and the repository is not archived. The badges show an OpenSSF Best Practices badge, an OpenSSF Scorecard badge, a FOSSA licence status and a Go Report Card, and the governance files are present, with GOVERNANCE.md, MAINTAINERS.md, CONTRIBUTING.md and CODE_OF_CONDUCT.md at the root.

Editorial conclusion

Witness suits a platform team that needs to prove how a released artifact was built, since the in-toto attestation model records the materials and steps of each pipeline stage and the embedded policy engine checks those attestations without a separate service. It is the wrong tool if you need an SBOM, because an attestation says how an artifact was made rather than what is inside it, and it is the wrong tool if your builds run on a host where the tracing features are unavailable, since the process tracing and tampering prevention are marked Experimental. Before you adopt it, read INSTALL.md for the manual install with integrity verification rather than piping the install script into bash, and check the tutorials in docs/tutorials before designing your pipeline around it.

Frequently asked questions

Official sources

1. in-toto/witness on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases