Global feed or filter for published repository-level security advisories (ecosystem-less)

[jgamblin]

Problem

Repository security advisories that do not map to a supported package ecosystem (desktop applications, firmware, tooling) are published, publicly readable, and carry GitHub-CNA-assigned CVE IDs, but they are invisible to every aggregate discovery surface GitHub offers:

• The global advisories API (GET /advisories) does not return them, and no type or ecosystem filter changes that (the reviewed database only accepts the supported package ecosystems)
• GraphQL securityAdvisory(ghsaId:) returns NOT_FOUND for them
• They never enter github/advisory-database, so OSV.dev, deps.dev, and every downstream consumer inherit the same blind spot
• The repository_advisory webhook only fires for repositories, orgs, or app installations you control

The only discovery mechanism that works is polling GET /repos/{owner}/{repo}/security-advisories for every repository you care about. We currently poll a 10,000-repository watchlist every 3 hours with ETag conditional requests. It works, and conditional requests keep it cheap, but mass-polling public data is the wrong architecture for both sides.

Concrete example: Notepad++

Notepad++ is one of the most widely deployed desktop applications on GitHub and publishes no package to a supported ecosystem, so its advisories are exactly this class. Verified today (2026-06-06):

Advisory	CVE	Visible in GET /repos/notepad-plus-plus/notepad-plus-plus/security-advisories	Visible in global GET /advisories	GraphQL
GHSA-r39g-3mcw-xcg2	CVE-2026-48770	yes	no (0 results by cve_id, 404 by GHSA id)	NOT_FOUND
GHSA-3x3f-3j39-pj3v	CVE-2026-48800	yes	no	NOT_FOUND
GHSA-p58x-r3c9-x9p6	none assigned yet	yes	no	NOT_FOUND
GHSA-qm4c-qg8p-qfcr	none assigned yet	yes	no	NOT_FOUND

The last two rows are the sharpest version of the problem: published security advisories for a major desktop application, sitting in the window before CVE assignment/publication, with zero signal available from any feed, search surface, or event stream. During that window (typically days to weeks) the repository advisory itself is the only public record in existence. Anyone not already polling that specific repository finds out only when the CVE eventually lands in cvelistV5/NVD.

Ask

Any one of these would eliminate mass polling:

1. A filter on the global advisories API, e.g. type=repository or ecosystem=none, that returns published repository-level advisories
2. An app-subscribable repository_advisory.published event that does not require installation on each repository
3. Inclusion of ecosystem-less repository advisories in github/advisory-database under an unreviewed-style label

Prior discussions

This gap has come up before: #67871 (staff response indicated a global advisory feed was not on the near-term roadmap), #181073, #12226. Raising it again with concrete, current examples because these advisories have no other public feed anywhere: the per-repo API is load-bearing for the entire ecosystem's visibility into this class of vulnerability.

[github-actions[bot]]

Thank you for your interest in contributing to our community! We currently only accept discussions created through the GitHub UI using our provided discussion templates. Please re-submit your discussion by navigating to the appropriate category and using the template provided.

This discussion has been closed because it was not submitted through the expected format. If you believe this was a mistake, please reach out to the maintainers.