Signatures secure distribution, not the code inside. Verifiable audits and builds provide safety.
Most of your project is other people's code, and updates keep introducing new, unaudited code. Who audits those changes, and how can you verify it?
The Challenge
Provenance of software is drawing attention across the industry: initiatives like GitHub attestations, Google OSS Rebuild, and rebuilt registries are pushing towards proving that a binary matches its source. That is necessary, but it is not sufficient. A backdoor committed upstream passes provenance checks, because provenance does not read the code: large parts of the xz-utils backdoor sat in plainly committed test files. The same is true for the regular npm attacks that hide a credential stealer inside an ordinary-looking package update.
So someone still has to read the code, and today that leaves teams with a bad choice: spend expensive expert time reviewing every dependency update, or rubber-stamp it and hope. Sharing human audits (cargo-vet, crev) spreads the cost, but coverage is thin and audits lag far behind releases. We close that gap with AI audits that run in attested hardware: the execution of every audit is verifiable, and a baseline verdict exists within hours of a release, not months later.
Backdoored releases & unread dependency diffs
xz-style, committed upstream: passes every provenance check
✓ Attested AI audit · Dependency Canary
Unverifiable builds & pre-compiled binaries
no proof the binary matches its source
✓ Attested build · Attestable Builds
No due-diligence evidence
CRA · NIS2 obligations, landing late 2027
✓ Signed, portable evidence
The cargo-vet ecosystem today
cargo-vet is an open-source tool from Mozilla that records audits of Rust crates in a shareable format, so teams can import each other's work instead of re-reviewing everything. Audits are made against criteria: safe-to-run means the code can be built and run without harm, say on a developer machine or in CI; safe-to-deploy additionally means it is fit for production use facing untrusted input. We like the concept very much. The problem is volume: the ecosystem simply is not producing enough audits to keep up with releases. That is the gap our attested AI audits fill.
Why It Matters
- Supply chain attacks (xz-utils, SolarWinds, CodeCov, …) have shown that even well-resourced organizations and careful maintainers miss malicious changes in their software or the infrastructure that builds it.
- CRA and NIS2 demand due-diligence evidence for third-party code that most teams simply cannot produce today, with the main CRA obligations landing in late 2027.
- Sovereignty-sensitive buyers must currently trust US vendors' infrastructure claims instead of verifying independently.
Why It Matters For Your Role
AppSec / DevSecOps
- Dependency updates are "rubber-stamped" rather than reviewed.
- SCA scanners flag known vulnerabilities, but they cannot flag potentially malicious dependency updates that have no known CVE yet.
Developer / Engineer
- Reviewing the diff of each dependency update rarely fits into delivery timelines.
- Verifying pre-compiled dependencies (Maven, PyPI, …) at scale is hard with today's tooling.
CISO / Compliance
- CRA / NIS2 require due-diligence evidence you cannot produce by hand; audit trails should be portable and verifiable.
- Black-box vendor risk scores are trust assumptions, not evidence.
- Insider threats and infrastructure compromise (SolarWinds) stay invisible without verifiable provenance.
How We Solve This
Dependency Canary
The audit layer: TEE-attested AI audits of dependency releases and diffs, published within 24 hours and backed by an attestation anyone can verify.
Learn More →Attestable Builds
The proof of origin: hardware-signed certificates that a binary was really built from its source, including pre-compiled ecosystems, where no provenance exists today. Also available standalone.
Learn More →Let us know how we can help you!
Book a call with our co-founders.