Start with the affected project’s security policy and use its designated private reporting channel. If you cannot find one, ask for a security contact without describing the vulnerability publicly. Then send maintainers enough precise, safe detail to verify the issue and coordinate next steps before publishing it.
1. Find the project’s preferred reporting route
Check the affected repository’s SECURITY.md file and its GitHub Security area. Follow the project’s stated scope, contact method, and handling instructions; reporting procedures differ between repositories. GitHub’s coordinated disclosure guidance explains that project policy is the starting point.
Check whether private vulnerability reporting is enabled
On GitHub, a public repository may offer a Report a vulnerability flow if its maintainers have enabled private vulnerability reporting. It is optional and separate from the repository’s SECURITY.md; it is not available for every project. If the flow appears, review any policy shown there and use it if it matches the project’s instructions. GitHub describes eligibility and the reporting form in its private reporting documentation.
If the project lists a security contact
Use that contact or other private channel exactly as instructed. Do not substitute a public issue or pull request simply because it is more familiar.
#1 Best Overall
2. If there is no security policy or private route
When no contact or policy is evident, GitHub recommends opening a public issue to ask for the preferred security contact. That issue is public as soon as it is posted, so keep it limited to the request. Do not mention the vulnerability, affected secrets, exploit steps, sensitive data, or proof of concept. The project’s maintainers can direct you to a private channel.
Do not assume GitHub’s fallback applies as the policy for every hosting platform or project. The affected project’s current instructions take precedence wherever they exist.
Rank #2
3. Prepare a report maintainers can validate
Be concise, factual, and specific. Include the information needed to understand impact and reproduce the behavior, but do not send unrelated personal or confidential data. GitHub’s reporting form may request a summary, details, proof of concept, and impact; projects can customize its fields. Its own security page also illustrates the kind of details that can help a maintainer assess a report.
- Project and location: repository name, affected component, file, function, endpoint, or other code location if known.
- Versions: affected release, branch, or commit, and any version you tested.
- Conditions: configuration, permissions, dependencies, or other prerequisites needed for the issue to occur.
- Reproduction: numbered steps and the observed result, plus the expected result where useful.
- Impact: what an attacker could do, and under what conditions. Distinguish what you observed from what you infer.
- Proof of concept: provide a minimal, safe example when appropriate and when the private channel supports it. Avoid live exploitation, real credentials, personal data, or destructive actions.
State what you do not know rather than guessing. A clear report helps maintainers reproduce the issue without exposing more than needed.
Recommended Free Tools
4. Coordinate remediation and disclosure
After private notification, give maintainers a chance to confirm the issue and prepare a fix or mitigation. Agree on how you will communicate, what information can be shared, and when public details may be released. Coordinated disclosure is intended to let affected users benefit from a fix or mitigation when possible; it does not mean there is one universal timetable.
GitHub advises against publishing before maintainers have had a chance to remediate, bypassing them, or expecting a bounty unless the project has a public bounty program. If contact attempts fail or a requested delay becomes excessive, public disclosure may be reasonable, but the cited guidance does not set a general deadline that applies to every project.
Rank #4
Why you may see a 45-day deadline
CERT/CC’s Vulnerability Disclosure Policy says it discloses reports it receives after 45 days, whether or not a patch is ready. That is CERT/CC’s own policy, not an industry-wide deadline for open-source maintainers. Timing and coordination arrangements depend on the reporting channel and the project.
Quick Recap
Quick route comparison
| Route | When to use it | What to check |
|---|---|---|
| GitHub private vulnerability report | When the public repository has enabled the feature and the route fits the project’s instructions. | Review the displayed policy; the feature is optional and separate from SECURITY.md. |
Project’s SECURITY.md instructions |
When the project specifies a private contact or reporting procedure. | Follow its scope, preferred channel, and requested details. |
| Public contact-request issue | When no security policy or private route is evident and you need to ask how to contact maintainers securely. | Ask only for the preferred security contact. Do not disclose vulnerability details. |
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.
