What is OpenVet

OpenVet gives consumers a way to require that every dependency in their lockfile has been reviewed by someone they trust, and gives reviewers a way to publish those audits so others can subscribe to and verify them. It comes in three layers:

• Protocol. A public specification for what an audit is, how authors sign it, and how audits are distributed over append-only, content-addressable logs. The standard is open and the wire format is implementable by anyone.
• Registry. A collaborative web platform at openvet.org where authors host logs, publish audits, and discover the work of others. It is the easiest way to participate, but it is one place logs can live, not the only one: the protocol is host-agnostic. Open-source and licensed under the AGPL-2.0 license.
• Tooling. The openvet CLI for authoring and publishing audits, subscribing to logs (registry-hosted or otherwise), and gating your project’s lockfile against a policy you write. Open-source and permissively licensed under the MIT license.

The problem #

A typical modern application pulls in a lot of third-party dependencies. The status quo is to trust what is published in software package registries by default — a habit from a time when the ecosystems were smaller, the registries were less of a target, and a careful developer could plausibly read the code they depended on. None of that is still true. Supply-chain attacks against open-source registries are happening more often, and with growing sophistication. It is time to rethink how we build software.

Current approaches to hardening supply-chain security cover different layers:

• Lockfiles (Cargo.lock, package-lock.json, …) pin dependencies by content hash.
• Vulnerability scanners (pip-audit, Dependabot, …) check dependencies against databases of known security issues.
• Build-provenance systems (Sigstore, npm provenance, Go’s checksum database) validate where an artifact came from.

All three are useful. None of them answer the question a consumer actually has: is this code safe? Lockfiles do not help if the code they pin to was already malicious at the time of pinning. Vulnerability scanners only catch malicious code after it has been discovered, catalogued, and added to a database. Build-provenance systems prove where an artifact was produced but not what it does — the Shai-Hulud worm showed how a hijacked CI pipeline can produce a perfectly attested malicious release.

And — more importantly still — none of these can answer the harder question that follows: is this code correct? That is the gap OpenVet fills.

What OpenVet provides #

The three layers in a bit more detail.

The standard #

An OpenVet audit is a signed statement, by a named author, about a specific package version, pinned by its hash. Audits carry several kinds of content:

• a short summary containing the audit’s high-level results;
• a structured report breaking down how the audit was performed and what it found;
• source-anchored annotations pointing at specific files or lines;
• structured findings that flag concrete issues, security-relevant or otherwise; and
• machine-readable claims — boolean assertions about observable properties of the code (does it open network connections, does it implement cryptography, is the implementation side-channel safe).

OpenVet defines a canonical claim vocabulary, with a small subset of required claims that every audit must address (enforced by the CLI). Beyond those, auditors can add custom claims for properties the vocabulary doesn’t cover.

Audits are organised into per-actor logs: append-only, signed commit chains over a content-addressable Merkle Search Tree. A log is signed by its owner end-to-end, so the party operating it does not have to be trusted — a consumer who has pinned the log’s head can detect any later tampering. The specification covers the data model, the log structure, the signing scheme, and the wire protocol, and is implementable by anyone.

The registry #

openvet.org is the OpenVet registry: a collaborative web platform where authors host logs, publish audits, and discover work by others. It is the easiest on-ramp — sign up, get a custodial key, and publish your first audit from the browser, with the option to switch to a self-held key later.

The registry is one implementation of the standard, not a central trust anchor. The protocol is host-agnostic: any static host (your own server, S3, GitHub Pages, anywhere static data can be served from) can host a log that the CLI will subscribe to. The registry exists to make collaboration easy, reduce friction, and make trustworthy audit logs discoverable.

The command-line tool #

The openvet CLI is the local entry point. It generates and manages signing keys, drafts and publishes audits to a log you control — registry-hosted or self-hosted — fetches and verifies the logs you subscribe to, and gates your project’s lockfile against a policy you write. The CLI is the half of OpenVet that lives in your terminal and on every developer’s machine.

How it fits into your workflow #

In a project that depends on third-party packages, you initialise OpenVet with a configuration file declaring which logs you trust, which lockfiles you have, and what requirements those dependencies must meet. OpenVet then reads your lockfiles, finds matching audits in the logs you’ve subscribed to, and validates each dependency against your requirements. Dependencies without a matching audit, or whose audits fail your requirements, cause OpenVet to exit with an error — just like the rest of your existing build tooling.

For reproducibility, OpenVet pins the logs you subscribe to in its own lockfile, so runs on different machines and at different times produce the same verdict. The check is optimised to be fast and stay out of the way of your development workflow.

If you want to contribute audits back, OpenVet provides a CLI workflow for drafting, editing, signing, and publishing audits to your own log — so anyone subscribed to it can use them.

Who it’s for #

OpenVet is for anyone who depends on third-party code, regardless of project size. The goal is to democratise software auditing — to make it tractable for an individual developer or a small team to ship audited dependencies, not just for large organisations with dedicated review staff.

Today, that asymmetry is real: large companies can afford teams whose only job is to review their dependencies; mid-sized companies, small companies, and most open-source projects cannot, and so they don’t. OpenVet is built on the bet that if there is a shared place where audits can be published, most projects will find that most of their dependencies have already been audited by someone — and that the work left for any one consumer is the long tail of dependencies nobody has covered yet.

How much of that work you delegate is your call:

• Subscribe broadly to logs you’d already trust, and rely on others’ reviews for most of your tree.
• Audit everything yourself if you want to.
• Or, most likely, pick a few trusted logs to start from and contribute audits back when you discover something new.

OpenVet covers the major source-shipping ecosystems — Cargo, npm, PyPI, Go modules, RubyGems — so a multi-language project doesn’t need a different audit format and tool per ecosystem.

What OpenVet is not #

OpenVet is deliberately scoped against several adjacent problems:

• Not a vulnerability scanner. OpenVet doesn’t ship a CVE database; it carries human review, not catalogued findings. Use it alongside cargo audit / pip-audit / Dependabot, not instead of them.
• Not a build-provenance system. Provenance answers where this artefact came from. OpenVet answers whether someone reviewed what’s in it. The two are complementary; we expect projects to use both.
• Not an arbiter of audit quality. The platform surfaces signed assertions; it does not verify that the auditor was thorough. A careless signer is indistinguishable, at the protocol level, from a meticulous one. Curation is the consumer’s responsibility.

Where to go next #

• How it works — the structure of audits, logs, and policies; how a consumer’s check resolves to a pass or fail.
• Landscape — how OpenVet relates to cargo-vet, cargo-crev, Sigstore, in-toto, and others.
• Quickstart — install the CLI and run it against your project.