Security Policies & Vulnerability Disclosure

Security Policies and Vulnerability Disclosure

Every widely used open source project eventually receives a security report. When it arrives, maintainers need to know where it should go, who handles it, how to fix it without tipping off attackers, and how to tell users once a fix is ready. Projects without a plan get reports as public issues — exposing users before a fix exists — or let reports sit unanswered until the researcher publishes anyway.

Coordinated vulnerability disclosure (CVD) is the widely accepted process: reporters privately notify maintainers, maintainers fix the issue within a reasonable time, and both publish details once users can protect themselves. A short security policy and a few repository settings make that process the default.

TL;DR

Publish a SECURITY.md with supported versions, a private reporting channel, and expected response times.
Enable private vulnerability reporting on your forge so reports never start as public issues.
Acknowledge quickly, reproduce, and assess severity (for example with CVSS).
Fix in a private fork or branch, agree on a disclosure date, and coordinate with downstream distributors when needed.
Request a CVE ID, publish a security advisory with affected and fixed versions, and release the fix.
Credit reporters, document lessons learned, and keep the policy current.

Quick Example

A SECURITY.md at the repository root (GitHub also recognizes it in .github/ or docs/):

Enabling private vulnerability reporting for a repository with the GitHub CLI:

Core Concepts

The Security Policy

A good policy answers the reporter's questions before they ask:

Organization-wide default policies can live in a .github repository so every project inherits one. A security.txt file (RFC 9116) on the project's website points researchers to the same channel.

Private Reporting Channels

Private vulnerability reporting on GitHub (and similar features on other forges) lets reporters submit a draft advisory visible only to maintainers.
A security email alias routed to several maintainers — never a single person's inbox.
Encrypted email (PGP) for sensitive reports where needed.
Foundation or ecosystem security teams for projects under umbrella organizations.

Triage

Acknowledge receipt quickly, even if assessment takes longer.
Reproduce the issue and confirm affected versions and configurations.
Assess severity with a consistent method such as CVSS, plus project-specific context: is the vulnerable code reachable in default configurations?
Decide whether it is a vulnerability, a hardening opportunity, or out of scope — and explain the decision to the reporter.

Coordinated Fixes

Work on the fix privately — GitHub security advisories provide temporary private forks for this. Prepare patches for all supported versions, write regression tests, and agree on a disclosure date with the reporter. Many projects default to a fix window of around 90 days, shortened when a vulnerability is actively exploited. For widely distributed software, give Linux distributions and major downstream users advance notice under embargo so patched packages are ready at disclosure.

CVEs and Advisories

A CVE ID gives the vulnerability a unique identifier used by scanners and advisories. GitHub, as a CVE Numbering Authority, can assign CVE IDs for advisories in public repositories; other CNAs cover specific ecosystems and vendors. The published security advisory states affected and patched versions, severity, impact, workarounds, and credits, and flows into vulnerability databases such as the GitHub Advisory Database and OSV, which power tools like Dependabot. See Vulnerability Management.

Disclosure

At the agreed time: release patched versions, publish the advisory, update the changelog with a clear security note (see Release Notes and Changelogs), and announce through the project's usual channels. Afterward, review what led to the vulnerability — missing input validation, unsafe defaults, absent tests — and fix the class of problem, not only the instance.

When Things Go Wrong

See Security Incident Response.

Best Practices

Route Reports to More Than One Person

A security alias or team ensures reports are seen during vacations and maintainer turnover.

Be Explicit About Supported Versions

Users and reporters need to know which versions will be fixed; without it, every report becomes a negotiation.

Communicate Throughout

Regular updates to the reporter — even "still working on it" — prevent frustration and early disclosure.

Strengthen the Project Afterward

Add regression tests, fuzzing, and dependency and secret scanning, and review the project's supply-chain posture. See Software Supply Chain Security.

Common Mistakes

No Private Channel

Silent Fixes

Fixing Only the Latest Release

FAQ

What is a SECURITY.md file?

A file in a repository that describes the project's security policy: supported versions, how to report vulnerabilities privately, what to expect after reporting, and how disclosure works. Forges such as GitHub link to it from the repository's security tab.

What is coordinated vulnerability disclosure?

A process in which a reporter notifies maintainers privately, maintainers develop and release a fix, and details are published once users can protect themselves, on a timeline agreed between them.

Do open source projects need CVE IDs?

For vulnerabilities in released software that users depend on, yes: CVE IDs let scanners, distributions, and advisories identify affected versions. Forges such as GitHub can assign them as part of publishing an advisory.

How long should a project take to fix a vulnerability?

It depends on severity and complexity. Many projects aim for a fix within about 90 days and move much faster for critical or actively exploited issues. The policy should state the expected timeline and how exceptions are handled.

What if a reporter discloses before a fix is ready?

Respond quickly: confirm the issue publicly, publish any mitigations or workarounds, and release a fix as soon as possible. Clear policies and regular communication make early disclosure less likely.