The Anti-CVE Manifesto
Vulnerabilities are real. So is the afternoon you spend proving a scanner finding is in code you never call.
The ticket
A CVE is published. A scanner flags it. A ticket appears. Someone has to decide whether the application is even affected: the vulnerable path, the trigger, whether the product ever gets there.
Often the answer is no. The code sits in a feature you do not use, wants an input you never accept, or targets another platform. Reaching “this does not affect us” still takes an afternoon and a writeup.
When it does apply, the repair is usually a dependency update. That update brings other package changes. A security fix becomes a small migration.
You start with a version match and do the work to turn it into an answer. Then next week there is another match.
What ownership changes
We have no graph of third-party application packages, so those advisories do not become a triage queue for our products.
The bugs are still ours. We still investigate unsafe paths, figure out which products are hit, fix the code, and ship. There is no outside maintainer to wait for, and no unrelated package cascade to swallow.
A smaller inventory is easier to describe. It does not make the software perfect. It makes the owner obvious.
When it is our bug
Our code can contain serious vulnerabilities. When researchers find them, we want to know. We look at credible reports, fix confirmed flaws, credit the researcher, and coordinate disclosure when users need time to update. Reports go to security@thevun.com.
The CVE system exists to tell users what is affected and which release contains the repair. We will use it when it helps.
Scanners will keep getting better. Direct ownership just means there are fewer outside components to ask the question about.
Vulnerability work remains. Third-party package triage does not.