31.6% of security advisories for self-hosted AI tools never reach the database your scanner reads
If you run a self-hosted AI tool — Open WebUI, Flowise, dify, LibreChat, vLLM, LangFlow — your dependency scanner may be silent about real, maintainer-published vulnerabilities in it. Not because the advisory doesn't exist, but because it never made it into the one database your scanner reads. I me

If you run a self-hosted AI tool — Open WebUI, Flowise, dify, LibreChat, vLLM, LangFlow — your dependency scanner may be silent about real, maintainer-published vulnerabilities in it. Not because the advisory doesn't exist, but because it never made it into the one database your scanner reads.
I measured how often this happens. Across 30 widely used self-hosted AI/ML projects, 195 of 618 published security advisories (31.6%) are not in the global GitHub Advisory Database under their own ID. The data, script and method are open:
GitHub has two kinds of security advisory:
A GRA only protects downstream users once it is imported into the global database under its own GHSA ID. Until then, the advisory is published and public — but invisible to automated scanning. There is no alert, no PR, no npm audit finding.
The one prior published study of GitHub's advisory-review pipeline (arXiv 2602.06009) gathers repository advisories only through the global database's repository_advisory_url field. By construction, a GRA that was never imported cannot appear in it — so the never-imported set is invisible to that study. As far as I can find, no prior work has counted this gap, and none for the self-hosted AI/ML ecosystem specifically.
All inputs are public, read-only metadata — no scanning, probing or logging in to anything:
The script and the 618-row dataset (CC BY 4.0) are in the repo; the code is Apache-2.0.
Because OSV.dev ingests GitHub-reviewed advisories from exactly this global database, an advisory absent there under its own GHSA ID is also absent from OSV under that ID — so OSV-based scanners ( pip-audit, osv-scanner, Dependabot's OSV path) are blind to it too. I'm now running a direct, per-advisory OSV.dev sweep to measure that independently (including how many of the CVE-bearing missing ones OSV happens to know from another ecosystem source); those numbers will land in a v0.2 update.
Publishing a repository security advisory is a great first step — but if you also want Dependabot and npm audit to flag it for your users, make sure it gets requested for global publishing / CVE assignment so it lands in the global database under its own GHSA ID.
Posted by MV2 of Munim, Inc. This research, the code and this write-up were made with AI agents working in his name; every number was checked against the linked public pages. Corrections are welcome — open an issue on the repo.