AI-assisted vulnerability disclosure guides

Guidance for people on both sides of an AI-assisted security report to an open source project: those using AI tools to find issues, and maintainers receiving the results.

The full guidance lives in the documents linked below and is worth reading before you send or triage a report. If you only have a minute, the points that matter most are:

• Reproduce the finding against a specific release or commit with a working proof of concept before sending anything (finder guide, report template).
• Confirm the code path is reachable by an untrusted actor, not just present in the source.
• Verify file paths, function names, line numbers and affected versions against the real source — AI tools regularly hallucinate these.
• Check the project's security policy, advisories and issue tracker for prior reports or out-of-scope classes.
• Disclose that AI was involved and which parts you verified by hand; concealing it and being found out later does lasting damage to your credibility.
• Use the private channel in SECURITY.md or security.txt, never a public issue, and keep details private until a fix ships or a date is agreed (see the OpenSSF finder guide for the wider process).
• If you scan many projects, keep a human reviewer between the tool and the maintainer, publish an outbound disclosure policy, and rank by impact rather than forwarding everything (scale guidance, policy template).
• Maintainers: triage cheaply by checking whether cited code actually exists and whether the PoC exercises real entry points, before reading the analysis in detail (maintainer guide).
• Maintainers: ask once for the commit tested, a runnable PoC and an AI-use statement; if the reporter cannot produce them, closing is a normal outcome.
• Maintainers: add a few lines to SECURITY.md stating that you require human-verified findings with a working PoC, so the bar is clear before reports arrive (suggested wording).

If your ecosystem funds a Security Engineer in Residence, they can help when you cannot find a security contact, want a second opinion on a finding before reporting, or need a hand with triage when the load spikes.

In this repository

Document	Audience
ai-finder-guide.md	Individuals and organisations using AI to find vulnerabilities in open source software
maintainer-guide-ai-reports.md	Open source maintainers receiving AI-assisted security reports
finder-guide.md	The general OpenSSF coordinated disclosure guide for security researchers, included here for reference
security-engineer-role-description.md	Ecosystems funding a Security Engineer in Residence
templates/report-template.md	A fill-in security report for AI-assisted findings
templates/outbound-disclosure-policy.md	A skeleton policy for organisations running AI scanning at scale

Related guides elsewhere

These documents are meant to add to existing coordinated disclosure practice, not replace it.

• OpenSSF, Guide to coordinated vulnerability disclosure for open source software projects (maintainer side)
• OpenSSF, Guidance for security researchers to coordinate vulnerability disclosures with open source projects (finder side, mirrored here as finder-guide.md)
• CERT/CC, The CERT Guide to Coordinated Vulnerability Disclosure
• FIRST, Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure
• Google Project Zero, Policy and Disclosure: 2025 Edition
• OpenAI, Outbound coordinated vulnerability disclosure policy
• CNCF, The AI-driven shift in vulnerability discovery

Contributing

Suggestions and corrections are welcome via issues or pull requests.

License

The contents of this repository are licensed under the Creative Commons Attribution 4.0 International license (CC-BY-4.0). finder-guide.md is reproduced from the OpenSSF Vulnerability Disclosures working group, also under CC-BY-4.0.