Investing in the security advisory experience on GitHub 🔐

We hear you: the signal-to-noise problem is real

Over the past few months, we've heard from maintainers across the ecosystem - in community discussions, in support channels, and directly - that the volume of private vulnerability reports is increasing significantly. Some reports are AI-generated with minimal or no human review. Others describe real behavior but mischaracterize it as a vulnerability, requiring deep investigation to confirm non-impact.

The burden this places on maintainers is significant. Validating even a single poor-quality report can take hours, and when reports arrive in volume, the effect is cumulative: maintainer time is consumed, trust in the reporting channel erodes, and the value of private vulnerability reporting as a coordinated disclosure mechanism is undermined.

We're seeing this reflected in broader ecosystem trends too. Multiple high-profile projects have had to change their vulnerability intake processes, raise submission requirements, or discontinue bounty programs entirely. Industry working groups are formally tracking AI-generated low-quality security reports as a systemic challenge for open source.

What we're working on

We're investing across several areas to improve the experience. Here's what's on our radar at a high level:

Reducing the burden of low-quality reports

We're exploring ways to help maintainers triage faster and deal with fewer junk reports:

• AI-assisted triage suggestions to help maintainers quickly assess incoming PVRs - surfacing plain-language claim assessments, duplicate and similarity checks against the Advisory Database, detection of codebase inconsistencies (e.g., "this report references a function that doesn't exist in this repository"), and scope validation against your SECURITY.md. Any AI-powered suggestions would be clearly labeled as AI-generated, visible only to maintainers, and would serve as a decision-support layer only - a human must always make the final call on every report.

• Tooling for faster responses - canned response templates, bulk actions for managing multiple reports, and improved filtering and sorting in the triage view.

• Raising the submission bar - we're looking at structured fields, rate limiting, and pre-submission validation to improve report quality before it reaches you.

Fine-grained permissions for security advisories

Today, there's no way to give someone security advisory access to a repository without making them an admin. The existing Security Manager role is org-wide only, which doesn't work for organizations that need per-repo scoping. We're working toward enabling fine-grained permissions for security advisories - create, read, edit, and close/accept/publish - that can be assigned at the repository level through custom repository roles. This would let you grant precisely the access your security responders need, on exactly the repositories that are relevant, without over-provisioning admin access.

Enabling CI on advisory workspace private forks

One of the longest-standing requests we hear is the inability to run GitHub Actions on the temporary private forks created for security advisories. Right now, maintainers can't run their CI pipeline against a security fix before merging, which means you're either merging untested patches or maintaining a separate private fork workflow outside of our advisory tooling.

We're actively working through the security model required to enable Actions on these workspaces safely. The core challenge is ensuring that embargoed vulnerability details can't leak through webhook payloads, third-party app integrations, or untrusted workflow execution. This is complex work with real security implications, and we're being deliberate about getting it right - the integrity of the embargo model is foundational to the trust that makes coordinated disclosure work.

Our philosophy

A few things we want to be explicit about:

Humans remain in the loop. Any AI-assisted tooling will be informative and clearly labeled and maintainers decide what happens to every report. Features should ship with sensible defaults, provide granular controls, and give maintainers the ability to configure their experience to match their project's needs - not impose a one-size-fits-all policy. Repository administrators may not always be the appropriate user to handle a vulnerability report, so expanding fine-grained permissions can increase the potential for human security support.

We're not trying to ban AI-assisted security research. AI tools can find real vulnerabilities, and legitimate researchers may use them as part of their workflow. The goal is to raise the quality floor for submissions and give maintainers better tools to separate signal from noise - not to penalize the tool, but to hold the human submitter accountable for the quality of what they submit.

We want your input

We're building this for the people who maintain the open source ecosystem, and your feedback directly shapes our priorities. Some questions we'd love your perspective on:

1. Triage workflow: What's the most time-consuming part of handling an incoming vulnerability report today? Where do you lose the most time - initial assessment, back-and-forth with reporters, investigating claims, or something else?

2. Report quality: What information, if required upfront from reporters, would most help you triage faster? (e.g., proof of concept, affected versions, reproduction steps, disclosure of AI tool usage)

3. Permissions: How are you currently managing who has access to your security advisories? What's broken about the current model?

4. CI on private forks: How are you working around the lack of CI today? Separate private repos? Merging untested? Something else?

5. Anything else: What's the single most impactful change we could make to the repository advisory and/or private vulnerability reporting experience?

Thank you for trusting GitHub with your coordinated disclosure workflows. The maintainer community's willingness to share honest, detailed feedback - even when it's critical - is what helps us prioritize the right work. We'll continue to share updates as these efforts progress.

[feanil]

CI on private forks is by far the most critical for us. It takes too much time and resources to validate fixes without it. Tooling to triage faster would also be really useful, especially response templates and AI-suggestions for de-duplication.

[Dakospy]

👍

[jsoref]

• Permissions? I'm fairly certain I found them fairly broken, but I can't remember all the details. From memory one problem I had as a reporter was that I couldn't add someone to a submission I made -- I could of course screenshot everything since I made it, and the org / repo admin could add whomever they wanted. But, why shouldn't I be allowed to add people? I reported it, and I can see it.

• CI on private forks? I create private disconnected forks and push things there to test CI. It's an evil workaround the lack of CI for security forks.

[Dakospy]

Write me up

[EiJackGH]

ayooo

[Dakospy]

Yes

[wraithgar]

What's the single most impactful change we could make...

Aggregation. If I have 70 repos I have to go to 70 different pages to triage reports. There are org level pages for vulnerabilities, secrets scanning, etc but there is no org level equivalent to the security/alerts/advisories page. If we can't easily triage then we can't even get to the next steps.

[ljharb]

A thousand times this. However, please do not restrict this to "an org" or "a user" or even "a github enterprise".

Many many people have things to triage that span users, orgs, enterprises, or all of them.

[RCheesley]

The org-level page for secret scanning is totally useless unless you're a paying org though. It tells you the number of secrets exposed across your org, but there's no way of seeing what repos, what secrets, which ones have been dealt with etc. Apparently that's a pay-to-play feature at this time. :(

[djc]

We really want to be able to decloak non-security-sensitive issues as normal issues, to expose the wrongfully-classified issues, their context (and potentially their reporter).

Partly because even if the issue is not security-sensitive, there might still be something useful to follow up on.

[potiuk]

This is a cool idea!

[zbraiterman]

Enabling CI on advisory workspace private forks would be the biggest priority for me (it would be a major time saver on some of my projects). I currently use separate private repos (at least in most cases).

[RCheesley]

With security advisories, we often get duplicated reports for ones we're already working on. There's no way I can tell to search the advisories for keywords - the top search bar doesn't let you limit it to advisories and there's no search within the UI of the security advisories. Would be pretty handy.

[djc]

Another thing I've noticed is that notifications about advisories do not currently appear in the Notifications tab in the iOS app. This is really annoying because I usually feel like I've caught up with projects I maintain after looking at the app, but then I might potentially miss new advisories until I next look at notifications in a browser.

[ljharb]

Ideally it'd be a separate tab, so I can still keep up, but it doesn't clutter the other notifications.