The Anti-CVE Manifesto
This is a document about the Common Vulnerabilities and Exposures system, and about the engineering time teams spend responding to it. The vulnerabilities are real. The question is how much triage work comes from carrying code maintained outside the team, and whether that work reduces risk proportionally.
1. The Problem
A CVE is published. Your security scanning tool flags it, a ticket is created, and an engineer is assigned. The engineer reads the advisory and determines whether your application is affected. Deciding that means understanding the vulnerable code path, the conditions that trigger it, and whether your application ever goes near it.
In many cases the answer is "this does not affect us." The vulnerable code path may be in a feature the application does not use, require an input it never accepts, or affect a platform it does not deploy to. Reaching that answer still requires an engineer to investigate and document it.
In the minority of cases where the vulnerability does affect you, the fix is to update the dependency. Updating the dependency pulls in new versions of its transitive dependencies, and those have to be tested too. If the update introduces a breaking change — and at sufficient depth in the dependency tree, breaking changes are frequent — your code must be modified to accommodate the new version. The fix for one vulnerability becomes a small project.
The National Vulnerability Database published over 28,000 CVEs in 2023 and over 33,000 in 2024. A dependency tree can intersect with a large catalog of advisories. Each match may generate a ticket, an investigation, and an action item before the team knows whether it is actually vulnerable.
This is the CVE treadmill. You run it every week, and you never get off.
2. Why the Treadmill Exists
The treadmill exists because modern software is assembled from components written by strangers, and the vulnerability disclosure system treats every component equally regardless of how it is used.
Transitive exposure. An application may depend on hundreds or thousands of packages while selecting only a small fraction directly. The rest arrive transitively, which is the dependency model the Anti-Dependency Manifesto examines. When a CVE is published against one of those packages, the application is potentially affected. The word "potentially" does a lot of work in that sentence.
Scanner noise. Basic vulnerability scanners compare a dependency list against advisory databases. More capable tools add reachability and context, but a match still often begins as a possibility rather than a demonstrated exploit path. The team must decide what matters and document why.
Compliance requirements. Frameworks such as SOC 2, ISO 27001, FedRAMP, HIPAA, and PCI DSS can require documented vulnerability-management processes; exact obligations depend on scope and implementation. A larger software inventory creates more findings to assess, remediate, or accept with a documented justification.
3. What the Treadmill Costs
Engineering time. Vulnerability triage, dependency updates, and the testing required to validate those updates consume real engineering capacity. Some of that is essential security work; some is inventory bookkeeping created by code the team did not select directly and cannot fully audit.
False urgency. Every CVE that enters your ticketing system competes for attention with product work. Critical and high-severity CVEs trigger incident response processes. Engineers are pulled from feature work to investigate a vulnerability that, after several hours, turns out to be in a code path their application never exercises. The opportunity cost is invisible but real: features delayed, deadlines missed, morale eroded by the feeling that the team spends its time reacting to other people's mistakes instead of building its own product.
Update risk. The remediation for a CVE is often a dependency update. Updates can introduce bugs, breaking changes, or additional advisories. Teams have to balance prompt patching against the validation needed to ship the update safely.
Evidence versus risk. A team that investigates and documents that a set of CVEs does not affect its application has improved its audit evidence. Whether it improved security depends on the quality of the investigation and what the team does with the result.
4. What Zero Looks Like
Our CVE count from upstream dependencies is zero. It has been zero since we began. It will remain zero.
This is not because our code is perfect. It is because we have no upstream dependencies. There is no dependency tree to scan. There is no lock file to compare against the National Vulnerability Database. There are no transitive packages maintained by strangers whose security practices we must evaluate and whose release schedules we must track.
When a vulnerability is discovered in our code, the process is:
- We are notified.
- We fix the code.
- We release the fix.
- You update one package.
We still investigate the vulnerable path, affected products, severity, and remediation. The difference is that the investigation stays within code and releases we own. There is no transitive dependency cascade or outside release schedule to evaluate. We fix the affected code and ship the update.
The compliance story is equally simple. Your bill of materials has four entries. Your vulnerability management process covers four entries. Your auditor reviews four entries. The documentation for a complete vulnerability assessment fits in a single meeting.
5. When It's Our Turn
Read the claim carefully: zero is our count from upstream dependencies. It is not a claim that our code is free of vulnerabilities. It isn't — no code is — and some of ours will eventually be found, disclosed, and assigned CVEs of their own. We want that. This document is not an argument against vulnerability disclosure; when a researcher finds a flaw in our library, we will fix it, credit them, and request the CVE ourselves. Reports go to security@thevun.com.
Here is what will be different about those CVEs. Every one will be in code we wrote and can read end to end, so triage never begins with "does this affect us?" — it does, and we know where. Every one will be fixed by the team that wrote the flaw, not by waiting for a stranger's weekend. And none will arrive as a passenger in somebody else's update. Zero-from-upstream was never a promise of perfection. It is a promise about scope: every vulnerability we ask you to care about is ours, is real, and comes with the fix attached.
6. Objections We Have Heard
"You still have to deal with your own vulnerabilities."
Yes. We deal with our own vulnerabilities. We do not also deal with the vulnerabilities of 1,200 strangers. This is a meaningful reduction in scope.
"The CVE system exists for a reason."
The CVE system coordinates vulnerability disclosure across the software ecosystem. We will use it for the same purpose: one team telling its users which products are affected and which release contains the fix. Owning the application code reduces coordination boundaries; it does not make disclosure unnecessary.
"Your code could have the same vulnerabilities as the libraries you replaced."
It could. The difference is scope and ownership. If our TLS implementation has a vulnerability, responsibility for diagnosis, remediation, testing, and release stays with us. That can shorten coordination, but it also makes the outcome entirely our responsibility.
"Automated scanning is getting better."
Automated scanning is getting better at identifying which CVEs are reachable in a codebase. That improves prioritization. Reducing the number of outside components reduces how often the question has to be asked in the first place.
7. What This Means
The CVE treadmill is not a law of nature. It follows from architectural and procurement decisions. If software contains a large graph of third-party components, the team inherits those components’ advisories and spends engineering time deciding which ones matter.
If you build software from components you own, your risk profile is your own. Your vulnerability surface is bounded. Your remediation timeline is under your control. Your compliance documentation is short.
Supply chain attacks only work if there's a supply chain.