Responsible Disclosure

Responsible disclosure is the practice of reporting a security vulnerability privately to the people who can fix it, giving them a fixed window to ship a patch, and publishing the details only after users can protect themselves. Also called coordinated vulnerability disclosure (CVD), it trades a short-lived secret for a fix that reaches users before an exploit does.

Mechanically, responsible disclosure is a protocol with four messages and a clock: a private report, an acknowledgment, a fix, and a public security advisory. The clock is what makes it work. A report with no deadline is a request the vendor can ignore, which is why CERT/CC publishes reports "45 days after the initial report" whether or not a patch exists (CERT/CC disclosure policy). In 2026, the protocol is carrying far more load than it was designed for. Anthropic says its models surfaced more than 29,000 candidate vulnerabilities in open source over six months, and its researchers manually triaged about 6,000 of them, according to our coverage of Anthropic's OSS Scanner.

Our position: the word "responsible" put the whole duty on the finder, and that was always half the contract. Responsible disclosure has three parties with obligations. Finders owe maintainers a validated reproducer, not a guess. Maintainers owe finders a private intake channel, a reply, and a deadline. Both owe users a fix that ships at the same moment as the advisory. One case breaks the protocol outright. For a malicious package, a private report to the author only warns the attacker. Report it to the registry instead.

Responsible disclosure in cybersecurity is the middle option among three choices a finder has about who learns of a flaw first. Full disclosure publishes everything to everyone at once. Non-disclosure keeps the flaw private, to exploit or to sell. Responsible disclosure tells the party that can fix it first, and everyone else later.

In practice, the sequence runs in six steps:

1. The finder locates the project's private intake channel: a security.txt file, a SECURITY.md file, or GitHub private vulnerability reporting.
2. The finder sends a report with the affected versions, a working reproducer, and the impact.
3. The maintainer acknowledges and triages the report. The draft European standard prEN 40000-1-3 sets a maximum of 7 calendar days for acknowledgment, according to ENISA's October 2026 draft technical advisory.
4. The maintainer develops the fix privately and reserves a CVE ID.
5. The fixed release, the advisory, and the CVE publish together, and the finder is credited.
6. If the maintainer stops responding, the deadline passes, and the finder publishes or hands the case to a coordinator.

Responsible disclosure is not the same thing as a bug bounty program. A bounty adds a payout table to the same intake process. Responsible disclosure works with or without money, and in open source it usually runs without any.

Coordinated vulnerability disclosure (CVD) is responsible disclosure under a newer name, adopted because the old name judged only the finder. Microsoft made the switch on July 22, 2010, announcing "a shift in philosophy" and citing the "endless debate between responsible disclosure and full disclosure proponents" (MSRC announcement, archived). Two days earlier, Google's security team had stated the objection directly: "The emotionally loaded name suggests that it is the most responsible way to conduct vulnerability research" (Google Security Blog, July 20, 2010). Google's argument was that a vendor sitting on a critical bug for years is also acting irresponsibly. It proposed 60 days as an upper bound for genuinely critical issues in widely deployed software.

Standards and regulation adopted the new framing. ISO/IEC 29147:2018 covers how a vendor receives reports and publishes advisories. ISO/IEC 30111:2019 covers how the vendor handles them internally. The EU Cyber Resilience Act will require manufacturers to put in place and enforce a coordinated vulnerability disclosure policy once its main obligations apply on 11 December 2027. Its Article 14 duty to report actively exploited vulnerabilities has applied since 11 September 2026.

The CRA also turns responsible disclosure upstream into law. Article 13(6) says manufacturers must, "upon identifying a vulnerability in a component, including in an open source-component," report it to whoever maintains the component and share any fix they wrote (Regulation (EU) 2024/2847). From 11 December 2027, a company selling software in the EU that finds a bug in a dependency has a legal duty to tell the maintainer. We use "responsible disclosure" on this page because it is still the name most people search for. On the substance, the rename was right.

A responsible disclosure fails before it starts if the finder cannot find a private place to send it. Two conventions solve this: security.txt for websites, and SECURITY.md plus GitHub's private reporting for code repositories.

RFC 9116, published in April 2022, defines security.txt, a plain-text file served at /.well-known/security.txt. Only two fields are required, Contact and Expires. The RFC recommends an Expires value "less than a year into the future to avoid staleness" (RFC 9116). PyPI's file, fetched on November 8, 2026, follows that guidance exactly:

Contact: mailto:security@pypi.org
Expires: 2027-11-08T14:39:44.000Z
Preferred-Languages: en
Canonical: https://pypi.org/.well-known/security.txt
Policy: https://pypi.org/security/

Our own security.txt points to our disclosure policy. The policy promises acknowledgment within five business days, aims to resolve critical issues within ten business days, and publishes reports two weeks after the fixing release ships. As of November 2026, though, our Expires value is set to January 2030, far past the RFC's one-year recommendation. A stale security contact is a real failure mode, and a long expiry date hides it.

For open source packages, the trap is in the package metadata. Registries expose a bugs URL, and it usually points at a public issue tracker, as it does for Express:

$ npm view express repository.url bugs.url --json
{
  "repository.url": "git+https://github.com/expressjs/express.git",
  "bugs.url": "https://github.com/expressjs/express/issues"
}

Filing a vulnerability at that URL is full disclosure by accident. npm's documentation says vulnerabilities "should be reported directly to the package maintainers" and advises "doing this privately," using npm owner ls <package-name> or the repository's security policy (npm Docs).

GitHub private vulnerability reporting turns a repository's Security tab into a private intake queue. GitHub introduced it on November 9, 2022, and maintainers must opt in per repository (GitHub changelog). Check that it is enabled before filing.

The request and response shapes below come from GitHub's published OpenAPI description, as packaged in @octokit/openapi 24.0.0. The repository, package, and values are placeholders.

# 1. Is private vulnerability reporting enabled?
gh api repos/OWNER/REPO/private-vulnerability-reporting
# {"enabled":true}

# 2. File the report. Only summary and description are required.
gh api -X POST repos/OWNER/REPO/security-advisories/reports --input - <<'EOF'
{
  "summary": "Path traversal in static file handler",
  "description": "Against 2.3.1, GET /static/..%2f..%2fetc%2fpasswd returns /etc/passwd. Full reproducer attached.",
  "severity": "high",
  "cwe_ids": ["CWE-22"],
  "vulnerabilities": [{
    "package": { "ecosystem": "npm", "name": "example-static" },
    "vulnerable_version_range": "<= 2.3.1",
    "vulnerable_functions": ["serveStatic"]
  }]
}
EOF

A successful report returns HTTP 201 and creates a repository security advisory. Trimmed, the parts that matter look like this:

{
  "ghsa_id": "GHSA-abcd-1234-efgh",
  "state": "triage",
  "submission": { "accepted": false },
  "published_at": null,
  "private_fork": null
}

The optional fields are the triage checklist. A maintainer deciding whether to accept a report needs the affected package, the version range, the vulnerable function, and the weakness class. A report that fills them in is faster to accept than one that leaves them blank.

The advisory then moves through a fixed set of states, shown in Figure 1.

Figure 1 traces one report from intake to publication. A repository admin first enables the feature, a public repository setting, with PUT /repos/{owner}/{repo}/private-vulnerability-reporting, which returns 204. The reporter's POST to /repos/{owner}/{repo}/security-advisories/reports returns 201 and creates an advisory in the triage state, with submission.accepted set to false. The maintainer can open a temporary private fork with POST /repos/{owner}/{repo}/security-advisories/{ghsa_id}/forks, which returns 202 and can take up to 5 minutes to become available; the advisory stays in triage. Accepting the report moves the advisory to draft, which GitHub's documentation notes "doesn't make the report public." Closing it moves the advisory to closed, ideally with a comment explaining why the report is not a security risk. From draft, POST /repos/{owner}/{repo}/security-advisories/{ghsa_id}/cve returns 202 and asks GitHub, acting as a CVE Numbering Authority, for an ID. Everything up to this point is private. Publishing moves the advisory to published, adds it to the GitHub Advisory Database, and makes the CVE public. The fixed release should reach the registry at the same moment.

GitHub keeps the secret well until the last step, and the last step is where open source leaks. A fix merged to a public default branch before the advisory publishes is a disclosure of its own, because anyone can read the diff. The temporary private fork exists to close that gap. The maintainer and the reporter build and review the patch privately, then merge, release, and publish in one motion.

You responsibly disclose a vulnerability in an open source package by sending it privately to the maintainers, through the channel they publish, with enough evidence to reproduce it. That covers the common case. The harder question is who the counterparty is, because the right counterparty changes with what you found.

Verdict: default to the maintainer and a short, stated deadline. When the maintainer goes silent, escalate to a coordinator, not straight to the public. When a foundation is the CVE Numbering Authority, use its process: the OpenJS Foundation became a CNA for more than 40 JavaScript projects in 2025. Skip the maintainer entirely when the code is malicious, and contact the registry at once. When a real maintainer's account published the code, tell the registry first, then reach the maintainer through a channel the attacker does not control. In a maintainer account takeover, the maintainer's email or GitHub inbox may be exactly what the attacker holds.

What the report contains matters as much as where it goes. A good report reads like a pull request description: the affected versions, a reproducer that runs against a supported release, the impact stated in terms of the project's own threat model, and a proposed fix. OpenSSL's maintainers credited that pattern when they shipped fixes for 12 AISLE-reported vulnerabilities in January 2026. The findings were tightly scoped, reproducible, and paired with validation the maintainers could act on.

No: a malicious package belongs with the registry, not its author, because the author is the attacker. Responsible disclosure assumes a counterparty who wants the flaw fixed. A malicious publisher wants the opposite, and a private heads-up buys time to rename the package, rotate infrastructure, or push a cleaner-looking version.

The registries split the two cases explicitly. npm routes vulnerabilities to maintainers and malware to a "Report malware" form on the package page. PyPI added project quarantine in August 2024, which lets admins hide a reported project from installation while they review it. By December 2024, about 140 projects had been quarantined, and only one had ever been released from quarantine (PyPI blog). PyPI's safety team also reported resolving over 90% of reported issues in less than 24 hours, as we covered in PyPI's malware response time report.

Coordination still has a role, just with different parties. Before publishing our research on the SANDWORM_MODE npm worm, we notified npm, GitHub, and Cloudflare so they could dismantle the campaign. npm removed the malicious packages, Cloudflare took down the worm's workers, and GitHub removed the attacker's infrastructure. That is coordination with the infrastructure owners, not with the author.

One more boundary belongs here. Publishing a live proof-of-concept package to a public registry is not responsible disclosure, even when the intent is research. The Cursor dependency confusion packages of January 2025 sent environment variables from every machine that installed them to their publisher's servers. A Cursor developer said the company had not commissioned the work. npm's acceptable content policy prohibits malicious code and adds: "This includes content submitted for research purposes."

A finder weighs one more variable before sending a report: whether the report could get them prosecuted. Responsible disclosure only works when reporting is safer than staying quiet.

In the United States, the Justice Department revised its Computer Fraud and Abuse Act charging policy on May 19, 2022. The announcement says the policy "directs that good-faith security research should not be charged" (U.S. Department of Justice). The change is a federal prosecution policy, not an amendment to the statute. It does not bind state prosecutors, and it does not stop a company from suing.

Elsewhere, the protection is thinner. In January 2024, in the Modern Solution case, a German court fined a programmer €3,000. He had found a database password hardcoded in a vendor's software, used it to confirm that customer passwords were stored in plain text, and reported the flaw to the company. The company filed a police complaint against him.

A safe harbor clause can only cover the policy owner's own systems. Ours says so explicitly, and so should every SECURITY.md. The clause costs a project nothing to publish and tells a finder that the private channel is safe to use. Without one, a cautious finder's rational options are silence or anonymous full disclosure, and both leave users worse off.

Responsible disclosure was designed around a scarce finder and an available fixer. In 2026, both assumptions inverted: AI tools made finding cheap, while fixing still depends on a small number of maintainers.

Anthropic's OSS Scanner numbers show the shape of the problem. When penetration testers checked 97 high- and critical-severity findings across 48 projects, 85 met Anthropic's coordinated disclosure criteria, 11 were real but duplicated known issues, and 1 was invalid. OSS Scanner sends unreviewed findings only to projects that opt in, and it runs no 90-day clock on them. The 90-day clock starts only when a finding is validated through Anthropic's human-reviewed program and the maintainer is notified. Maintainers can add a threat_model.md file that tells the scanner what the project does not consider a vulnerability.

The U.S. government is building intake capacity too. The White House announced the Gold Eagle initiative on July 14, 2026: a clearinghouse meant to collect AI-discovered findings, deconflict scanning, and validate reports, reportedly built on CERT/CC's existing VINCE platform. The pressure it responds to is visible in curl. Even after curl's bug bounty shutdown in January 2026, the project was receiving security reports at four to five times its 2024 rate by May.

Downstream, the advisory pipeline is falling behind. In April 2026, NIST stopped enriching most CVEs after CVE submissions grew 263% between 2020 and 2025. A responsible disclosure that completes perfectly can still reach a vulnerability scanner days late, and malicious packages rarely get a CVE at all.

We think the unit of responsible disclosure has changed. It used to be the report. Now it is the validated finding: a reproducer against a supported release and, ideally, a patch. A finder, human or automated, who cannot supply that should hold the finding rather than forward it. Maintainers should publish a threat model, because it lets them close an out-of-scope report with a single link.

The open problem is who owns the secret. Responsible disclosure assumes one finder holds a vulnerability and chooses when to release it. When several tools can find the same bug in the same week, nobody holds it alone, and the real deadline is set by whoever finds it next. The protocol was built for one finder keeping quiet, and it now has to work when the secret is already shared.