Zero-knowledge proofs have reached the point where "prove a computation happened correctly without revealing its inputs" is engineering rather than research, and supply chain vendors have begun marketing them. Groth16 and PLONK SNARKs, STARKs (used in StarkWare's Cairo and Polygon zkEVM), and Bulletproofs each have production implementations; libraries like arkworks 0.5, halo2 0.3, and the RISC Zero zkVM 1.2 make it possible to generate proofs over general computations rather than ad-hoc circuits. For software supply chain problems specifically, the question is not whether zk-proofs work but where they actually improve on simpler constructions like signed SBOMs, transparency logs, and standard in-toto attestations. This post is an honest technical analysis: what zk-proofs genuinely enable in supply chain contexts, what they cost, and where conventional Sigstore-style signatures remain the correct choice.
What problem do zero-knowledge proofs solve that signatures do not?
They prove a statement is true without revealing the inputs that make it true. A Sigstore signature on an SBOM proves "I, holding key K, vouch for this bill of materials"; it does not prove "the build executed correctly and contained no components from the embargoed list." A zk-SNARK over a circuit that evaluates the build script against input artifacts and a policy can prove the latter without disclosing the artifacts. Concrete use cases include: proving an artifact was built on SLSA v1.0 Build Level 3 infrastructure without revealing the build log, proving a dependency set excludes a specific banned component without revealing the full dependency list, and proving an SBOM's VEX status without revealing the underlying vulnerability triage data. These are real privacy gains, especially in multi-tenant or competitive-supplier contexts.
Which proof systems are mature enough to deploy?
Groth16, PLONK, and STARKs, with very different tradeoffs. Groth16 (introduced in the 2016 paper) has the smallest proofs (192 bytes on BN254) and fastest verification (single-digit milliseconds) but requires a per-circuit trusted setup. PLONK (Gabizon, Williamson, Ciobotaru 2019) and its variants Halo2 and UltraPLONK allow a universal trusted setup; proofs are larger (around 400 to 800 bytes depending on parameters) and verification is modestly slower. STARKs, used by StarkWare and RISC Zero, need no trusted setup and offer post-quantum security at the cost of much larger proofs (tens to hundreds of kilobytes) and slower verification (tens of milliseconds). Bulletproofs (Bünz et al. 2017) are useful for range proofs and small batches but scale poorly for general computation. For supply chain, STARKs are the most honest default: no setup ceremony to explain to auditors, and the larger proof size is acceptable for artifacts stored in registries.
How expensive is it in practice?
Prover costs are the binding constraint. Proving a STARK over a Keccak-256 hash of a 10 MB blob takes roughly 8 to 30 seconds on a modern 16-core workstation using the RISC Zero zkVM 1.2; proving a full SLSA-style build trace can take minutes to hours depending on circuit size. Memory usage is similarly steep, often 16 to 64 GiB during proving. Verification, by contrast, is cheap: a STARK verifier runs in tens of milliseconds, a Groth16 verifier in under 10 milliseconds. The asymmetry is fundamental to the technology and it means zk-proofs are viable for release-gate attestations (where you prove once and verify many times) but not for per-dependency hash checks at build time. Aggregation schemes like Nova and ProtoStar reduce amortized cost but add engineering complexity.
What real systems are using zk for supply chain?
Production uses are still rare but moving. Aleo's snarkOS and the ZK-EVM projects (Scroll, Polygon zkEVM, Taiko) are the bulk of the zk ecosystem but are payment-rails-focused. In supply chain specifically, RISC Zero's Bonsai 1.2 demonstrated proving a Docker layer digest computation from a Dockerfile input, and Succinct Labs' SP1 1.0 (released 2024) has community examples for proving SBOM membership. The Ethereum Foundation's 2024 grants round funded work on zkSBOM prototypes, and Sigstore's roadmap lists "transparency-log-of-attestations with selective disclosure" as a longer-term item, though as of early 2026 it is not yet shipping. In regulated industries, Aztec's noir 1.0 has been used in pilot programs to prove compliance statements without revealing underlying customer data; equivalent supply-chain pilots are beginning.
When are conventional signatures still the right answer?
Almost always, unless confidentiality is the explicit requirement. If every verifier can see the SBOM, the dependency list, and the build log, a Sigstore signature plus a Rekor transparency log entry gives you tamper evidence, non-repudiation, and public auditability at a fraction of the cost. Public transparency is itself a strong property: Certificate Transparency (RFC 6962) and Rekor depend on it. Zero-knowledge is the right tool when a producer must prove a property about data they cannot disclose, for example a defense contractor proving "no components from sanctioned vendor list X" to a customer who is not cleared to see the actual vendor list. For open-source and most commercial releases, the extra complexity of a proving toolchain is not justified by the marginal privacy gain.
How Safeguard Helps
Safeguard's attestation model is built around in-toto 1.0 and SLSA v1.0 predicates today, with an extension point for custom predicate types that can wrap zk-proofs when the organization's threat model calls for selective disclosure. Findings and policies operate on the publicly visible portion of an attestation, while private evidence can live alongside it as a verified predicate. Policy authors can require that a verifiable proof of a specific circuit identifier accompanied by an accepted proving key be present before a release is allowed, and the audit log captures the proof identifier and verification outcome. This keeps the tooling honest: conventional signatures for most paths, zk-proofs only where privacy is a hard requirement.