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 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:

• Repo + dataset: https://github.com/munimtechnologies/advisory-import-census

The gap, plainly

GitHub has two kinds of security advisory:

1. Repository security advisories (GRAs) — the advisory a maintainer writes and publishes on their own repo's Security tab.
2. The global GitHub Advisory Database — the reviewed, curated set that Dependabot, npm audit, pip-audit and OSV.dev actually read.

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.

What the census found (snapshot 2026-10-14)

• 30 self-hosted AI/ML repos surveyed; 19 had at least one published advisory; 618 advisories total.
• 195 / 618 (31.6%) are not present in the global database under their own GHSA ID.
  • 90 have no global presence at all.
  • 18 carry a CVE but only a thin record under a different ID.
  • 87 have no CVE at all.
• Median time missing: 91.1 days. Max: 999.7 days.
• By contrast, when GitHub does import a reviewed GRA, the median time to do so is 3.2 days — so the missing ones aren't just sitting in a short queue.
• Seven projects are 100% missing: dify (21/21), LibreChat (29/29), anything-llm (25/25), text-generation-webui (12/12), ragflow (8/8), ComfyUI (4/4), feast (1/1).
• Some projects, by contrast, had zero missing advisories (e.g. ray, langchain, haystack) — so this is uneven, not universal.

Why this is new

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.

How it's measured (reproducible)

All inputs are public, read-only metadata — no scanning, probing or logging in to anything:

1. List each repo's published advisories via the REST API.
2. Build the complete set of GHSA IDs in github/advisory-database with a blobless, no-checkout clone (small and fast).
3. An advisory counts as imported only if its own GHSA ID appears in that set.
4. For an advisory that is missing but carries a CVE, the GitHub advisories API is queried by CVE to tell "no global presence at all" from "only a thin record under a different ID."

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.

Honest limits

• One snapshot, 30 repos — a sample, not the whole ecosystem.
• "Missing" means "not present under its own GHSA ID at snapshot time", not "wrongly withheld". Curation lag can be legitimate, and an advisory may be re-imported later under a different ID (the CVE column bounds that case).
• No vendor-blaming is intended; the point is the measurable visibility gap, not anyone's motive.

If you maintain one of these projects

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.