If a project cannot receive private vulnerability reports through GitHub, its maintainers should publish a clear SECURITY.md policy with a monitored, private contact route. Depending on the project’s capacity and platform, that route could be a security email, a verified confidential issue tracker, or an external coordinated-disclosure service. Reporters should never post vulnerability details in a public issue.
What should I do if a repository doesn’t have private vulnerability reporting enabled?
Follow the repository’s security policy if it has one. On GitHub, private vulnerability reporting is an opt-in feature for eligible public repositories; a SECURITY.md file is separate. The file can tell reporters how to reach the project, but it does not itself create GitHub’s private report form. If the form is unavailable and no private route is documented, GitHub advises reporters to consult the policy or ask publicly for the preferred security contact without including vulnerability details. See GitHub’s private vulnerability reporting guidance and its coordinated disclosure guidance.
How do I report a security vulnerability to an open-source project?
- Look for the project’s policy. Check the repository’s
SECURITY.mdfile or security page for supported versions and a private reporting route. - Use the route the maintainers specify. It may be a security email, a confidential tracker, or a disclosure platform. Confirm that the issue or form is actually private before submitting details.
- Include useful, proportionate information. Identify the affected version or commit, explain the impact, provide reproduction steps or a proof of concept, and give maintainers a way to contact you. Avoid sending unnecessary sensitive data.
- Keep the report out of public channels. If you cannot find a private route, ask for the security contact in a public issue or other appropriate public channel without describing the vulnerability.
GitHub’s disclosure guidance warns that a public request for a contact is immediately visible, so it should not include vulnerability details.
What alternatives can maintainers offer?
A security policy and private email
A SECURITY.md policy is a practical starting point for projects without a private-reporting feature. It can name supported versions, give a private email or other route, describe what a report should contain, set expectations for acknowledgement and coordination, and explain how users will hear about a fix. Keep the address monitored, preferably use a project-controlled account, and make clear which maintainers can access it. Google’s Open Source Vulnerability Guide offers guidance for establishing a coordinated disclosure process.
#1 Best Overall
A confidential issue tracker
A tracker can keep intake close to the project’s development workflow, but only if confidentiality is actually enforced. GitLab’s handbook documents confidential issues and a vulnerability disclosure template; it is an example, not proof that every tracker or project configuration is safe for sensitive reports. Before directing reporters to a tracker, verify visibility permissions, notifications, integrations, and who can access the issue. A normal issue should be treated as public unless the platform and configuration clearly say otherwise. See GitLab’s vulnerability disclosure handbook.
An external coordinated-disclosure platform
Services such as HackerOne’s vulnerability disclosure offering and Bugcrowd’s disclosure and bug bounty workflows can provide structured intake or coordination. A bug bounty is a separate choice: offering rewards brings scope, triage, and program-management obligations, and is not required to publish a disclosure policy. The available documentation does not establish project-specific pricing or eligibility, so maintainers should check the service’s current terms rather than assume a particular arrangement.
An existing ecosystem security program
Projects accepted into Google OSS-Fuzz can use its private handling for bugs found through the program. This is not a general inbox for arbitrary vulnerability reports: the project must qualify, and the route applies to findings from OSS-Fuzz. Its project guidance describes the program context.
Can maintainers use a private issue tracker or security email instead?
Yes, if the route is private in practice and someone is responsible for monitoring it. A simple policy and maintained security email may be enough for a small project; a tracker or outside platform can add workflow structure but also requires setup and ongoing attention. Use this checklist before naming a route in the policy:
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match- Confidentiality: Can only the people needed for investigation see the report? Are notifications and integrations also protected?
- Discoverability and usability: Can an outside reporter find the instructions and submit a report without an account or avoidable friction?
- Response ownership: Is someone assigned to monitor the route, acknowledge reports, and coordinate triage?
- Fix and release workflow: Can maintainers involve code reviewers, CI, release managers, and downstream package maintainers as needed?
- Disclosure terms: Does the project explain how it will coordinate a fix and communicate with reporters and users?
- Operational constraints: Are there costs, eligibility rules, contractual terms, or staffing needs that make the route unsuitable?
What should a security policy tell vulnerability reporters?
A useful policy should answer the questions a reporter needs before sending sensitive information and the questions maintainers need to handle the report:
- Which versions are supported and where the private report should be sent.
- What information helps reproduce and assess the issue, such as affected versions or commits, impact, and reproduction steps.
- How maintainers will acknowledge and coordinate with the reporter, including any response expectations the project can realistically meet.
- Who can access the report and how maintainers will coordinate with downstream projects where necessary.
- How the project expects to validate a fix, announce affected and fixed versions, and advise users what to do.
Do not promise a response time or disclosure date the project cannot honor. Clear, workable expectations are more useful than an unsupported deadline.
What happens after a private report arrives?
Private intake is only the first part of vulnerability handling. A coordinated process moves from triage through remediation to public communication. GitHub describes its repository advisory workflow as private discussion and fixing on GitHub.com followed by publication; it is not a universal service for projects hosted elsewhere. Its overview is at About repository security advisories.
- Acknowledge and assess: Restrict access to people who need to investigate, assess impact and affected versions, and ask for any missing details through the private route.
- Coordinate: Work with the reporter and, where relevant, downstream maintainers. Agree on a practical plan for mitigation, testing, and disclosure.
- Prepare and validate a fix: Develop a remediation, verify it, and plan its release and distribution.
- Inform users: When disclosure is appropriate, publish an advisory that identifies affected and fixed versions and tells users what action to take.
How should projects set disclosure timing?
There is no single deadline that every project must adopt. Google Security Research describes its own 90-day disclosure deadline, with public details released after 90 days or sooner if the vendor releases a fix. Google OSS-Fuzz says it makes reported issues public 90 days after notifying project authors, or when a fix is released if that happens first; its guidelines also describe a 14-day grace period for a scheduled patch. Those intervals are the policies of those programs, not universal standards. Projects should state a workable approach and coordinate timing with the reporter and affected parties. Google Security Research’s policy says, “We believe that vulnerability disclosure is a two-way street.” See Google Security Research’s disclosure policy and OSS-Fuzz’s disclosure guidelines.
Is OSV a private reporting alternative?
No. OSV provides a vulnerability schema, reference infrastructure that aggregates and indexes advisory data, and OSV-Scanner tooling. Projects can publish machine-readable vulnerability records in the OSV format for consumers to use, but OSV documentation does not describe it as a confidential report channel. It complements intake and coordinated disclosure; it does not replace them. See the OSV project.
Quick Recap
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.
