Colofon — Cryptographic Receipts for Software Supply Chain Compliance

Apertrue Ltd · v0.2 · April 2026

Abstract

The UK Software Security Code of Practice (SSCoP), the EU Cyber Resilience Act (CRA), and the UK Defence Cyber Certification scheme (DCC) each push software vendors to demonstrate specific supply-chain security properties to their buyers. The CRA does so by law (full enforcement December 2027); the DCC, through MOD procurement; SSCoP, through buyer expectation today and a forthcoming NCSC certification scheme. Today, vendors facing any of the three have a binary choice: produce a self-attested questionnaire (unverifiable), or publish the full evidence (which exposes SBOMs, build-pipeline internals, developer identities, customer lists, and CVE embargo state). In 2026 this trade-off has hardened: capable language models can now turn that disclosed evidence into a targeting plan in minutes — the SBOM as training data, the approved-builder identities as a spear-phishing roster, the patch timeline as an exploit window expressed as a calendar. Neither option serves regulated sectors. Colofon closes this gap by producing zero-knowledge proofs of conformance that are anchored to public Sigstore / Rekor transparency logs, verifiable in any web browser, and mapped directly to SSCoP Assurance Principles and Claims. Vendors prove the claims; the underlying evidence remains private. The product is built on existing production infrastructure from Apertrue Ltd's media-authenticity platform and targets UK defence SMEs, regulated fintech, and closed-source ISVs as the initial market.

1. The problem

Software vendors selling to regulated buyers — government, finance, healthcare, defence — must increasingly demonstrate that their software supply chain is secure. This requires answers to specific questions: is every third-party component legitimate and unmodified? Has the release been scanned for known vulnerabilities? Are releases signed off by authorised personnel? How quickly are vulnerabilities patched? How quickly are customers notified when incidents occur?

Two options exist today, and neither works.

Questionnaire compliance is what SSCoP currently asks for: the vendor completes a self-assessment form, ticks fourteen boxes, signs, and hopes. The buyer has no cryptographic way to check. Almost every publicly-reported supply-chain attack in recent years — XZ Utils, polyfill.io, 3CX, SolarWinds — happened against vendors whose paperwork was in order. Claims-based assurance, as NCSC frames it, is a starting point, but by itself creates a trust gap that regulators have not yet closed.

Full-disclosure compliance means the vendor publishes the complete Software Bill of Materials, the build-pipeline attestations, the vulnerability scan results, the patch timelines, and the incident ledger. The buyer can now verify. The vendor has exposed:

• A map of the software's entire dependency tree, usable by anyone targeting the vendor's customers.
• Competitive intelligence about which open-source stacks the vendor depends on and how they're licensed.
• Build-pipeline internals — runner configurations, toolchains, identity of release managers.
• Customer lists, for incident notifications.
• CVE embargo state, when disclosure discipline is required.

For defence contractors subject to DCC Level 2+ controls, for closed-source ISVs under prime-contract NDAs, for FCA-regulated fintech vendors, and for medical device manufacturers, this disclosure is contractually or legally forbidden. These vendors cannot prove compliance through today's options. The result is a structural gap in the UK and EU regulatory architecture: the claims regulators want to verify are precisely the claims that vendors are forbidden to substantiate.

The economics of that disclosure have also changed. Until recently, turning a disclosed compliance dataset into an actionable attack plan required an analyst-week per target; adversary economics didn't scale, and organisations tolerated disclosure on those grounds. Capable language models have collapsed that cost. A modern model ingests a disclosed compliance dataset and returns, in minutes: a ranked list of unpatched CVEs in the target's dependency tree annotated with exploit maturity; personalised spear-phishing templates naming the target's release managers and calibrated to their public language register; plausible malicious pull requests against each direct dependency, with social hooks shaped to each maintainer's recent review patterns; and a map of the target's CI workflow paths to probe for known misconfigurations. What was once a commercial-confidentiality concern is now a security liability. The disclosed SBOM is training data. The list of Fulcio identities is a social-engineering roster. The patch timeline is an exploit window expressed as a calendar.

This is not an argument for less compliance evidence; the regulatory direction is the opposite. It is an argument that disclosure is no longer a safe substrate for that evidence. The proof must carry the claim without carrying anything else an adversary can repurpose.

Three regulatory forcing functions are converging to make this gap urgent:

• SSCoP certification scheme. NCSC and the Software Security Ambassadors Scheme (launched January 2026 with 13 ambassador organisations) are designing a certification pathway beyond the current self-assessment. The scheme needs credible evidence that claims are true.
• EU Cyber Resilience Act. Vulnerability reporting obligations take effect September 2026; full enforcement December 2027. Mandatory for any product with digital elements sold in the EU.
• UK Defence Cyber Certification (DCC). Scheme open to applicants since July 2025; all four levels (0–3) live by end of August 2025. Certifies against Cyber Security Model v4 (DEFSTAN 05-138 Issue 4, mandatory for new MOD contracts under DEFCON 658 from 3 December 2025). Increasingly mandated for MOD procurement. Levels are tiered by the supplier's assessed cyber-risk profile.

All three demand the same underlying operational evidence. None of them tell vendors how to provide that evidence without exposing the underlying data.

2. The solution

Colofon is a cryptographic receipt system. Every software release passes through the vendor's existing CI pipeline, where a small plugin (the Colofon Agent) generates a proof bundle: a cryptographic artifact that proves a set of specific claims about the release without disclosing the underlying evidence.

The buyer receives a shareable URL. Opening it in a browser runs a WASM verifier that:

• Checks the bundle's zero-knowledge proofs against public Sigstore / Rekor transparency logs.
• Renders plain-English summaries of each verified claim.
• Produces a signed verification receipt for the buyer's audit file.

No sensitive vendor data ever leaves the vendor's environment. The evidence the proofs reason about — the SBOM, the build-pipeline attestation, the vulnerability scan, the notification log — stays private. The proofs are portable, composable, and verifiable offline.

Colofon does not issue certifications. It produces cryptographic evidence that existing certifiers (auditors, accreditation bodies, the forthcoming NCSC certification scheme) can accept as substrate for their work.

3. The five circuits

Colofon ships five zero-knowledge circuits, each engineered to answer a specific SSCoP-aligned question:

Circuit 1 — Build provenance

Proves: this binary came out of an authorised build pipeline, from a specific commit, on an approved toolchain. Signed input: SLSA v1.0 in-toto provenance attestation (GitHub Actions OIDC keyless signature; Rekor-anchored). Stays private: the builder identity, runner names, workflow paths, toolchain internals. Adversary cannot derive: which CI workflow paths to probe for misconfigurations, which toolchain versions to fingerprint for known weaknesses, or which release-manager identity to imitate. SSCoP principles: 2.1, 2.2, 3.1.

Circuit 2 — Developer authorisation

Proves: the commit that triggered the build was signed by a member of the vendor's authorised-signer set. Signed input: Sigstore gitsign commit signature (Rekor-anchored). Stays private: which specific developer signed. Adversary cannot derive: a roster of authorised signers to target with spear-phishing, OIDC-account-takeover, or credential-theft campaigns. Plain Sigstore signatures publish that roster on every commit. SSCoP principles: 2.1.

This circuit is the clearest illustration of why plain signatures aren't sufficient. A signature by default reveals the signer. "A member of this set signed this, and I'm not going to tell you who" is a fundamentally zero-knowledge claim.

Circuit 3 — SBOM dependency non-membership (the headline)

Proves: no component in this release has an unpatched vulnerability above the buyer's severity threshold, older than the buyer's age threshold, against a trusted CVE snapshot. Signed input: cosign-signed CycloneDX SBOM (predicate type cyclonedx.org/bom, DSSE envelope, Rekor-anchored) + OSV.dev CVE snapshot. Stays private: the SBOM itself; which CVEs were checked against; which components the vendor uses. Adversary cannot derive: the dependency tree as an attack-surface map, the vendor's choice of upstream maintainers to target with malicious-PR campaigns, or which adjacent CVEs are presently unpatched on the vendor's release cadence. SSCoP principles: 1.2, 3.3.

This is the first circuit of the five that could not be built before zero-knowledge proofs matured. It answers the buyer's question "is this release vulnerability-clean against my policy?" while keeping the SBOM private. No existing product provides this capability.

Circuit 4 — Incident notification SLA

Proves: for every customer in the committed customer set, a notification email signed by the vendor's mail provider was sent within the SLA window of the incident timestamp. Signed input: outbound DKIM signatures (Postmark / SendGrid / Mailgun / AWS SES; DKIM keys published in DNS). Stays private: the customer list; the incident contents. Adversary cannot derive: a downstream-targeting roster (the customers most likely to still be running an unpatched build), or the existence and contents of incidents under embargo. SSCoP principles: 4.3.

The clever element here is reusing the DKIM signatures vendors are already generating for every outbound email. The mail provider — not the vendor — is the signer, giving the buyer an independent trust root without any new infrastructure.

Circuit 5 — Policy composition

Proves: all four prior circuits verify against the specific compliance policy the buyer has committed to. Signed input: buyer's policy document, published to Rekor by the buyer. Stays private: every witness from circuits 1–4; the buyer-policy thresholds satisfied (only the policy-commitment hash is public). Adversary cannot derive: any per-circuit witness from the wrapper proof; which buyer's policy was satisfied (multiple buyers' policies share a single proving run); which thresholds were tight versus comfortable. SSCoP principles: meta-circuit wrapping all of the above.

This is where Colofon becomes a product rather than a primitive. Each buyer has their own severity thresholds, their own approved-builder allowlists, their own SLAs. Circuit 5 lets a single proving run satisfy any number of buyers, each verifying against their own committed policy. Enterprise procurement can now treat compliance policy as a negotiable artifact.

4. Trust architecture

Every signed input is anchored to the Sigstore Rekor transparency log. Rekor v2 (GA October 2025) is a production-ready, tile-backed transparency log with published signed tree heads, exposing standard RFC 6962-style inclusion proofs at the API layer. Cosign v2.6.0+ and the official Go, Python, and Java clients verify against it.

For signed inputs that do not currently land in Rekor — NVD CVE timestamps, OSV snapshots, DKIM email headers — Colofon uses the provider's native signing infrastructure (NIST-signed NVD feeds, HTTPS+pinned-cert for OSV in v1, DNS-published DKIM keys). A v2 roadmap item is upstream contribution to OSV.dev for Sigstore-signed snapshots, closing this residual trust gap.

Circuits report coverage as a ratio rather than binary pass/fail, reflecting real Sigstore adoption curves across package ecosystems. Adoption is uneven: npm and PyPI are leading, both with attestation rates in the 7–17% range as of early 2026, while crates.io, Go modules and Maven Central are at or near zero. Buyers see e.g. "183/247 components Sigstore-verified; 64 anchored by vendor-signed hash only" and make informed risk decisions.

5. Technical foundation

Colofon is built on Noir (Aztec Labs' zero-knowledge circuit language) and Barretenberg's UltraHonk proving system. Apertrue Ltd has been running production ZK infrastructure on this stack since 2025 for media authenticity (C2PA-signed content with privacy-preserving proofs). Approximately 60% of the core cryptographic primitives Colofon needs — ECDSA P-256 verification, Merkle inclusion, recursive proof composition, X.509 parsing, browser WASM verification, signed-bundle distribution — are already shipped inside Apertrue's codebase.

The Aztec Indexed Merkle Tree — the protocol's built-in non-membership-friendly data structure — is the natural substrate for the vulnerability non-membership circuit, and is the only place in the five-circuit architecture where substantial new circuit engineering is required.

For DKIM verification (Circuit 4), Colofon builds directly on the noir_rsa library (zkpassport's fork — the same RSA-2048 PKCS#1v1.5 verification primitive Apertrue's production C2PA stack runs on) and implements the DKIM-specific layer — RFC 6376 relaxed canonicalisation handling, body-hash chain binding, partial-SHA body precompute, and the sender-domain double-binding — directly inside the Colofon circuits. ZK Email's zkemail.nr library pioneered DKIM-in-Noir; v1 was audited by Consensys Diligence in late 2024 and informed several design choices in Circuit 4, including the partial-SHA body-hash pattern. We evaluated direct integration of zkemail.nr v2.0.0 (March 2026) but its Noir-API expectations did not align with our pinned 1.0.0-beta.19 toolchain; a future re-evaluation when zkemail.nr ships beta.19+ compatibility is on the v1.5 roadmap.

6. Regulatory alignment

Colofon bundles map directly onto the claims structure of four regulatory frameworks: the UK Software Security Code of Practice (SSCoP), the EU Cyber Resilience Act (CRA), the US NIST Secure Software Development Framework (SSDF), and UK Defence Cyber Certification (DCC). Mapping is principle-by-principle rather than framework-by-framework: one piece of evidence (a bundle) typically discharges the same underlying claim across all four.

6.1 UK SSCoP — full principle mapping

SSCoP comprises 14 principles across 4 themes. The v1 bundle addresses 11 of them: six via zero-knowledge circuits, five via plain signed attestations. The remaining three sit on the v1.5 / v2 roadmap with identified architectural paths (all three need completeness guarantees — "you sent X notifications" is soluble in-circuit; "you sent every notification that was due" requires a committed customer-set architecture, which is Circuit 4's v2 direction).

Theme-level coverage: Theme 1 (secure development) 1/4 ZK; Theme 2 (build environment security) 2/2 ZK — full coverage; Theme 3 (secure deployment) 2/5 ZK; Theme 4 (customer communication) 1/3 ZK. Every theme has at least one ZK circuit.

6.2 EU Cyber Resilience Act

The CRA entered into force December 2024; vulnerability reporting obligations apply from September 2026; full compliance December 2027. The bundle addresses the Act's core operational requirements.

CRA Article 13 explicitly contemplates SBOM availability on request rather than by publication. The bundle format satisfies the verifiability problem without the request chain — a buyer, regulator, or CSIRT can verify the vulnerability-non-membership claim against the committed SBOM without the SBOM itself changing hands.

6.3 US NIST Secure Software Development Framework

NIST SSDF v1.1 (SP 800-218) structures its practices into four groups. The bundle maps to the practices where a cryptographic claim is materially stronger than a textual attestation.

Practices not listed (PO.x preparation practices, RV.2 assessment) are organisational rather than per-release and do not reduce to cryptographic claims. The bundle is evidence for SSDF, not a replacement for the process.

6.4 UK Defence Cyber Certification

The DCC scheme has been open to applicants since July 2025, with all four levels (0–3) available by end of August 2025. It certifies against Cyber Security Model v4 (DEFSTAN 05-138 Issue 4, mandatory for new MOD contracts under DEFCON 658 from 3 December 2025). Levels are tiered by the supplier's assessed cyber-risk profile. Colofon targets the supply-chain layer of CSM v4 controls; vendors continue to hold Cyber Essentials or CE+ for the broader baseline. (DCC certifies cyber-security maturity; handling of classified material remains the domain of DEFCON 660 and DEFCON 659A and is out of scope here.)

A core procurement concern that DCC engages — that MOD-tier defence procurement frequently involves prime-contract-sensitive material a supplier cannot publish to evidence its security posture — is exactly the shape of problem zero-knowledge compliance was built for. The bundle lets an SME prove conformance to a Level 2 or Level 3 profile without exposing the SBOM, build-pipeline internals, or customer list that would otherwise carry that material.

6.5 Cross-framework coverage summary

The same circuit discharges claims across frameworks. A single proving run addresses at minimum:

• SSCoP principles 1.2, 2.1, 2.2, 3.1, 3.3, 4.3 (six principles, all four themes)
• CRA Annex I §1(2)(b), §2(1), Article 14 (three core provisions)
• SSDF PS.1, PS.2, PW.4.5, PW.6, RV.1 (five practices)
• DCC Level 2 and Level 3 supply-chain controls

The principle Colofon is built around: compliance evidence should be authored once against underlying facts, and reused across whichever frameworks a buyer happens to be operating under. Vendors do not need separate SSCoP, CRA, SSDF, and DCC evidence packages. They need one bundle that each framework's reviewer can read their own claims out of.

Appendix — further reading

• Per-circuit deep-dives: Circuits
• SSCoP: https://www.gov.uk/government/publications/software-security-code-of-practice
• Software Security Ambassadors Scheme: https://www.gov.uk/government/publications/software-security-ambassadors-scheme/software-security-ambassadors-scheme
• Apertrue Ltd: https://apertrue.com
• Sigstore: https://docs.sigstore.dev/
• Aztec: https://docs.aztec.network/
• OSV.dev: https://osv.dev/