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

[jgamblin]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

API

Body

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++ (under active attack interest right now)

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

Advisory	CVE	Per-repo API	Global GET /advisories	GraphQL
GHSA-r39g-3mcw-xcg2	CVE-2026-48770	visible	0 results by cve_id, 404 by GHSA id	NOT_FOUND
GHSA-3x3f-3j39-pj3v	CVE-2026-48800	visible	not returned	NOT_FOUND
GHSA-p58x-r3c9-x9p6	none assigned yet	visible	not returned	NOT_FOUND
GHSA-qm4c-qg8p-qfcr	none assigned yet	visible	not returned	NOT_FOUND

These are not hypothetical: public proof-of-concept exploits exist for both assigned CVEs, Rapid7 assesses that exploitation typically follows disclosure within days for this class, CVE-2026-48800 required a follow-up fix in v8.9.6.2 after the first patch was bypassed, and we are observing active exploitation attempts in our own telemetry. The window between advisory publication and the CVE appearing in cvelistV5/NVD is exactly when defenders most need machine-readable data, and it is exactly when none exists: the last two rows above are published advisories for a major desktop application with zero signal available from any feed, search surface, or event stream. Anyone not already polling that specific repository finds out only after the fact.

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

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[tanvishinde017]

This is a well-written and compelling use case.

Polling thousands of repositories individually clearly works, but as you pointed out, it shifts unnecessary load to both consumers and GitHub. Repository-level advisories with assigned CVEs are publicly visible security data, so having no aggregate discovery mechanism creates a real visibility gap.

Among the proposals, a global advisories API filter (for example type=repository) seems like the most natural extension because it would preserve existing workflows and benefit downstream consumers such as OSV, deps.dev, and internal security platforms.

The Notepad++ examples are particularly useful because they demonstrate that this is not a theoretical edge case. Desktop applications, firmware, and tooling projects don't always map cleanly to package ecosystems, yet defenders still need timely machine-readable access to those advisories.

Hopefully the security team can comment on whether there are any plans to expose repository advisories through a broader feed or GraphQL surface. The current per-repository polling approach feels more like a workaround than a long-term solution.