OpenVet Blog

Reactive vs proactive supply-chain security

2026-06-01T00:00:00+00:00

Software supply-chain security is currently top-of-mind for many people, because the previous months have seen a lot of attacks. However, this is not a new issue. It is something that I have been thinking about for several years now. My concerns about it were strengthened when the xz-utils attack happened, and current events provide even more evidence that we need to re-think how we approach it.

As a community, we have adopted a working pattern where we place implicit trust in software packages published on registries like NPM, PyPI, Cargo or even on random GitHub repositories. And I would like to live in a world where that is okay, but real world experience shows us that this is not a sustainable path.

People have suggested different “solutions” for this. In the previous months I have read a plethora of blog posts arguing for different ways to improve security. However, in my opinion, none of the suggestions are actually the right way to solve this. They are all reactive: they wait for something to go wrong, then tell you about it. Real security has to be proactive. It has to surface problems before they reach you in the first place.

I think we can only solve this problem if we re-think the way that we use dependencies. Part of the reason proactive security isn’t pushed more often, in my view, is that it asks us to change how we think — and the tooling to make that practical does not yet exist.

In this article, I want to walk through some suggestions that I have read about, and why I think they are not good solutions. Finally, I will explain what OpenVet’s philosophy is, why I am building it the way I’m building it, and how OpenVet tries to solve these problems differently, and properly.

Just don’t use dependencies #</a> </h2>
A few of the articles I have read seem to argue that you just should not use dependencies. Implement things yourself, or copy code. In fact, Go even spells the latter out as a proverb:

A little copying is better than a little dependency. </blockquote>
Let me untangle this a bit. I think a part of this thinking applies to microdependencies, those are dependencies that do a tiny thing. For example, `left-pad</code> was a small package published on NPM that left-padded a string. When the maintainer deleted it, it broke a lot of other people’s code. The article``Micro-libraries need to die already</a> talks about cases like this.`
However, I don’t agree with the blanket idea that you should copy code. If a lot of people are using a dependency that does one tiny thing, that is a signal that whatever the library does should become part of the language’s standard library. There’s no signal stronger to add something like left-pad</code> to your language’s standard library than someone publishing a library that does only that, and has hundreds of millions of users. There are cases where copying is fine, but that should not be the go-to way that software is developed.
`For larger libraries, I also don’t think copying is the right move. A language’s usefulness is compounded by having a set of robust libraries. It’s the ecosystem. Instead of declaring that an ecosystem is bad and that people should go back to implementing things by themselves, we should work together to make sure that there are strong libraries, and that those libraries are safe.`
`Having dependencies is not bad. Having dependencies and not checking them is bad.`
Vulnerability scanners don’t protect you #</a> </h2> Many people are pushing for the use of vulnerability scanners. I don’t think that using these is bad — it’s better than not using them. But fundamentally, vulnerability scanners can’t protect you. Vulnerability scanners are, by definition, reactive. If there is an active attack (a malicious version of a software package published), someone might notice it, investigate it, make a report, that report is then checked, once verified it lands in a vulnerability database and that is where your dependency scanner picks it up. But that might be a considerable time later. This is reactive security: by the time your dependency scanner flags something, your secrets, API tokens and access to your infrastructure may already be exfiltrated. Modern supply-chain attacks move fast. The time it takes for a malicious package to be discovered also depends on how popular it is. Today, most attacks target dependencies that are popular, which means that the damage they can do is greater (more users), but it also means that they are discovered more quickly. What if someone attacks a smaller, niche dependency? Who looks into those? The data also undercuts the assumption that the CVE feed is even complete. Sonatype’s 2026 State of the Software Supply Chain</a> report puts the catalog coverage of recent open-source CVEs at roughly 35%. The other 65% of issues are real, but not in any database your scanner is querying. The scanner is also not going to flag the next Shai-Hulud worm an hour after it is published, because there is no signature to match against yet. SBOMs answer a different question #</a> </h2> A Software Bill of Materials is a list of what is in your build. It is documentation. It does not contain any assertion about whether the listed components are safe — it just enumerates them. SBOMs are useful when you need to answer “do I have a dependency on log4j 2.14?” after a CVE drops. They do not help you decide whether to take a new dependency in the first place. The empirical picture is also bleak. Williams et al.’s Rising Tide</a> study of supply-chain practices across nine large companies found SBOM consumption at three percent adoption. That is not “early days” three percent: that is “the machinery to act on SBOMs basically doesn’t exist on the consumer side” three percent. SBOMs are being produced because regulators are asking for them, not because consumers have a workflow that ingests them. Scanners on top of SBOMs do not close the gap either. Dietrich et al. looked at 727 confirmed vulnerable shaded clones in Maven Central across 29 CVEs; the dominant SCA tools (Dependabot, Snyk, OWASP Dependency-Check, Grype) collectively flagged 20.5% of them. Even catalogued issues evade catalog-based detection when the code reappears under a slightly different name. These would have been caught if someone had looked into those dependencies. Sigstore and provenance answer yet another question #</a> </h2> Sigstore, npm provenance, PyPI’s Sigstore-bound uploads, and Go’s checksum database are all answering the question did this artifact come from where it claims to?. They are good, important answers to that question. I want them to exist, and OpenVet’s data structures are explicitly designed to compose with them rather than replace them. But “came from where it claims” is not the same as “is safe to run”. The dominant supply-chain compromises of the last two years all produced signed, attested, provenance-verified malicious releases: The xz-utils backdoor</a> was introduced by a maintainer who was, at the time, a legitimate maintainer of the project. Every release in the campaign was signed by a real key held by a real human with push rights.</li> The polyfill.io takeover</a> happened because the attacker bought the domain and the GitHub organisation of the dependency. There was no credential compromise to detect — they were the new owners.</li> The Shai-Hulud worm</a> propagated via postinstall</code> scripts published under stolen but otherwise valid maintainer tokens. Every infected release was provenance-attested to a real CI job, run from a real repo, under a real account.</li> </ul> There is also a deeper limit on what attestations can prove, even in their richest form. in-toto, the spec behind most modern attestation schemes, only constrains the chain from source to artifact: it records which steps ran, in what order, and signed by whom. It is not an auditing tool: it does not check whether the source code is correct. A maintainer with commit and signing rights (or one whose tokens have been stolen) can put malicious code straight into the git tree, and the entire chain will verify end-to-end, even with in-toto. A perfectly attested malicious release is still malicious. Provenance gates lower the rate at which unauthorised compromises succeed; they do not lower the rate at which authorised compromises succeed, and “authorised” turns out to cover a lot of the interesting attacks. For example, the Ultralytics</a> GitHub project was hijacked and published a malicious release that went through the legitimate GitHub Actions pipeline and was properly attested in Sigstore. Every signature was real, every check passed, and the release was still malicious. Dependency freezes shift the problem in time #</a> </h2> Dependency cooldowns</a> and the related “turn Dependabot off, pin everything, update on your own cadence” school (Valsorda</a>, Hoyt</a>) start from a real observation: most malicious package versions are detected within days of publication, so a consumer who waits N days before adopting a new release dodges a lot of attacks for free. The problem, as Cal Paterson pointed out</a>, is that this works precisely because someone else absorbs the attack during the cooldown window. The mechanism is structurally a free-rider on the ecosystem’s early adopters. If everyone froze for 7 days, the detection clock would simply move 7 days later, because most detections happen when the malicious code reaches consumers and one of them notices. The aggregate amount of exploitation does not go down; it just shifts to a slightly later cohort. Cooldowns do nothing against slow campaigns. xz-utils was prepared over multiple years. A 7-day cooldown is invisible to that attack. Anywhere a determined adversary is willing to wait, time-based defenses degrade to zero. There is also a second axis of dependency risk that cooldowns do not engage with at all. Cooldowns are a defense against malicious code — code deliberately placed in a release to harm consumers. They do nothing about ordinary vulnerabilities: bugs in legitimate code, undiscovered at release time, waiting to be found. The longer you stay on an old version, the more time attackers have to find exploitable bugs in the code you are still running, and the longer you remain on a version that has accumulated known issues since release. Cooldowns trade exposure to malicious new releases for exposure to slowly-accumulating vulnerabilities in old ones. The common pattern #</a> </h2> Each of these defenses is a real thing, addressing a real layer of the threat surface. CVEs answer “is this known broken?”. SBOMs answer “what is in my build?”. Provenance answers “did this come from where it claims?”. Cooldowns answer “has anyone else been hit yet?”. Pinning answers “is this still the same code I ran last week?”. None of them answer the question that actually matters when you take a dependency: has anyone competent looked at this code? That question is the one we have been collectively avoiding for two decades. We use other people’s code at a scale that has no historical precedent — the median application now pulls in around 180 transitive dependencies — and we do it almost entirely without reading what we are running. The popularity heuristic (“if a lot of people use it, someone must have looked at it”) is the implicit fallback, and it is exactly the heuristic that maintainer-handoff, typosquatting, and account-takeover attacks are designed to defeat. Sammak et al.’s 2024 interview study of 18 industry developers across 11 countries is sobering on this point: all 18 reported assessing popularity, 15 of 18 verified the recency of the last update, and 13 of 18 named dependency auditing as one of the most challenging security measures to implement at all. SBOMs, signing, and SLSA were essentially absent from the actual decisions developers reported making. So why don’t we just read our dependencies? #</a> </h2> Because there is too much code. One personal data point: my average Rust pet project pulls in around 400 transitive dependencies, summing to about 3.5 million lines of code, as measured with cargo vendor</code> and tokei</code>. Reading that, even once, is the work of months. Doing it again on every update is not a job a human can hold. And the trajectory is wrong. AI coding agents are generating code at unprecedented speed, and recent benchmarks suggest only around 10% of AI-generated code meets both functional and security bars. The volume of code entering projects without anyone reading it is growing faster, not slower. This is the part of the argument that I think is most often missed. When somebody says “just audit your dependencies”, they are either: proposing that every consumer privately performs millions of lines of review per project, on rolling updates, forever — which is not going to happen; or</li> proposing the same private audit at company scale, which is what Google, Mozilla, and the Bytecode Alliance actually do, and which produces real audit artifacts that the rest of the world cannot see1</a>; or</li> handwaving.</li> </ol> Option 1 is unrealistic at the individual level. Option 2 happens, but the artifacts are locked inside each organisation. Option 3 is what the “you should audit your dependencies” discourse usually collapses to in practice. The proactive bet: read once, share widely #</a> </h2> OpenVet’s argument is that doing the actual code-reading is the only thing that actually answers the question — and that the only way to make it sustainable is to do it in the open. If you read a dependency and publish a signed, machine-readable audit of what you read, then everyone who trusts you gets to stand on that work without re-reading the code themselves. The marginal cost of adding another audited consumer drops to zero. The trust model is the load-bearing piece. You don’t have to trust every audit; you choose whose audits you trust. Maybe you trust Mozilla, the Bytecode Alliance, some well-known cryptography researchers, and three of your friends. Maybe you also trust a vendor you work with. A dependency passes your policy when the union of audits from people you trust covers it. If nobody you trust has audited it, you have a clear, actionable signal: either you do the audit yourself (which OpenVet tries to make as easy as possible), or you find a dependency that someone you trust has reviewed. This is proactive in the specific sense that it answers the question before you ship the dependency, not after the incident response. You read the code while you are depending on it, not three months later when the CVE rolls in. And because the work is shared, you do not have to read all 3.5 million lines yourself: you only have to audit the slice that nobody you trust has audited yet. And there is one aspect that none of the other approaches cover at all. OpenVet is a tool you can use to detect malicious code, but it does not end there. What about correctness? Vulnerability databases focus on code that is exploitable, but not on code that is just broken. By auditing your dependencies, you can not only surface malicious behaviour, but you can also check for other properties, such as correctness, test coverage, and overall implementation quality. Audits don’t need maintainer cooperation #</a> </h2> There is one more structural property of the audit channel that the attestation-based defenses do not have: it does not require the maintainer to do anything. Every signing scheme — npm provenance, PyPI attestations, in-toto layouts, Sigstore-bound publishes — depends on the publisher of a package opting in. That turns ecosystem-wide adoption into a coordination problem across millions of independent maintainers, and the numbers show it is going slowly. Williams et al. put attestation production at 0.17 across major industry adopters and provenance delivery at 0.08. Your security model cannot realistically be “I will contact every maintainer in my dependency tree and convince them to emit attestations”. OpenVet sits on the other side of that boundary. An audit is something anyone who can read the code publishes about a package, with zero cooperation required from the upstream maintainer. If a crate’s maintainer has never heard of signing, an auditor can still publish a useful audit of it. If a package’s maintainer is unreachable, an auditor can still review it. The bootstrap problem is much smaller: you do not have to convince every npm publisher in the world to flip a switch. You just need a community of reviewers willing to read code, and a way to share their work. It is also why this is a thing you can deploy today, without waiting on the rest of the ecosystem to catch up. Reactive defenses still matter #</a> </h2> I want to be clear that I am not arguing against the reactive layer. Provenance, signing, SBOMs, and CVE feeds are all genuinely useful and OpenVet is designed to compose with them, not displace them. Andrew Nesbitt makes the honest version of this case in Signing is for the bad days</a>: the value of signing infrastructure shows up when something has already gone wrong — forensic clarity, identity binding, the ability to tell whether a malicious release came from a stolen token or a poisoned build cache. He is right about that. The reactive layer is the thing that helps you survive a bad day. It just should not be the layer that decides whether to install the dependency in the first place. Provenance is useful to capture where binary artifacts came from. You typically can’t meaningfully audit binary artifacts, so provenance doesn’t tell you whether they are safe — but it does at least tell you where they came from, which is often the best you can do.</li> SBOMs give you the inventory you need to ask, after a disclosure, “do I have this thing in my build?”. They also give you legal compliance, in jurisdiction where that is required.</li> CVE feeds tell you when somebody else has caught an issue you missed. One feature I am working on with OpenVet is re-publishing data from CVEs and various vulnerabilities as OpenVet audits, so the tooling can ingest those as well.</li> </ul> These should be present. They just should not be the front line. A defense layered entirely on “what the rest of the ecosystem has already learned” is a defense that accepts being late as a feature. The front line should be “somebody I trust read this code”, and the reactive feeds should sit behind that as a backstop for the cases the audits did not catch. What OpenVet is doing about it #</a> </h2> Concretely, OpenVet’s design follows from this position in a few specific ways: Audits are first-class artifacts. They are signed, structured, and machine-readable. They carry claims, findings, source-anchored annotations, and a structured report. They are not a side effect of some other workflow.</li> Audits are publicly shareable by default. The registry hosts them under permissive licenses (CC0 or CC-BY-4.0</a>) so that consumers can actually use, redistribute, and build on them.</li> Trust is rooted in publishers, not in the platform. Consumers pick whose logs they trust. The registry holds the bytes, the signatures and the cryptographic chain hold the trust.</li> The tooling is built around lowering authoring cost. Creating and publishing your first audit should take minutes, not days. If the marginal cost of publishing one more audit is high, the ecosystem will not scale.</li> </ul> The bet is that, if we can get the cost-sharing right, an ecosystem where most of the code most people depend on has been read by somebody they trust is actually reachable. It is not reachable by asking every consumer to read everything. It is not reachable by hoping a CVE feed catches the bad stuff in time. It is reachable by splitting the work and making the result legible across the network of people who already trust each other to some degree. That is the part of the problem none of the reactive defenses are trying to solve, and it is the part OpenVet is built around. ^1Google, Mozilla and some other companies are auditing their dependencies. They publish some of these audits</a> in the form of cargo-vet</code> audits. But these published audits only cover Rust libraries, and don’t seem to be updated very often. </div>



OpenVet 0.6.0 Release
2026-05-31T00:00:00+00:00
OpenVet 0.6.0 is out.</strong> I managed to sneak some breaking changes into the
data structures again. Two important commands were included in this release:
openvet info</code> allows you to query audit data about the dependencies in your
project, and openvet guard</code> is my first attempt at integrating the OpenVet
checks into existing developer flows.</p>
I also took the time to audit every single dependency of OpenVet with OpenVet
itself, some dogfooding that allows me to test how this all fits together.</p>
The rest of this post walks through the changes that matter from a user’s
perspective: the guard wrapper, the dependency lookup, the new per-dependency
narrative on audits, the new --project</code> flag for root auto-discovery, and the
wire-format breaks to be aware of if you have audits authored against 0.5.0.</p>
All direct dependencies of OpenVet are audited
#</a>
</h2>
The 0.5.0 release post ended with 111 audits in the OpenVet log. In 0.6.0 that
grew to 572, covering every direct dependency the OpenVet workspace pulls in,
with the project’s own openvet.toml</code> requirements satisfied end-to-end.
Running openvet check</code> against the workspace now passes cleanly:</p>
$ openvet check</span></span>
[..]</span></span>
Summary: 572 passed, 0 failed, 0 unaudited, 14 skipped</span></span></code></pre>
This is the first project that has a full audited-dependencies workflow.  All
audits are hosted in my log at openvet.org/xfbs</a>.
You can take a look at them if you are curious. Note that most of them are
generated with the help of an LLM: My goal here was not to produce the most
perfect audits, but to exercise every part of the data structures and to test
the flow end-to-end. For some heavy dependencies, I only did a light audit,
which did not evaluate all claims. And I have had to add some overrides.
This models a reasonable real-world usage of OpenVet.</p>
Notably, many of the design decisions (content-addressing, caching, compression)
seem to be working well. Once you’ve populated the cache on the first run, checking
takes only a couple hundred milliseconds:</p>
$ time openvet check</span></span>
[..]</span></span>
openvet check  0.10s user 0.02s system 84% cpu 0.139 total</span></span></code></pre>
Running it with an empty cache is reasonable. This will do about ~600 network
requests. It is fast because the OpenVet Registry has a CDN, will transparently
serve pre-compressed objects, and network requests are issued in parallel.</p>
$ rm ~/.cache/openvet/cache.db</span></span>
$ openvet check</span></span>
[..]</span></span>
openvet check  0.44s user 0.34s system 20% cpu 3.752 total</span></span></code></pre>
The cache size is reasonable:</p>
$ ls -lah ~/.cache/openvet/cache.db</span></span>
-rw-r--r-- 1 patrick  patrick   6.6M May 31 14:49 /home/patrick/.cache/openvet/cache.db</span></span></code></pre>
There is currently no garbage collection for the cache. If the cache grows too
large, you would need to just delete it. That is something that is on my
roadmap. But given that the size of it is in the megabytes, I am not too
worried about that yet.</p>
openvet guard</code> — block a build until policy passes
#</a>
</h2>
OpenVet is not useful if it’s only advisory: the way that OpenVet becomes
useful is by integrating it into developer flows, so that it blocks you from
executing code that does not match your requirements. Doing that is not
trivial, and there are different ways that I am exploring. What I built into
this release is openvet guard</code>, which is intended to be used as a kind of
proxy for running commands. It takes a command that you want to run, runs
openvet check</code> quietly, only executing the command if the check passes. The
intended use is a shell alias:</p>
alias</span> cargo</span>=</span>'</span>openvet guard cargo</span>'</span></span></code></pre>
With that in place, every cargo build</code>, cargo test</code>, cargo run</code> in the
project first checks that all dependencies match the project’s openvet.toml</code>
requirements, and only proceeds when they do. Forget to audit a new dependency
you just added? cargo build</code> won’t run. Add a dependency whose existing audit
contradicts a requirement? Same.</p>
On block, you get the same per-subject failure trees that openvet check</code> prints, followed by an error summary so the reason is
unmistakable:</p>
$ cargo build</span></span>
✘ cargo:some-new-crate@0.3.0</span></span>
└─ requires: is-benign</span></span>
   └─ no audit asserts is-benign</span></span>
</span>
error: 1 subject(s) did not pass policy (run `openvet check` for details)</span></span></code></pre>
On pass, guard is silent, so the wrapped command’s output starts immediately.
The exec is in-place, so signals and exit codes flow through unchanged.
Hyphenated arguments after the command are forwarded verbatim (openvet guard cargo build --release --features foo</code> works as expected).</p>
Outside an OpenVet project, guard’s behaviour is configurable via a new
[guard]</code> section in the user config. The default is strict = false</code>, which
runs the wrapped command transparently — so aliasing cargo</code> globally doesn’t
break anything in scratch directories. Flip to strict = true</code> and guard
refuses to run the wrapped command anywhere that isn’t an OpenVet project,
except for paths you’ve explicitly excluded:</p>
openvet</span> config</span> guard.strict</span> -</span>-set</span> true</span></span>
openvet</span> config</span> guard.exclude</span> -</span>-set</span> "</span>~/Projects/alacritty,~/scratch</span>"</span></span></code></pre>
Unix-only for now.</p>
openvet info</code> — a man-page for a project dependency
#</a>
</h2>
openvet info <registry>:<package>[@<version>]</code> finds every matching
subject in the project’s lockfiles and renders each matching audit as
a flat, reflowed document. The default view is short — claims and
summary — with longer sections opt-in via flags:</p>

-r</code>, --report</code> long-form report</li>
-f</code>, --findings</code> findings (with --severity</code> / --class</code> to triage)</li>
-n</code>, --annotations</code> source annotations</li>
-d</code>, --deps</code>  declared direct dependencies (with the new per-dependency
narratives, see below)</li>
-u</code>, --users</code> reverse dependencies (which of your audited packages declare
this one as a dep)</li>
-a</code>, --all</code> everything at once</li>
</ul>
Short examples:</p>
openvet</span> info</span> cargo:serde</span>                  #</span> claims + summary, paged</span></span>
openvet</span> info</span> cargo:serde@1.0.210</span>          #</span> pin a version</span></span>
openvet</span> info</span> -</span>rfd</span> cargo:serde</span>             #</span> report, findings, deps</span></span>
openvet</span> info</span> -</span>a</span> cargo:serde</span>               #</span> the whole picture</span></span>
openvet</span> info</span> cargo:serde</span> -</span>-severity</span> high</span>  #</span> only high-severity findings</span></span>
openvet</span> info</span> -</span>u</span> cargo:serde</span>               #</span> who in my project uses it</span></span></code></pre>
The reverse-dependency mode (-u</code>) is probably the most interesting feature.
If you have a dependency that has a soundness or safety issue, or some security
findings, you need to make a decision: is this dependency okay to use? There
are cases where dependencies have an issue that only surfaces if you use a
specific API, or if you use them on a specific platform.</p>
Let’s say you want to check package frobnication</em>. With the reverse-dependency
mode, OpenVet will scan all of the other</em> dependencies in your project to see
if any of those use frobnication</em>, and surface that to you, with a description
of how</em> the frobnication</em> package is used. This should give you some data to
help you decide if it is safe to use frobnication</em>, even if it has a known
issue.</p>
Here’s an example of what the output looks like, this is the output of openvet info -u cargo:sha1</code>:</p>

cargo:sha1@0.11.0#sha256:aacc4cc499359472b4abe1bf11d0b12e688af9a805fa5e3016f9a386dc2d0214</strong></p>
Audit 57cbe92225e8 (from xfbs)</strong></p>
crypto-impl-correct=true, crypto-impl-safe=true, crypto-impl-tested=true, has-binaries=false,
has-build-exec=false, has-fuzz-tests=false, has-install-exec=false, has-integration-tests=true,
has-property-tests=false, has-unit-tests=false, impl-algorithm=false, impl-concurrency=false,
impl-crypto=true, impl-datastructure=false, impl-interpreter=false, impl-jit=false,
impl-parser=false, impl-protocol=false, is-benign=true, unsafe-documented=true, unsafe-minimal=true,
unsafe-safe=true, unsafe-tested=true, uses-concurrency=false, uses-crypto=false,
uses-environment=false, uses-exec=false, uses-filesystem=false, uses-interpreter=false,
uses-jit=false, uses-network=false, uses-unsafe=true</p>
sha1 0.11.0 is the RustCrypto SHA-1 (FIPS 180-4) implementation with four backends (portable soft,
x86 SHA-NI, ARMv8 SHA1, LoongArch64 asm); the source matches upstream, unsafe is minimal and
properly gated, and KAT vectors plus a 16 MiB feed test exercise all backends. One high-severity
finding: SHA-1 itself is cryptographically broken — unsuitable for any new collision-sensitive use;
the crate exists for legacy interop.</p>
Reverse Dependencies</strong></p>
cargo:axum@0.8.9 -> cargo:sha1@0.10</strong></p>
Optional (ws feature). SHA-1 digest used to compute the Sec-WebSocket-Accept handshake header value
as specified by RFC 6455. Not used for security, only for protocol compliance.</p>
cargo:rsa@0.9.10 -> cargo:sha1@0.10.5</strong></p>
Optional dependency, used as a hash function for PKCS#1 v1.5 and OAEP operations in examples and
tests. Not included in the default feature set.</p>
cargo:ssh-key@0.6.7 -> cargo:sha1@0.10</strong></p>
Optional dependency, gated behind the sha1 feature. Provides SHA-1 used by the legacy Md5/Sha1
fingerprint formats and by the known_hosts HMAC-SHA1 host-name hashing scheme.</p>
cargo:zip@8.6.0 -> cargo:sha1@0.11</strong></p>
Optional dependency behind the aes-crypto feature. Provides the SHA-1 hash function as the primitive
for PBKDF2 and HMAC in the WinZip AES key derivation and authentication scheme.</p>
</blockquote>
Output paginates through a git-style pager (OPENVET_PAGER</code>, then $PAGER</code>,
then less -FRX</code>) when stdout is a terminal. --no-pager</code> turns it off.</p>
Because the reverse-dependencies mode needs to walk all audits for all
dependencies in your project, there is a slight delay (~100ms) when using that
mode. I am considering using caching to make this faster, but for now I am okay
with the slight inefficiency.</p>
Per-direct-dependency narratives on audits
#</a>
</h2>
Closely tied to info -u</code> above. Audits now carry an Audit.dependencies</code> field
with the auditor’s prose answer to why does this package need this dep</em> and
how does it use it</em> for each declared direct dependency. The audit body is
what reaches the consumer alongside the claims and findings. So a downstream
consumer triaging a disclosure against dep X</code> can read the entries on his
audited packages that depend on X</code> to judge whether the weakness is reachable
in his composition.</p>
The authoring side is automated where it can be:</p>


openvet audit new</code> auto-seeds the list from a new openvet-package</code>
extractor — one entry per resolved dependency with an empty description for
the auditor to fill in. The full extractor output (including the entries it
skipped, like git URLs and path deps) is written to dependencies.json</code> next to
audit.pb</code> as an auditor-local sidecar, never signed, never published.</p>
</li>

A new openvet audit dependency</code> subcommand manages the list at authoring
time, letting you list, show, edit dependency metadata in audits.</p>
</li>
</ul>
The linter enforces a non-empty description on every entry, and warns inside a
workspace when the extractor sees a dep the audit doesn’t carry. The server’s
publish handler runs the same description check at publish time, so an audit
with empty descriptions cannot enter a log even by bypassing the CLI.</p>
The extractor itself is a meaningful addition on its own: every shipping
registry adapter (cargo, npm, pypi, rubygems, go) now parses its native
manifest and surfaces direct dependencies with their registry, package,
requirement, scope (runtime vs build), and an optional</code> flag.</p>
VCS provenance on audits
#</a>
</h2>
Sibling to the dependency narratives, audits also gained an optional
Audit.vcs</code> field that records where the audited package’s source is hosted in
version control: clone URL, optional commit hash, optional subdirectory for
monorepo packages. Registry-published VCS metadata is sometimes missing,
sometimes wrong, and sometimes unreachable; this field captures what actually
worked</em> so a downstream consumer can navigate to the same source the auditor
reviewed.</p>
openvet audit new</code> records what cloned successfully. It has some retry and
fixup logic, rewriting some git://</code> and ssh://</code> URLs to https://</code>. Many
registries don’t validate the git URLs, and some of them are broken. We fix
them on a best-effort basis, but sometimes it needs manual work to discover the
proper VCS URL.</p>
A new openvet audit vcs</code> subcommand inspects, sets, or clears the field.
--commit</code> accepts only 40-character SHA-1 or 64-character SHA-256 hex strings:
tag names and branch names are rejected, because a tag-pinned audit can
silently start covering different source if someone moves the tag.</p>
openvet audit check</code> warns when a recorded provenance has no commit. A Git URL
without a pinned revision means the repo HEAD could move under the audit.</p>
Project root auto-discovery
#</a>
</h2>
OpenVet now discovers the project root by walking up the filesystem and
locating the openvet.toml</code> file, similar to how git</code> and cargo</code> operate.</p>
Previously, commands only worked in the root folder of projects, and I had
separate --config</code> and --lockfile</code> flags. Not because that is the right way
to build it, but I needed a way to override these for unit tests.  I’ve now
done it properly, with either the parent-traversal for automatic discovery, or
a --project</code> flag that lets you point at the project root. The
OPENVET_PROJECT</code> environment variable can also be used to override this.</p>
Other things worth a quick mention
#</a>
</h2>


openvet check</code> runs ~3.5× faster on a cold cache.</strong> Per-subject audit
lookups and the up-front head prefetch now fan out across logs and subjects
with bounded 16-way concurrency. Output order is preserved, so the listing
stays diff-stable across runs.</p>
</li>

openvet check</code> explains not-asserted requirements.</strong> When a requirement
neither passes nor is contradicted because the claims it rests on were never
asserted, check</code> now prints the same per-audit expression tree it already
shows for contradictions. The unevaluated claim is visible in the tree rather
than collapsed to a bare not asserted</code> line.</p>
</li>

openvet update <log></code> accepts a single log name.</strong> Refreshes only the
named log’s pin and leaves every other entry in openvet.lock</code> untouched. The
bare openvet update</code> still refreshes every configured log.</p>
</li>

File annotations carry a per-file content hash.</strong> A new required
FileTarget.content_hash</code> field (32-byte BLAKE2b-256) binds each file
annotation’s body and per-line ranges to the exact byte sequence the auditor
reviewed at that path. The audit’s subject.hash</code> already commits to the
archive as a whole, but per-annotation hashes let a consumer detect (and
openvet audit check</code> flag) annotations whose target file has drifted under
them without re-deriving the manifest.</p>
</li>

Audit subject binding is now enforced at publish.</strong> A new spec invariant
requires that InsertAudit</code> and UpdateAudit</code> operations carry the same
subject</code> as the embedded audit’s audit.subject</code>. This closes a hole where a
hostile client could put an audit for one subject under a different tree key,
misleading any consumer querying for that key.</p>
</li>

Commit timestamp monotonicity and admission window.</strong> Every published
commit’s timestamp</code> must be greater than or equal to its predecessor’s, and
the server rejects commits whose timestamp</code> is more than 15 minutes away from
its wall clock. Publishers whose system clock is badly off will see a 400 Bad Request</code>, fix by running NTP. This makes KeyState revocation more easily
verifiable: monotonic time means commits cannot be backdated, which allows
key expiry to work correctly.</p>
</li>
</ul>
Wire-format breaks
#</a>
</h2>
0.6.0 is another breaking pre-1.0 release. If you have audits
authored against 0.5.0, the things to know:</p>


FileTarget.content_hash</code> is now required. Audits produced by earlier
releases (where file annotations had no content_hash</code>) fail to decode. The
path forward is to re-run openvet audit annotate <path></code> over each file
annotation, which reads the manifest, validates against the on-disk contents,
and stamps the content hash onto the annotation.</p>
</li>

New optional fields (Audit.dependencies</code>, Audit.vcs</code>) decode as empty /
None</code> on older blobs and are ignored by older readers, so they don’t break
wire compatibility.</p>
</li>

A handful of source-level renames in the protocol crates (CommitSigned</code> →
CommitEnvelope</code>, AuditSigned</code> → AuditEnvelope</code>, Publish</code> → Bundle</code>,
apply</code> → build_commit</code>, etc.). Wire bytes are unchanged for these; only Rust
crate consumers see the rename. If you depend on openvet-proto</code> or
openvet-log</code> directly, your imports need updating.</p>
</li>
</ul>
The full per-bullet migration notes live in CHANGELOG.md</code></a> in the
CLI repo.</p>
What I’m working on next
#</a>
</h2>
Some of the ideas that I listed in the 0.5.0 release I still haven’t gotten to,
but they are still on the roadmap. There is a long list of features I still
need to design, implement and/or test.</p>
One feedback that I got from talking to @muji</a>
(thanks for taking the time!) was that the per-project config that OpenVet uses
may not work well for all users. He suggested that it should support a way to
use OpenVet as a global proxy for package registry operations. This is
something that I need to think through, design and test. There are different
ways this could be implemented: a proxy running on your local machine, or a
hosted proxy that organizations can use to configure an organization-wide
policy and overrides.</p>
I see different mechanisms with different goals here:</p>

An organization-wide or system-wide proxy allows you to set a policy that
applies to all</em> projects. You can use this to enforce an organization-wide
policy, like a baseline that all projects need to use, or for individual
users it could be used to set a system-wide policy with a minimum set of
requirements.</li>
A project configuration can be used to set more specific requirements. You
may not need this at all. Or this can be used to set more granular
requirements, depending on the needs of a project.</li>
</ul>
The over-arching goal of OpenVet is to make it as easy as possible for both
individuals and organizations to adopt it. So getting this right matters a lot,
and it requires me to do a lot of prototyping, testing, and talking to people
to get some outside perspectives.</p>
There are some alternative implementation approaches that I want to test out
for the OpenVet guard mode that don’t involve an alias, so that tooling (IDEs)
can use them too. I know roughly what those would look like, but I haven’t
implemented them yet.</p>
I put together some thoughts on the Licensing of audits hosted on the
OpenVet registry</a>,
which I have not implemented in this version yet, but will land in the
next version.</p>
I’ll keep posting here as these land.</p>
Find it / report it
#</a>
</h2>

Install:</strong> cargo install openvet</code></li>
Source:</strong> gitlab.com/openvet-org/openvet</a></li>
Docs:</strong> docs.openvet.org</a></li>
Changelog:</strong> CHANGELOG.md</code></a></li>
Issues:</strong> the GitLab tracker on the CLI repo. Issues and MRs
are very much welcome — this is still a one-person project and
any extra eyes help.</li>
</ul>
If you’d rather reach me directly, my GitHub profile has the
contact info.</p>


Licensing of audits hosted on the OpenVet Registry
2026-05-30T00:00:00+00:00
The OpenVet Registry hosts audits that its users produce, and the whole point
is that those audits are freely accessible to anyone who wants to consume them.
The whole reason I am building the OpenVet Registry, that I am hosting it, and
that I am licensing it as AGPL is that I think audits should be a public good,
and supply-chain security should not be a subscription model.</p>
“Freely accessible” sounds nice in a marketing sentence, but it is not a
legally meaningful statement. If we want consumers to actually be able to use</em>
the audits they download — read them, depend on them, redistribute them, build
on top of them — we need to encode what “freely accessible” means in terms that
copyright law understands. That means licensing.</p>
This post is about how I’m planning to approach that.</p>
Audits are original work
#</a>
</h2>
One thing that makes the licensing question tractable is that audits, as
OpenVet defines them, are completely original work. They do not embed the
code they describe. An audit can annotate a piece of code, but the annotation
refers to the source by file path and line number — it does not include the
source itself. Findings, claims, and the report text are all written by the
auditor.</p>
This matters because it means a single audit can be covered by a single
license. There is no embedded third-party material that needs to be tracked
or licensed separately. The auditor wrote the audit, the auditor owns the
copyright, and the auditor gets to pick the license.</p>
The license attribute
#</a>
</h2>
Audits already have a mechanism for carrying meta-data about the audit
itself (as opposed to data about the thing being audited). We call these
attributes</em>. The natural place to encode the license is as one of these
attributes, set to an SPDX</a> license identifier.</p>
That answers the how</em>. The harder questions are:</p>

What licenses are reasonable for audits to be published under?</li>
Should the registry require specific licenses, or accept anything?</li>
</ul>
What licenses make sense
#</a>
</h2>
The registry only exists because audits get more useful when they are
shared. If somebody publishes an audit under a license that prevents others
from using it — anything non-commercial, anything that forbids
redistribution, anything bespoke that consumers need a lawyer to read —
there is no point in hosting that audit on a public registry. The whole
value proposition collapses.</p>
So the set of acceptable licenses needs to be narrow enough that consumers
can use audits without thinking about it, and wide enough to cover the
reasonable preferences authors have. My argument is that, at least for now,
that set should be exactly two licenses: CC0</strong> and CC-BY-4.0</strong>.</p>
Both are well-understood, both are permissive enough to be useful, and they
differ in exactly one meaningful way:</p>

CC0</strong> is effectively a public-domain dedication. The author gives up
their rights and the work can be used by anyone for any purpose with no
obligations attached.</li>
CC-BY-4.0</strong> allows the same uses, but requires attribution: if you
redistribute or build on the work, you have to credit the original author.</li>
</ul>
Either license makes audits useful in the way I want them to be. A consumer
can pick up an audit, improve it, and re-publish the improved version. If
the original was CC0, no strings attached. If it was CC-BY-4.0, the
improved version needs to credit the original author. Both of these are
reasonable workflows for a collaborative auditing ecosystem.</p>
This is not a novel choice. RustSec</a> uses the same pair: their own
original advisory content is published under CC0, and they also ingest
GitHub advisories, which are CC-BY-4.0. The intersection of “useful for a
public security database” and “common enough that people will actually
pick it” lands in roughly the same place for both of us.</p>
Why enforce it, and why now
#</a>
</h2>
The registry could accept any license and let consumers sort it out. I
think that would be a mistake.</p>
If we do not enforce a license attribute from the start, we end up with a
collection of audits with unclear licensing. Some will have no license at
all (which, under default copyright law, means consumers cannot legally
redistribute them). Some will have hand-rolled licenses that consumers
have to read individually. Cleaning that up after the fact is much harder
than getting it right from day one — you have to track down every author
and ask them to re-license, and any author who has gone silent leaves a
permanent hole in the dataset.</p>
It is always possible to relax</em> the requirement later. If, in a year, it
turns out that there is a strong case for adding a third license to the
allow-list, that is a one-line registry change and existing audits remain
valid. Going the other direction — tightening the rules after the fact —
would mean breaking or removing existing audits, which is the kind of
thing that erodes trust in a registry.</p>
So: enforce a license attribute, and limit it to CC0 or CC-BY-4.0.</p>
Cross-posting from other sources
#</a>
</h2>
One of the use cases I want this scheme to support is cross-posting</em>
existing vulnerability data into the audit format. I would like to be able
to write a tool that ingests, say, RustSec advisories, and generates
(either automatically or with human review) an audit whose findings and
claims encode what that advisory says. The same goes for GitHub Security
Advisories, and for CVE data.</p>
The CC0 / CC-BY-4.0 allow-list covers this cleanly for the sources I care
about most:</p>

RustSec</strong> advisories are CC0, so they can be republished under either
CC0 or CC-BY-4.0 with no friction.</li>
GHSA</strong> entries are CC-BY-4.0, so a cross-posted audit can carry that
license and the attribution requirement is satisfied by crediting the
original advisory.</li>
CVE</strong> data is more nuanced. The structured facts (affected versions,
identifiers, references) are not copyrightable on their own, so summarizing
them in our own words produces an original audit that we can license
freely. Verbatim copying of CVE descriptions would fall under the CVE
program’s terms of use, which is a special case I do not want to add to
the allow-list.</li>
</ul>
In other words, the policy is “audits in the registry are CC0 or
CC-BY-4.0”, and the cross-posting workflow has to produce audits that fit
inside that policy. Any source whose terms do not fit gets summarized in
the audit author’s own words, or it does not get cross-posted.</p>
Implementation
#</a>
</h2>
The default workflow to create audits uses the command-line interface of
OpenVet. I am changing this tooling to insert a default license of CC0</strong>,
with a message stating it has done so. The attribute can be overridden using
the audit commands, like this:</p>
openvet audit attribute license --set CC-BY-4.0</span></span></code></pre>
In the registry, I am implementing a check to require a license attribute to be
present, and for it to be one of the licenses in the allow-list. OpenVet
does not force you to use any of these licenses. Only the registry requires
published</em> audits to have one of these two licenses.</p>
Summary
#</a>
</h2>

Audits are original work, so a single license per audit is enough.</li>
The license will be encoded as a license</code> attribute on the audit, using an
SPDX identifier.</li>
The registry will only accept CC0 or CC-BY-4.0.</li>
Enforcing this from the start avoids a permanent licensing-mess in the
dataset; the allow-list can always be relaxed later.</li>
The same allow-list happens to make it straightforward to cross-post
audits derived from RustSec, GHSA, and (with care) CVE data.</li>
</ul>


Supply-Chain Update #1
2026-05-23T00:00:00+00:00
Updates on supply-chain security, vulnerabilities, attacks and mitigations.
I try to summarize interesting articles I come across, and post these,
targeting a biweekly cadence.</p>
Vulnerabilities
#</a>
</h2>
CVE-2026-46529: 10-year-old RCE in Linux PDF Viewer (XReader/Evince/Atril)</a>
#</a>
</h3>
Claude Code helped find a bug in several Linux PDF viewers
(Evince/Atril/XReader) that use the Evince codebase for rendering PDFs. The
author tried fuzzing, which did not yield results. Looking through the codebase
for suspicious code revealed the ev_spawn</code> function, which is used to
implement the /GoToR</code> (go-to-remote) PDF function, which is used to open
external documents. This function is implemented using an exec()</code> call and is
susceptible to injection attacks, because injected parameters are not properly
shell-escaped.</p>
Supply-Chain Attacks
#</a>
</h2>
Investigating unauthorized access to GitHub-owned repositories</a>
#</a>
</h3>
GitHub was hit with a supply-chain attack involving a malicious VS Code
extension. The attackers were able to exfiltrate the contents of 3800 internal
git repositories used by GitHub.</p>
Megalodon: Mass GitHub Repo Backdooring via CI Workflows</a>
#</a>
</h3>
5,561 GitHub repositories received malicious workflow commits which exfiltrate
CI environment variables and various credentials (including AWS, GCP, SSH,
databases, APIs, GitHub Actions). The commits which added the malicious GitHub
workflow configurations were pushed straight to master with no pull-request,
likely using a compromised personal access token or deploy key.</p>
This attack does not affect downstream consumers of the affected packages, it
only works to exfiltrate secrets from the CI pipelines, which would later give
attackers the means to further compromise those affected packages.</p>
TeamPCP’s Mini Shai-Hulud Is Back: A Self-Spreading Supply Chain Attack Compromises TanStack npm Packages</a>
#</a>
</h3>
To quote from the article:</p>

Mini Shai-Hulud is a true worm: after stealing credentials from one CI/CD
pipeline, it enumerates every package that maintainer controls and publishes
infected versions of each. The 2.3 MB obfuscated payload reads GitHub Actions
runner process memory to extract every secret, harvests credentials from over
100 file paths spanning cloud providers, cryptocurrency wallets, AI tools,
and messaging apps, and installs persistence hooks in Claude Code, VS Code,
and OS-level services that survive reboots. Stolen data is encrypted and
exfiltrated through the Session Protocol CDN and GitHub’s own GraphQL API,
where dead-drop commits are authored as claude@users.noreply.github.com and
disguised with Dependabot-style branch names drawn from Frank Herbert’s Dune
universe.</p>
</blockquote>
Grafana Labs security update: Latest on TanStack npm supply chain ransomware incident</a>
#</a>
</h3>
Grafana was affected by the TanStack</em> NPM supply-chain ransomware event (also
called the Mini Shai-Hulud</em> attack). According to them, the attack did not
affect customer production systems or the Grafana Cloud platform. Business
contact names and email addresses that would be exchanged in a professional
relationship context were leaked. Their reaction is to harden their CI and CD
pipelines.</p>
Reverse engineering android malware with claude code</a>
#</a>
</h3>
Not really software</em> supply-chain security, but nevertheless interesting:
cheap gadgets bought from Chinese vendors come pre-loaded with malware.
Oftentimes, such hardware is used to implement residential VPNs</em>: they allow
other people to use your internet connection (and thus your IP address) to
access the internet. These types of VPNs are popular because residential IP
addresses often bypass detection systems for automated requests. This article
contains a writeup examining an LED projector, figuring out how the malware is
pre-loaded, and analyzing how it works.</p>
Security
#</a>
</h2>
Apple: A blueprint for formal verification of Apple corecrypto</a>
#</a>
</h3>
Apple is formally verifying their CoreCrypto framework, which implements post-quantum
cryptography. They are using Cryptol and Isabelle to do so. Their verification efforts
have surfaced real correctness issues.</p>
CoreCrypto ships on billions of Apple devices, so a verified implementation
removes a class of supply-chain risk from every system that depends on it.
Verifying post-quantum primitives is particularly high-leverage: the algorithms
are new and structurally complex, and implementation bugs are easy to miss in
normal review or testing. The most useful signal from Apple’s writeup is that
the work already surfaced real correctness issues — i.e. formal methods caught
things conventional QA didn’t. It also fits a broader pattern this issue
touches on (AWS’s s2n-tls, Jane Street’s growing interest per the Minsky talk
below): formal verification is moving from “academic” to “practical at
production scale.”</p>
Cloudflare: Project Glasswing: what Mythos showed us</a>
#</a>
</h3>
Cloudflare talks about finding security issues with Mythos in their
participation in Project Glasswing. They explain that in general, LLMs are
useful at finding issues in code, but they work best when given direction and
context. They also explain that the output can be very noisy, with
false-positives being included in the output, and with the models not being
able to express accurate certainty (hedging). Cloudflare explains the harness
they use to refine the output.</p>
The First CVE Wave: Signs That AI-Assisted Vulnerability Discovery Is Reshaping Disclosure Volumes</a>
#</a>
</h3>
The article claims that CVE disclosure volumes are up sharply year-to-date
(YTD) across several software suppliers, ranging from 100% to 500% increase
compared to last year. Much of the growth of discovery of vulnerabilities can
be attributed to the availability of LLMs.</p>

The evidence appears to point to emerging AI models that have enabled
software suppliers and security researchers to discover and remediate
vulnerabilities that would have likely gone overlooked otherwise.</p>
</blockquote>
The article walks through several projects and companies, examining their
vulnerability disclosures, closing with some thoughts about how this impacts
software security:</p>

What’s less clear is whether these volumes will be sustained, or whether this
is a temporary surge as better AI models are pointed at different code bases
and new models continue to surface vulnerabilities.</p>
</blockquote>
I think one graphic, produced by Mozilla, stands out and does a good job summarizing
the situation:</p>
</p>
Turso: How we used Quint to find over 10 bugs in SQLite while hardening Turso</a>
#</a>
</h3>
Quint</a> is a specification language in the TLA+ family for modelling state
machines and their transitions. From a spec you can model-check invariants and
generate traces that explore behaviour conventional tests rarely reach.</p>
At Turso, they used this to build a specification of the SQLite API, generated
a list of traces, translated those into programs exercising both SQLite’s C API
and Turso</em> (the company’s SQLite-compatible re-implementation in Rust). In
doing so, they were able to find and fix over 10 bugs in SQLite, in addition to
improving Turso. To quote:</p>

Formal methods, and Quint in particular, were able to explore parts of the
specification that the Turso simulator previously could not. The general
concepts are similar, but instead of generating a random sequence of SQL
statements and enforcing system-level properties, Quint generates a list of
traces that can then be translated into any substrate we want.</p>
In this case, we translated Quint traces into a C program that interacted
with the C API. Turso got better thanks to this endeavor. So did SQLite: at
least 10 bugs were found, reported, and fixed.</p>
SQLite is a magnificent piece of software that has been around and thoroughly
tested for decades. And yet, bugs were lurking that previous disciplines did
not catch. Formal methods did.</p>
</blockquote>
Mitigations
#</a>
</h2>
GitHub: Staged publishing and new install-time controls for npm</a>
#</a>
</h3>
Staged publishing is available for NPM. With this opt-in change, pushes of new
versions of packages (commonly originated from workflow runs) are not live
immediately. Instead, they are pushed into a publish queue and need to be
manually accepted. Also documented on the NPM docs</a>.</p>
Dependency cooldowns are unfair; we should use phased rollouts instead</a>
#</a>
</h3>
Scott Robinson argues that instead of dependency cooldowns (where downstream
projects don’t update their dependencies to the latest versions, but the latest
versions which have been released for at least N</em> days), phased rollouts</em>
should be used.</p>

I propose that instead of “everyone waits N days,” package managers should
deterministically map projects into a rollout window based on stable inputs:
a project-specific identifier, package name, version, and artifact digest.
The result is a globally distributed adoption curve rather than
timezone-based canaries.</p>
</blockquote>
Culture
#</a>
</h2>
Open-Source Resistance: Keep OSS alive on company time</a>
#</a>
</h3>
A “radical” proposal for employees of tech companies to help maintain
the open-source infrastructure the company depends on, on company time:</p>

The Open Source software your work relies on is maintained by others who also
work. Evenings and weekends alone cannot maintain it. Stop begging massively
profitable companies for time to fix things. Join the Open Source Resistance:
quietly, professionally and on company time, doing what needs done.</p>
</blockquote>
This relates to supply-chain security because this idea formalizes something
that is already the case: the dependencies (supply-chain) are part</em> of the
product. Issues in dependencies lead to issues in company infrastructure or the
product.</p>
Now more than ever: building reliable software in the age of agents</a>
#</a>
</h3>
A talk Ron Minsky (of Jane Street) gave at Bug Bash 2026, discussing how to
build reliable software in an age where AI agents exist. To quote from the
description:</p>

Ron stakes out their position that AI workflows should maximize human
effectiveness and understanding rather than replacing humans entirely. At
Jane Street, many traditional (aka pre-Claude) software engineering practices
have become more important rather than less. Type systems help provide fast
feedback and enforce invariants that agents can understand. Expect tests
allow developers to see system behavior and create deterministic simulations
at the library level. Code review remains crucial for maintaining code
quality and human understanding, even though agents change the dynamics.
Finally, he touches on Jane Street’s growing interest in formal verification,
and the impact of agents making previously expensive approaches, like formal
methods, more practical.</p>
</blockquote>


OpenVet 0.5.0 Release
2026-05-18T00:00:00+00:00
OpenVet 0.5.0 is out.</strong> Highlights: an audit linter (openvet audit check</code>),
an ad-hoc query command (openvet query</code>), the implies</code> operator in
requirements, and a deliberate wire-format reshape.  Most of what landed is
motivated by me doing some dogfooding. I created audits for the crates that the
openvet project itself uses. The openvet repository has about 500 dependencies,
and I audited 111 of them. On the way I learned a lot, and most of what’s in
this post is what those lessons turned into.</p>
Ideally, when you implement OpenVet in a real-world project, you don’t have to
audit everything from scratch – you can trust audits that others have produced.
But I am the first real “user” of OpenVet, so I do have to audit everything from
scratch. And I need a dataset of audits, to test the CLI against.</p>
I didn’t want to create all of the audits manually, especially given that the
main reason I needed them was to test stuff, and I may have to re-create them.
So, what I did was automate creating audits, by writing a “skill” that Claude
can use to audit a package. This was actually very productive, for a number of
reasons:</p>

Writing the skill forced me to write down rules about how an audit is structured.
I had some ideas in my mind about what audits should look like — but there is
nothing like drafting it, letting Claude apply it, looking at the outcome,
and seeing that it comes out different than I expected (because I had implicit
assumptions, but I did not write them down)</li>
Watching Claude use the CLI with my instructions and the help text revealed some
real shortcomings that the CLI had.</li>
Having a set of audits allowed me to test the registry: to make sure that audits
render right.</li>
It also allowed me to test the CLI, answering questions like: how fast does
check work with ~100 audits in a log? How fast is publishing? How fast does
it update and verify new commits?</li>
</ul>
Claims vocabulary
#</a>
</h2>
OpenVet uses the concept of a claims vocabulary</em>. Claims are atomic “facts” about
a software package. For example, uses-unsafe</code>. Or uses-network</code>. I had a vocabulary
file drafted up, but I hadn’t put a lot of effort into it. The first few audits
showed me that this vocabulary was not really in the shape I wanted it to be in.</p>
So, I ended up revising it, pointing Claude at the revised vocabulary, and it looked
much better. I came up with a pattern of claims that works well with the way we
write requirements. There are two kinds of claims:</p>

Discovery claims</strong>: Encode a fact about something a package is, or does. These
are claims like uses-unsafe</code> (uses memory-unsafe code), impl-crypto</code> (implements
cryptography), has-binaries</code> (has binaries/executables in the package archive),
or is-benign</code>. These are simple, can be asserted by just looking at what files
are there, what code is there. is-benign</code> is the global one — it doesn’t slot
into the has-*</code> / uses-*</code> / impl-*</code> families, but every audit asserts it like
the others.</li>
Audit claims</strong>: These are gated on the discovery claims. For example, if a
crate implements cryptography (impl-crypto</code>), then you may want to check
if the cryptography is implemented in a safe way for callers (crypto-impl-safe</code>),
whether it’s implemented correctly (crypto-impl-correct</code>), whether it is
tested (crypto-impl-tested</code>).</li>
</ul>
With this vocabulary in place, the auditing process works like this:</p>

You test and assert all discovery claims (to true or false).</li>
You then test and assert all audit claims that are gated by the discovery claims.</li>
</ul>
The new vocabulary is now in place, and the old one is removed.</p>
Referencing findings, claims
#</a>
</h2>
OpenVet has a file format for audits, that has human-readable and machine-readable
pieces. For example, it has claims (boolean “facts”, machine-readable) and it has
markdown-shaped data, for human consumption. But I wanted a way to “connect” the two.</p>
One feature that I built previously is that you can reference claims from inside the
markdown, using the !claim-name</code> syntax. The idea behind that was that you can
link claims inside the markdown, to justify why you asserted a claim the way you did.
Similarly, I had built the #1</code> syntax, to reference findings.</p>
OpenVet is set up to check these: you can only reference findings that exist. If you
wrote #34</code>, but there are only 27 findings, that is an error. Same for the claims.</p>
Testing showed that the #1</code> syntax for findings clashes with some things, including
GitHub pull-request references. In the registry, we render these as FINDING-1</code>, so
the syntax was changed to #finding-1</code>, which reduces the chance of clashes.</p>
One issue was found with the claims: sometimes, you want to choose to not evaluate
a claim (leave it unasserted). This can happen for a number of reasons: maybe it is
not possible for you to evaluate it. Maybe the scope is too large. But you still
want to explain in the prose why</em> you didn’t evaluate it. That did not work: OpenVet
would error if you referenced a claim that you did not assert.</p>
So I changed that. You can now reference claims, even if you don’t assert them.</p>
Turning a summary into a report
#</a>
</h2>
Initially, audits had a summary</em> field as a high-level summary of the audit.
Iterating on it, I ended up standardizing on a structure for it, that begins with
a high-level explanation of the package that is audited (what it does), followed
by the methodology of the audit (how was it examined, what tools were used), followed
by a results section (explaining the outcome of the audit, explaining claims and
findings), followed by a conclusion section.</p>
That worked, but it turns out there is a small problem: in the web interface,
what can we show as an actual summary? I considered extracting the conclusion
section from the summary, but a conclusion isn’t really a summary of an audit.</p>
So, I changed the audit wire format. What used to be summary</em> is now called
report</em>, and I added an actual summary field, which is enforced to be less
than 1024 bytes.</p>
Audit linter
#</a>
</h2>
Testing showed that it is easy to forget to assert a claim. Especially the
discovery claims, ideally they should all be set to something. Claude forgot
to, and so did I.  A more structured approach was needed.</p>
Since we have the claims vocabulary (and their relationships), and good
markdown parsing abilities (with pulldown-cmark</code>), I thought the best way to
handle this is to build a linter. The existing audit validation code was moved
from the openvet-proto</code> crate into a dedicated openvet-audit</code> crate. The
vocabulary was converted into a TOML document, that the linter can validate. So
OpenVet can now enforce a number of things:</p>

All of the discovery claims need to either be asserted, or they need to be
referenced in the markdown (a justification of why they could not be
evaluated).</li>
Gated on the discovery claims, the applying audit claims need to either be
asserted, or referenced.</li>
Any asserted claim needs to be referenced (explaining how it was evaluated).</li>
</ul>
Similarly, the linter also checks the report. It verifies that the markdown has
the expected headings (Subject, Methodology, Results, Conclusion).</p>
Making the linter fast and giving it readable output took real effort. I came
up with a tree-shaped output. Here’s an example:</p>
$ openvet audit check</span></span>
note: detected workspace audit-cargo-deranged-0.5.8-7cd812cc2bc1, performing workspace check</span></span>
audit.pb</span></span>
├─ ✘ claims</span></span>
│  ├─ ✘ 'uses-unsfae' is declared but never cited</span></span>
│  ├─ ✘ 'algorithm-impl-safe' is asserted but 'impl-algorithm' is false or absent</span></span>
│  ├─ ⚠ 'unsafe-documented' should be asserted because 'uses-unsafe' is true</span></span>
│  ├─ ⚠ 'unsafe-minimal' should be asserted because 'uses-unsafe' is true</span></span>
│  ├─ ⚠ 'unsafe-tested' should be asserted because 'uses-unsafe' is true</span></span>
│  └─ ⚠ 'uses-unsfae' is not in the taxonomy (typo, or a custom claim)</span></span>
├─ ⚠ summary</span></span>
│  └─ ⚠ summary is over the soft cap (577 bytes; soft cap 512)</span></span>
├─ ✘ report</span></span>
│  ├─ ⚠ unexpected section: ## Assessment (sibling-level structure should be H3+)</span></span>
│  ├─ ⚠ unexpected H1: # Some Other Heading (only `# Summary` is allowed at H1)</span></span>
│  ├─ ✘ #finding-99 (no such finding)</span></span>
│  └─ ⚠ '#1' inside backticks looks like a finding reference; remove the backticks to make it resolve</span></span>
├─ ✘ findings</span></span>
│  ├─ ✘ findings[0].description: #99 (no such finding)</span></span>
│  └─ ⚠ findings[1].description: '#1' inside backticks looks like a finding reference; remove the backticks to make it resolve</span></span>
├─ ✘ annotations</span></span>
│  └─ ✘ src/unsafe_wrapper.rs</span></span>
│     └─ ✘ lines 50-60 exceed file length (36)</span></span>
└─ ? signatures (not signed yet)</span></span>
</span>
5 errors, 9 warnings</span></span></code></pre>
The forward-reference part of this check is wired into more than just the
command line: openvet audit sign</code> won’t sign an audit with unresolved
references, and the registry’s publish endpoint refuses bundles whose
references don’t resolve. Same code, three call sites — what the CLI gates
pre-sign matches what the server enforces at publish time.</p>
Querying and requirements
#</a>
</h2>
With 111 audits in hand, a different question came up: I now have a pretty cool
dataset (all of my dependencies audited, with claims attached), but could I
build a way to query that dataset? I wanted to answer questions like:</p>

How many dependencies I have use unsafe?</li>
How many dependencies I have implement cryptography, or use cryptography?</li>
</ul>
So I built openvet query</code>. OpenVet already has a language (the requirement
language), and all I needed was a way to evaluate a requirement expression and
pretty-print the output. That part was not so hard.</p>
$ openvet query impl-crypto</span></span>
✓ cargo:sha1@0.11.0</span></span>
✓ cargo:siphasher@1.0.3</span></span>
✓ cargo:ssh-cipher@0.2.0</span></span>
✓ cargo:subtle@2.6.1</span></span>
Summary: 4 match, 182 contradicted, 372 unknown, 13 skipped</span></span></code></pre>
One pattern for requirements I used a lot looks like this:</p>
(not impl-crypto) or crypto-impl-safe</span></span></code></pre>
This translates to: either the package does not implement cryptography, or the
cryptography must be safe. In other words: if impl-crypto</code> is true, then
crypto-impl-safe</code> must also be true. Because this is a common pattern, I added
syntax for it. You can now write:</p>
impl-crypto implies crypto-impl-safe</span></span></code></pre>
This works both when querying, and when writing requirements.</p>
I then wanted a few more things:</p>

By default, it shows all crates that match the requirement. But I wanted a
way to show crates that don’t match it, or crates where the requirement
evaluates to unknown</em> (because it has no audits, or the audits it has don’t
assert one of the claims in the requirement)</li>
I also wanted a way to explain how</em> the requirement expression was evaluated.</li>
</ul>
So I added a --status [match|contradicted|unknown|all]</code>, and an --explain</code>
flag. The explain output fits into a tree-like shape, similar to the audit linter.</p>
$ openvet query impl-crypto implies crypto-impl-safe --explain</span></span>
✓ cargo:zerovec@0.11.6</span></span>
└─ from xfbs: ✓ true</span></span>
   └─ any → true</span></span>
      ├─ not → true</span></span>
      │  └─ impl-crypto → false</span></span>
      └─ crypto-impl-safe → unknown</span></span>
✓ cargo:zerovec-derive@0.11.3</span></span>
└─ from xfbs: ✓ true</span></span>
   └─ any → true</span></span>
      ├─ not → true</span></span>
      │  └─ impl-crypto → false</span></span>
      └─ crypto-impl-safe → unknown</span></span></code></pre>
openvet check</code> shows you the same for packages that fail your requirements, it
just breaks it down per-requirement.</p>
Breaking the wire format
#</a>
</h2>
By now you may have noticed that 0.5.0 breaks the wire format. Several of the
changes above — splitting summary</em> into report and summary, the #1</code> →
#finding-1</code> rename, the relaxation of which claim references must resolve —
are breaking. I could have implemented them in a way that preserves backwards
compatibility, but I chose not to. OpenVet does not have users yet, so I can
still “move fast and break things”. I figured: if I break the wire format, I
might as well break it right. So I snuck a number of simplifications and
improvements in there too.</p>
A lot of RFC 3339 timestamps were replaced with a single u64</code> UNIX timestamp.
No need to stringly-type time, saves parsing and encoding. The keys used by the
keyset tree were simplified (now are just a TaggedHash</code>’s Display output). The
Signature</code> type lost the embedded public key.</p>
Adjacent to all of that I added some authoring tooling. Annotations gained a
--remove</code> flag — previously, if you set an annotation incorrectly, you had to
recreate the audit workspace from scratch. I also added directory-level
annotations (a wire-shape change of its own); you can attach an annotation to a
whole subtree now, like a has-tests</code> note on the tests/</code> directory.</p>
The wire format isn’t perfect yet, there are still things I need to change, but
I tried to fold everything into this breaking change that I could fit.</p>
Next steps
#</a>
</h2>
There is still a lot on the to-do list for the CLI. Some of the bigger pieces:</p>

The TUI editor could lint as you go.</strong> It works, but you have to close it
and run openvet audit check</code> to see what’s wrong. Folding the linter into
the TUI so it surfaces issues as you type would close the loop.</li>
openvet audit new --diff</code> doesn’t exist yet.</strong> Diff audits record metadata
stating what previous version and audit were consulted. The metadata for this
shipped already, but the tooling for it did not.</li>
Encrypted SSH keys aren’t supported yet.</strong> Today OpenVet only signs with
unencrypted on-disk keys; encrypted-key support with a passphrase prompt
is a planned addition.</li>
Only sshsig signatures are supported.</strong> Other signature formats are on
the list but unimplemented. Using SSH keys and signatures is convenient:
almost every developer has one, and they support hardware-backed tokens
(ed25519-sk</code>). But long-term, I want to support different kinds of keys.
I am especially keen to try a WebAuthn-backed flow. The breaking changes
in the wire format support that, but I haven’t built it yet.</li>
There is no mirroring story yet.</strong> Self-hosting a log on static storage
works, but tooling for “mirror an existing registry-hosted log to your
own server” hasn’t been built.</li>
</ul>
I’ll keep posting here as these land.</p>
Find it / report it
#</a>
</h2>

Install:</strong> cargo install openvet</code></li>
Source:</strong> gitlab.com/openvet-org/openvet</a></li>
Docs:</strong> docs.openvet.org</a></li>
Issues:</strong> the GitLab tracker on the CLI repo. Issues and MRs are very
much welcome — this is a one-person project and any extra eyes help.</li>
</ul>
If you’d rather reach me directly, my GitHub profile has the contact info.</p>


OpenVet Registry: first preview deployment
2026-05-18T00:00:00+00:00
The OpenVet Registry is now live at openvet.org</a></strong> as
a preview deployment. The registry is a public, collaborative
host for cryptographically signed software dependency audits:
a place for auditors to publish their work and for projects to
subscribe to the auditors they trust.</p>
OpenVet is a tool that tries to make it possible, affordable
and scalable for projects to adopt audited-dependencies
workflows. The status quo today is that most projects use
dependencies without reviewing what they do. As a collective,
we place implicit trust in packages published in registries.
Large corporations can afford teams dedicated to reviewing
dependencies, but most projects cannot. The OpenVet
command-line tool tries to make it easy to audit packages, and
to consume those audits. The registry tries to make it easy to
publish those, and discover logs. If you want to know more, the
docs have a longer answer</a>.</p>



  WARNING</div>
  

This is a preview deployment.</strong> The registry is operational
and I’m dogfooding it daily, but the data structures behind it
aren’t yet frozen. Expect that I’ll occasionally change
something and reset the registry in the process. Don’t host
audits here that you can’t afford to lose until I drop the
preview</em> label.</p>


  </div>
</div>
What you can do with it today
#</a>
</h2>
I run openvet</code> against the OpenVet repository as a continuous
dogfooding exercise. The output below is real, from a check in
mid-May 2026 — the numbers are what they are.</p>
Setup
#</a>
</h3>
openvet init</code> drops a starter openvet.toml</code>. Mine, after a
few edits, looks like this:</p>
[</span>log</span>.</span>xfbs</span>]</span></span>
url</span> =</span> "</span>https://openvet.org/xfbs</span>"</span></span>
</span>
[[</span>lockfile</span>]]</span></span>
kind</span> =</span> "</span>cargo</span>"</span></span>
path</span> =</span> "</span>Cargo.lock</span>"</span></span>
</span>
[</span>requirement</span>]</span></span>
benign</span> =</span> "</span>is-benign</span>"</span></span>
crypto</span> =</span> "</span>uses-crypto implies crypto-safe and crypto-tested</span>"</span></span>
unsafe</span> =</span> "</span>uses-unsafe implies unsafe-safe and unsafe-tested</span>"</span></span></code></pre>
I trust one log (my own, at openvet.org/xfbs</code>), I want to gate
the Cargo.lock</code>, and I declare three requirements: every
dependency must be benign, must be safe-and-tested if it uses
cryptography, and must be safe-and-tested if it uses unsafe
code. The requirement syntax is boolean over claim names — see
claims vocabulary</a> and requirement syntax</a>
in the docs for the full set.</p>
Pin and verify the logs you trust
#</a>
</h3>
openvet update</code> fetches each audit log you’ve subscribed to in
openvet.toml</code>, verifies its signature chain end-to-end, and
writes the new head into openvet.lock</code>:</p>
$ openvet update</span></span>
xfbs: verified 50 new commit(s) (0 keyset / 0 gen-root); head 117574148ceb -> cb6e938a4ced</span></span>
wrote openvet.lock</span></span></code></pre>
The signature verification is local — the registry’s only job
here was to serve bytes. The pinned head in openvet.lock</code> is
what guarantees the same verdict on every machine running
openvet check</code> later.</p>
Gate your project against the audits
#</a>
</h3>
openvet check</code> walks your lockfiles, evaluates each requirement
against the audits in the logs you’ve pinned, and exits non-zero
on anything that doesn’t satisfy your policy:</p>
$ openvet check</span></span>
✘ cargo:matchers@0.2.0</span></span>
└─ unsafe: ✘ contradicted</span></span>
   └─ from xfbs: ✘ false</span></span>
      └─ any → false</span></span>
         ├─ not → false</span></span>
         │  └─ uses-unsafe → true</span></span>
         └─ all → false</span></span>
            ├─ unsafe-safe → true</span></span>
            └─ unsafe-tested → false</span></span>
Summary: 53 passed, 505 failed, 13 skipped</span></span>
</span>
(output trimmed)</span></span></code></pre>
When a requirement fails, check</code> prints the resolution tree:
which auditor’s statement contradicted it, which claim atoms
combined under three-valued logic, and which atom resolved to
which value. The full mechanics live in
How it works</a>.</p>
The 505 failed</code> is honest — most crates in OpenVet’s own
dependency tree don’t have audits in my log yet. That’s the
work; closing the gap is the next stretch of dogfooding.</p>
Ask concrete questions about your dependency tree
#</a>
</h3>
openvet query <expression></code> walks your lockfiles and reports
the state of a requirement expression across them. It uses the
same parser and evaluator as [requirement]</code> in openvet.toml</code>
— anything you can write as a requirement, you can pass to
query</code>. The simplest case is a single claim atom: which of my
crates use unsafe code, according to my pinned audits?</p>
$ openvet query uses-unsafe</span></span>
warn  openvet@0.4.0 (path / workspace dep)</span></span>
warn  openvet-audit@0.4.0 (path / workspace dep)</span></span>
…</span></span>
✓ cargo:bitflags@2.11.1</span></span>
✓ cargo:log@0.4.29</span></span>
✓ cargo:matchers@0.2.0</span></span>
✓ cargo:once_cell@1.21.4</span></span>
✓ cargo:tempfile@3.27.0</span></span>
✓ cargo:tracing@0.1.44</span></span>
✓ cargo:unsafe-libyaml@0.2.11</span></span>
✓ cargo:zeroize@1.8.2</span></span>
…</span></span>
Summary: 30 match, 35 contradicted, 493 unknown, 13 skipped</span></span>
</span>
(output trimmed)</span></span></code></pre>
match</code> is the count of dependencies the expression resolves to
true for. contradicted</code> are dependencies where audits disagree
under three-valued logic. unknown</code> is the long tail where no
pinned audit provides enough information to resolve the
expression. Compound expressions work the same way — openvet query "uses-unsafe and impl-crypto"</code> would count only
dependencies where both atoms resolve to true. The summary line
on its own tells you the coverage of a given property across
your tree.</p>
What’s in this deployment
#</a>
</h2>
The registry implements the OpenVet protocol</a>. It’s not
a central trust anchor — the command-line tool will work with
anything that speaks the protocol. You can host your own log on
anything that can serve data over HTTP/HTTPS, and get the same
functionality. The public deployment exists to make
participation low-friction. Signup is two clicks if you have a
GitHub account. It defaults to custodial keys, so you don’t
have to manage your own keys (unless you want to, which is
perfectly fine, and encouraged), all to make the process of
adopting it as easy as possible. The registry is free, and it
will always be. It’s not a SaaS, it’s just a (public) service.</p>
What’s working today:</p>

Account signup and custodial keys.</strong> New accounts get a
registry-held signing key by default. Custodial keys are
published in your keyset like any other, so consumers can verify
audits you sign with them.</li>
Publishing audits from the CLI.</strong> Author audits locally,
sign with a self-held key, and push to your registry-hosted
log. End-to-end without going through the UI.</li>
Package search.</strong> The registry actively synchronizes
package registry contents, so you can search for packages on
openvet.org, and find matching audits. Currently, only
synchronization with crates.io is enabled on the hosted
registry, but more will be enabled soon.</li>
Audit log hosting for any ecosystem.</strong> Audits can be hosted
here regardless of which ecosystem the audited package comes
from.</li>
Raw log endpoints for subscribers.</strong> The CLI subscribes
directly to a log’s HTTP endpoint and verifies the signature
chain locally; the registry’s job is to serve bytes.</li>
</ul>
What’s still rough
#</a>
</h2>
In the spirit of “should I use this yet?”, a candid list:</p>

Data structures may still change.</strong> Some breaks will be
migrations; some will be hard resets of the registry’s data.
Until I drop the preview</em> label, anything you publish here
should be considered ephemeral.</li>
The web UI is pre-pre-beta.</strong> The basic flows (login,
searching packages, viewing audits) work. Some things may look
strange, or be subtly broken.</li>
Self-custodial setup doesn’t fully work yet.</strong> You can add
your own key to your log’s keyset, but there is currently no
way to remove the custodial key and give your own key
operator privileges.</li>
Search beyond cargo is dark.</strong> RubyGems and PyPI syncers are
implemented but not yet enabled in production. npm and Go are
next. The work is queue-and-storage, not a code rewrite.</li>
No mirroring story yet.</strong> Self-hosting a log on static
storage works, but tooling for “mirror this registry-hosted
log to your own server” isn’t shipped.</li>
</ul>
Try it
#</a>
</h2>
Browsing the registry is open, no account required. Visit
openvet.org</a> and search for a crate (try serde</code>) to
see what audits exist for it, or open my profile</a> to see
what one auditor has published.</p>
To participate, sign in with GitHub (two clicks). The registry
mints you a log slug and a custodial signing key. From there:</p>

Click Trust</em> on any profile</strong> to follow that auditor — their
audits flow into your feed.</li>
Under Settings → Keys</em>, add your own key.</strong> The UI gives
you a one-line openvet login</code> command to run in your terminal,
which pairs the CLI with your log. You can create, sign and
publish audits from the CLI, and they will show up in the
registry.</li>
</ul>
To gate your own project against the audits, the CLI
section</a> above walks the loop: install the CLI,
declare a log to trust, run openvet update</code> and openvet check</code>.
The Quickstart</a> in the docs is the end-to-end
version.</p>
What’s next
#</a>
</h2>
OpenVet is still under development. I am working on the
specification, the command-line interface, and the backend in
parallel. As new bits get released, I will make announcements
on this blog, explaining what works, what doesn’t, what is
stable, and what isn’t.</p>
One of the outstanding pieces that will be released in the
upcoming days is an initial version of the OpenVet
specification, which still needs some cleaning up. The registry
is the piece that is the most behind: audits already render
fine, but there is no web-based auditing flow implemented yet.
There are a lot of rough edges and unimplemented pieces. The
command-line tool is in better shape, but is still missing some
important features, such as signing with encrypted keys, or
supporting signatures with anything besides sshsig.</p>
Find it / report it
#</a>
</h2>

Registry source:</strong> gitlab.com/openvet-org/registry</a></li>
CLI source:</strong> gitlab.com/openvet-org/openvet</a></li>
Docs:</strong> docs.openvet.org</a></li>
Issues:</strong> the GitLab tracker on whichever repo is closest to
the problem. Issues and MRs are very much welcome — this is a
one-person project and any extra eyes help.</li>
</ul>
If you’d rather reach me directly, my GitHub profile has the
contact info.</p>


Hello, OpenVet
2026-05-17T00:00:00+00:00
This is the start of the OpenVet dev log.  I plan to write about what I am
working on, what I managed to break, and from time to time post about
supply-chain security related news.</p>
What OpenVet is
#</a>
</h2>
OpenVet is a project that gives you supply-chain security by requiring that
your dependencies are audited, and match requirements you set out. It has
two parts:</p>


A public registry</a> that hosts signed, machine-readable audits
of software dependencies. It lets you publish audits to your own
cryptographically-signed, append-only log. And it lets others see and consume
the audits you produce. It is hosted at https://openvet.org</a>.</p>
</li>

A command-line tool</a> that can ingest those audit logs, enforce
that your dependencies are audited, and match the requirements you have. It
doesn’t trust the registry, it trusts the key of the publisher of the log.
The tooling is also not tied to the registry: you could just as well host
your own logs on any static site host.</p>
</li>
</ul>
Both of these components are open-source. The command-line tool is MIT</code> and
Apache-2.0</code> licensed, giving you freedom to adapt and integrate it. The
registry is AGPL-3.0</code> licensed, more restrictive in what you can do with the
code, requiring modifications to be released under the same license.</p>
Why
#</a>
</h2>
As software engineers, we don’t build everything from scratch. We build on top
of what others before us have built, which means depending on software packages
hosted on public registries — and that is a net positive.</p>
When the internet was initially built, there was a culture of trust: there was
no encryption, little authentication. That was possible because it had few
users and a lack of valuable targets. We have a similar culture of implicit
trust</em> on anything published in public registries. But slowly, attackers have
found out that developers’ machines are high value targets, containing API keys,
cryptocurrency wallets, and access to company infrastructure. Times are
changing.</p>
Supply-chain attacks have moved from hypothetical to routine, accelerated in
recent years by the availability of LLMs. Some attacks like the Shai-Hulud</em>
worm or the xz-utils have become well-known, but a major supply-chain security
company has logged over 1.2 million malicious packages in total, with 454,600
added in 2025 alone</a>.</p>
The current defenses either don’t work, or don’t scale. Build and release
provenance doesn’t help when attackers hijack CI workflows that release
packages (they just prove where the release happened, not what’s in the package).
CVE scanners are reactionary: by the time the CVE lands, your API keys and
wallets have been exfiltrated, and attackers have already had access to your
infrastructure. Dependency freezes just shift the pain to whoever updates first,
and if we all implemented them, they just delay when attacks are discovered.</p>
But malicious packages are not the only thing that OpenVet addresses: it is
also correctness. We are producing code at an ever-growing rate, with
ever-growing complexity. In my opinion, the only way to do this sustainably is
to have reviewed and well-tested primitives hosted at registries that can be
composed to build complex software.</p>
One personal data point: my average pet project pulls in 400 dependencies
summing up to 3.5 million lines of code, as verified by cargo vendor</code> and
tokei</code>. You may want to check your projects, and think about: how many lines
of that have I actually reviewed? How do I know that my dependencies are
correct and safe to use?</p>
The way out is to drop implicit trust and require external vetting (auditing)
of software dependencies. And when I say auditing</em>, I don’t mean the multi-month
project that is auditing a cryptographic library. For most dependencies, there
are some simple questions you need to answer, like:</p>

Does this have any build-time or install-time actions, and do these actions look safe?</li>
Does this code make network requests, and if so, why and what is sent?</li>
Does it read or write to the filesystem, and if so, what is read or written?</li>
Does it read any environment variables, and if so, what does it do with them?</li>
Does it have extensive test coverage, including randomized tests (fuzz tests, proptests)?</li>
</ul>
Any software engineer with some experience can answer that with a checklist.
Thorough audits may be required for some</em> dependencies, but not for all.</p>
The actually hard problems are elsewhere:</p>

The time it takes to perform audits of all of your dependencies</li>
The user experience for creating, publishing and discovering audits</li>
The distribution of audits</li>
The tooling for validating that your dependencies are audited</li>
</ul>
OpenVet is an approach to solving these four problems in a way that might
be able to scale beyond niche</em>.</p>
How it works, briefly
#</a>
</h2>
OpenVet defines a data format for audits. They contain both machine-readable
claims (similar to what cargo-vet</a> does, in the future I will make a post
explaining the mental model of them), and human-readable findings, source
annotations, and a report. Audits are signed by the author, the signature is
required and verified.</p>
OpenVet defines a way to distribute them. Audits are published in
cryptographically-signed append-only logs, so you do not need to trust the
platform, only the person holding the keys.  OpenVet has a registry for audits,
think about it like a GitHub</em>, but it holds audits, not code.</p>
It does not scale for us to audit every single dependency ourselves. The core
idea of OpenVet is that auditing is a collaborative process, just like
open-source development is. You publish your audits, others can trust you (and
with that, your audit-log). You can choose to trust an entity (a large company,
which has audited several dependencies, or a friend). With that, you only need
to audit dependencies that others you trust haven’t already audited, which is a
lot more manageable. It makes OpenVet’s adoption much cheaper, and thereby
scalable.</p>
When you do need to audit software, OpenVet tries to make it easy. It has a
command-line driven workflow for auditing software that lets you create an
audit workspace. I try to build tooling that makes the process as simple as
possible. And this tooling also allows you to automate the auditing process for
low-risk dependencies, by getting an LLM to do it. I am not saying that
LLM-generated audits are the perfect solution, but in my opinion: LLM-audited
dependencies are better than unaudited dependencies, and it means you can spend
your time on higher-risk dependencies.</p>
Finally, OpenVet attempts to ship tooling that makes enforcing dependency
audits as painless as possible. The command-line tooling can scan all of your
lockfiles, and search through all of the audit-logs you trust for relevant
audits in parallel and with local caching. The audit log data structure is
designed for cacheability and efficient lookup.</p>
What to expect here
#</a>
</h2>
Don’t expect a refined product here, or a sales team. It’s just me, and this is
not a commercial endeavour. I am building this because I want it to exist, and
because it is fun to do so. I am implementing features, and breaking things
along the way, as I figure out what works and what does not.</p>
If you think this idea has merit, feel free to stay along for the ride. I try
to post updates on this blog as I am working on OpenVet, as I implement new
features. I would ask you to like, comment, and subscribe, but I don’t have
any social media buttons on here, nor do I have a mailing list, nor a comment
feature.</p>
If you want to get in touch or help with this, you probably find a way to reach
me on my GitHub profile.</p>
In the meantime, if you want the source, it’s on
GitLab</a>.</p>

OpenVet Blog

Reactive vs proactive supply-chain security

OpenVet 0.6.0 Release

Find it / report it #</a> </h2> Install:</strong> cargo install openvet</code></li>

Licensing of audits hosted on the OpenVet Registry

Supply-Chain Update #1

OpenVet 0.5.0 Release

Find it / report it #</a> </h2> Install:</strong> cargo install openvet</code></li>

OpenVet Registry: first preview deployment

Hello, OpenVet