Start with the affected project’s security policy and use its designated private reporting channel. If you cannot find one, ask publicly only how to contact the security team—do not post the vulnerability, exploit details, or proof of concept. Then send maintainers a concise report they can validate and coordinate disclosure with them before sharing technical details publicly.
1. Find the project’s security policy
Check the affected repository for a SECURITY.md file. On GitHub, it may also be surfaced in the repository’s Security area. Follow the project’s own instructions, including any stated scope, preferred contact method, and handling rules. Reporting arrangements are project-specific; a platform’s general guidance does not replace the repository’s current policy. GitHub’s coordinated-disclosure guidance explains where to look and why to follow the project’s stated route.
As an Amazon Associate I earn from qualifying purchases.
2. Choose a private reporting route
Use the private channel the project specifies. On GitHub, a public repository may offer a separate Report a vulnerability flow when maintainers have enabled private vulnerability reporting. The feature is optional, so its absence does not mean the project has no other private contact route. Review any policy shown in the form before submitting. GitHub documents the feature and its availability.
| Route | When to use it | What to check |
|---|---|---|
| GitHub’s private vulnerability reporting form | The repository has enabled it. | Read the displayed policy and complete the requested fields. The form is separate from SECURITY.md. GitHub Docs. |
| Project’s stated security contact or channel | The repository policy names a private route, such as a security contact. | Follow the project’s stated scope and instructions. GitHub’s guidance on coordinated disclosure. |
| Public request for a private contact | No policy or private channel is apparent. | Ask only where to report a security issue privately. Do not identify the flaw or include technical details. GitHub recommends this fallback. |
3. If there is no security policy, request contact without exposing the issue
If you cannot identify a private route, GitHub recommends opening a public issue to ask for the project’s preferred security contact. Because that issue is visible immediately, keep it generic: say you have a security concern and ask how to report it privately. Do not include the vulnerability’s location, affected versions, exploit steps, screenshots, proof of concept, credentials, personal data, or other sensitive information. Move the technical discussion to the private channel once maintainers provide one. See GitHub’s no-policy guidance.
#1 Best Overall
4. Prepare a report maintainers can validate
Keep the report focused on the security impact and the facts needed to reproduce it. GitHub’s form requests a summary, details, proof of concept, and impact by default, although repository maintainers can customize the fields. Include only information relevant to the issue; do not send unrelated sensitive data. The github/docs security page provides an example of project-level reporting instructions and useful report details.
- Project and location: identify the repository and the affected file, component, endpoint, or feature.
- Impact: describe what an attacker could do and under what circumstances, without overstating what you have verified.
- Affected code state: give the version, branch, or commit you tested, if known.
- Conditions: note required configuration, dependencies, permissions, or other setup.
- Reproduction: provide clear steps and the observed result, distinguishing it from the expected result.
- Proof of concept: include one only when safe and appropriate for the private channel. Avoid real credentials, personal information, destructive actions, or data from other people.
5. Coordinate validation, a fix, and disclosure
After sending the report, work with maintainers privately so they can confirm the issue, assess its scope, and determine a mitigation or fix. Agree on how and when to publish details, ideally when users can act on a fix or mitigation. Avoid announcing the vulnerability publicly before maintainers have had a reasonable opportunity to respond, and do not bypass them simply to publicize it. GitHub’s guidance recognizes that disclosure may be reasonable after unsuccessful contact attempts or an excessive requested delay, but it does not set one deadline for every project. Read GitHub’s coordinated-disclosure guidance.
Rank #2
There is no universal disclosure clock
Agree on a practical timeline with the project when possible, taking into account severity, maintainer responsiveness, and whether users have a mitigation. CERT/CC’s own Vulnerability Disclosure Policy says it discloses reports it receives after 45 days whether or not a patch is ready. That is CERT/CC’s policy, not a universal deadline for open-source maintainers. The OpenSSF’s Guide to coordinated vulnerability disclosure for open source software projects offers broader guidance for finders and projects.
Recommended Free Tools
Should you open a public issue or pull request?
Not to report the vulnerability itself. Use a private channel for technical details. If none is listed, a public issue can ask only for a private security contact. Do not open a public issue or pull request that reveals the flaw, and do not submit a public fix that makes the vulnerability easy to identify before maintainers can coordinate remediation.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Should you expect a bounty?
Only if the project has a public bounty program with terms that apply to your report. A security report does not by itself create an expectation of payment. GitHub’s disclosure guidance cautions against expecting a bounty where no public program exists.
Quick Recap
Rank #4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
