The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Private vulnerability reporting is the way a researcher sends a security issue privately to a GitHub repository’s maintainers. A repository security advisory is the maintainer-managed record and workflow for investigating the issue, coordinating a fix, and deciding when to publish details. They are related stages, not competing features: a private report can start the advisory process.
How the two GitHub features differ
| Question | Private vulnerability reporting | Repository security advisory |
|---|---|---|
| Main purpose | Privately send a vulnerability report to repository maintainers. | Privately document and manage assessment, remediation, and eventual disclosure. |
| Who starts it | Any reporter, if the repository has enabled the feature. | A maintainer or other user with the required repository role. A researcher’s private report can propose an advisory workflow. |
| What happens | The reporter submits a form with details about the issue. | Maintainers create or manage an advisory draft, work on a fix, and publish when ready. |
| Visibility | The submission is handled privately. | The draft is private; publication makes the current advisory information public. Collaborators can see the conversation history. |
| Availability covered here | Public repositories on GitHub.com where the owner or an administrator has enabled private reporting. | Public repositories on GitHub.com. |
GitHub describes repository security advisories as a way for public-repository maintainers to privately discuss and fix vulnerabilities. Its private reporting feature lets anyone report an issue when the repository has enabled it. See GitHub’s repository security advisory documentation and instructions for privately reporting a vulnerability.
What a private vulnerability report contains
When enabled, the repository offers a Report a vulnerability form. GitHub’s default form asks for a summary, details, proof of concept, and impact statement. Maintainers can customize the form to request information relevant to their project. A clear, reproducible report helps maintainers understand the affected component and assess the impact.
GitHub says the reporter is added as a collaborator and credited user on the proposed advisory. The reporter can optionally start a temporary private fork to help address the problem. The maintainer alone can merge changes from that fork into the parent repository. The submission itself does not make the vulnerability public. Details are in GitHub’s private reporting guide.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows 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 reinstall#1 Best Overall
What maintainers do with a repository security advisory
A maintainer with the appropriate role can create a draft advisory and use it to coordinate privately with the reporter and other collaborators. The draft records information such as the vulnerability description, affected products and versions, severity, weakness, and credits; a CVE may be included or requested. Maintainers can work on and validate a patch before deciding to publish.
When possible, include a fixed version so affected users know what version is safe to install. After publication, GitHub reviews public advisory data for inclusion in the GitHub Advisory Database. GitHub may use published advisories to issue Dependabot alerts; it says the review and potential alert process can take up to 72 hours, but an alert is not guaranteed. See Repository security advisories and GitHub’s advisory creation guide.
If you are reporting a vulnerability
- Check the repository’s security policy and look for the private reporting option. If enabled, open the repository’s Security tab and choose Report a vulnerability.
- Provide a concise summary, technical details, a reproducible proof of concept, and the potential impact. Follow any additional instructions in the repository’s policy or report form.
- Submit the report privately and give maintainers time to assess it. You may offer to help through a temporary private fork, but only a maintainer can merge changes into the main repository.
- If private reporting is unavailable, follow the repository’s security policy. If there is no policy, ask publicly for the preferred security contact without including vulnerability details. Agree on disclosure expectations and allow maintainers a chance to fix the issue.
GitHub’s coordinated disclosure guidance treats disclosure as a joint process between reporters and maintainers. It also advises reporters not to assume compensation when no public bounty program exists. Read GitHub’s coordinated disclosure guidance.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.If you maintain a repository
- Enable private vulnerability reporting in the repository’s settings if you want researchers to submit reports through GitHub. Repository owners and administrators can configure it; GitHub also documents organization-level configuration. For the repository settings path and permissions, see GitHub’s configuration guide.
- Customize the form if the default questions do not gather enough information. Add
VULNERABILITY_REPORT.ymlorVULNERABILITY_REPORT.yamlin the.githubdirectory. A repository-level form takes precedence over an owner’s default form. - Review the report, collaborate privately on investigation and remediation, and create or update the advisory draft. Record affected package, ecosystem, and version information, severity, and a fixed version when available.
- If a CVE is needed, request one through the advisory workflow or provide an existing identifier. GitHub says an eligible request usually receives review within 72 hours. Requesting a CVE does not publish the advisory; if GitHub assigns one, its details are published when the advisory is publicly released.
- Publish when the fix and disclosure timing are ready. GitHub then reviews the advisory for its database and may use it for Dependabot alerts; the process can take up to 72 hours.
See Creating a repository security advisory for the advisory fields and workflow.
Quick Recap
Best Value
Rank #3
Which one should you use?
- As a researcher: use private vulnerability reporting to send the initial disclosure when the repository has enabled it.
- As a maintainer: use a repository security advisory to track the issue privately, coordinate a fix, and prepare public disclosure.
- If reporting is disabled: use the repository’s published security policy, or ask for a security contact without posting technical details publicly.
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.
