Blog
depproof blog
Honest writing on application security risk in the code you didn’t write: vulnerabilities, exploitation, licenses and maintenance, plus our own research. Start with the AppSec risk guide for the whole map.
Subscribe via RSS — no email, no account.
AppSec risk, explained
Evergreen reference on the risk that sits in your dependencies.
End-of-life dependencies: the risk with no CVE
A finding says “is there a known problem?” — end-of-life says “if a problem appears, will anyone fix it?”. Every vulnerability Apache lists for Log4j 1.x was published at least four years after the project was declared dead. Why no feed carries maintenance status, the three places to look, and what the Cyber Resilience Act already asks for.
Read the article →Software composition analysis: the part that never finishes
An SCA finding has two inputs and only one of them is yours: your dependency set changes in a pull request, while what the world knows about it changes daily. Why the count moves on code nobody touched, the four moments worth scanning — including the one every team skips — and the five quiet ways a healthy practice falls behind.
Read the article →Severity is a bad prioritiser — KEV and EPSS as a CI gate
A “fail on high” gate stops builds on roughly the top 48% of everything published — and still lets through 11% of the CISA KEV catalogue, every entry of which is confirmed exploited. What CVSS, EPSS and KEV each actually measure, why CVSS severity is not one of the four variables in CISA’s BOD 26-04, and a gate built from all three.
Read the article →OSV vs CVE: the difference, and why it matters
Not two competing databases — two different layers. CVE names a vulnerability; OSV says which package versions it affects. Why CPE can’t describe a Maven coordinate, the advisories that never get a CVE at all, and what that means for what your scanner can find.
Read the article →Zero findings is not zero risk
A clean dependency scan has two possible meanings — nothing is wrong, or nothing was read — and they look identical in the report. Why “0 errors” reads best when coverage is worst, the four input problems that produce a confidently empty result, and the four signatures that tell them apart.
Read the article →VEX and vulnerability waivers explained
What VEX (Vulnerability Exploitability eXchange) is, the four status values, and why “not affected” must cite one of five fixed justifications. Plus waivers — risk acceptance with a justification, an owner and an expiry — and how the two relate.
Read the article →Why npm & pnpm audit miss vulnerabilities
A clean npm/pnpm audit isn’t proof your dependencies are safe. How the audit commands actually work, the four structural reasons they miss vulnerabilities or return nothing, and what more complete lockfile-based scanning looks like.
Read the article →Is AGPL safe for commercial and SaaS use?
Yes — the AGPL-3.0 is safe to use commercially; the risk is narrower than "AGPL is banned." What Section 13’s network clause actually triggers, when a SaaS product is affected and when it isn’t, and how to catch AGPL in your transitive tree before due diligence does.
Read the article →Dependency governance: when per-repo scans stop being enough
The day you land a regulated customer, start a SOC 2, or a CRA obligation lands, per-repo scans stop being enough. Governance is the org-wide aggregate — and an honest, self-hosted way to get there without a six-figure platform.
Read the article →Research
What we measured across real codebases, with the method and the limits.
Do popular packages ship what is in their source?
Reviewers read git; users install from the registry. Comparing the 1,000 most-downloaded npm and PyPI releases with their tagged source, 98% of those that could be checked declare nothing at install that their source does not. One release in eight cannot be checked at all: no repository link, or no tag for the version people install.
Read the article →What your SBOM cannot say
An SBOM that leaves component scope empty tells your platform that everything ships, test tooling included, by CycloneDX’s own default. Most generators we tested write no scope at all; Dependency-Track keeps it when it is there. A five-minute check for your own SBOM, and what goes against us.
Read the article →Nobody left to fix it
Every scanner tells you a dependency is vulnerable; none tell you whether anyone is still around to publish the fix. About one component in seven carries a signal that nobody is maintaining it — and the rate is the same whether it ships or only runs in your tests. Measured across 24 repositories, with four signals in five inferred rather than declared, and a retraction of our own earlier headline.
Read the article →Findings that never ship
Two in five of the vulnerabilities a scanner reports sit on test harnesses and build plugins that never reach production — including more than a third of criticals — and they trigger the same escalation anyway. Measured across 24 repositories in five ecosystems, why the share swings from 58% to nothing depending on your language, and why we rank on scope rather than filter by it.
Read the article →Releases
Product announcements. The changelog has every release.
The depproof hub: org-wide governance, waivers & audit trail
The self-hosted hub aggregates every repo’s scans into one cross-repo view — blast-radius search and org-wide license posture — and adds cybersec-owned waivers with an append-only audit trail and OpenVEX export.
Read the article →The depproof scanner: self-hosted dependency & license audit for GitHub and GitLab
Meet the scanner: zero-config in GitHub Actions and GitLab CI, it audits Java, JavaScript, and Python dependencies for vulnerabilities and license risk — full transitive tree, CycloneDX SBOM, and a pass/fail CI gate, self-hosted.
Read the article →