Responsible disclosure is the practice of privately reporting a security vulnerability to the affected vendor and giving them a fixed window — commonly 45 to 90 days — to patch it before any public details are released. The concept was formalized to replace two failure modes: silent non-disclosure, where flaws never get fixed, and full disclosure, where researchers publish exploit details the moment they find a bug, leaving no time for defenders to respond. Google Project Zero's policy, in place since 2015, sets a 90-day deadline with a further 30-day grace period once a patch ships, to let users actually update. CERT/CC uses a 45-day default. Log4Shell (CVE-2021-44228) is the textbook case: Chen Zhaojun at Alibaba reported it to the Apache Software Foundation on November 24, 2021, and it went public on December 9, 2021 — a 15-day window that still triggered a global patching scramble.
What Is the Difference Between Responsible Disclosure and Full Disclosure?
The difference is timing: responsible disclosure withholds technical details until a fix exists or a deadline passes, while full disclosure publishes everything — sometimes including working exploit code — immediately upon discovery. Full disclosure was the dominant model in the 1990s, championed by mailing lists like Bugtraq on the theory that public pressure forces vendors to act. It still produces same-day patches in some cases, but it also arms attackers before defenders can respond; the 2014 "GHOST" glibc vulnerability (CVE-2015-0235) and various Adobe Flash 0-days were weaponized within hours of full-disclosure posts. Responsible disclosure — now more often called "coordinated disclosure" by groups like ISO, which codified the practice in ISO/IEC 29147:2018 and ISO/IEC 30111:2019 — keeps the technical writeup embargoed but still sets a hard deadline, so vendors can't sit on a report indefinitely either.
How Long Do Researchers Typically Wait Before Disclosing?
Most established programs use a window of 45 to 90 days, though the exact number depends on severity and exploitability. CERT/CC's default is 45 days from initial report. Google Project Zero uses 90 days, shortened to 7 days if the bug is already under active exploitation in the wild — that 7-day rule was invoked for the actively exploited Chrome 0-day CVE-2021-38003 in October 2021. Microsoft's MSRC doesn't publish a fixed number but generally targets patch releases to align with Patch Tuesday, sometimes extending internally negotiated timelines to 120 days for complex fixes touching multiple product lines. The common thread across every framework: the clock starts at first contact with the vendor, not at initial discovery, and it runs whether or not the vendor replies.
What Happens if a Vendor Doesn't Respond to a Vulnerability Report?
If a vendor goes silent, the standard practice is to escalate through a coordinating body and then disclose on the original deadline regardless. CERT/CC will act as an intermediary and notify a vendor on the researcher's behalf if direct contact fails, but it does not indefinitely extend the 45-day clock just because a vendor is unresponsive. A well-known example: security researcher Tavis Ormandy of Google Project Zero has published several advisories at the 90-day mark specifically because vendors — including Symantec in 2016 (CVE-2016-2208 and related AV-engine flaws) — had not shipped a fix. The public advisory typically states the report date, the deadline given, and the vendor's response status, which is also why "vendor did not respond" has become a recurring line in disclosure timelines for CVEs tied to smaller IoT and embedded-device manufacturers.
Do Bug Bounty Programs Follow Responsible Disclosure Rules?
Yes — bug bounty platforms formalize responsible disclosure into contractual terms, and the payouts are now substantial. HackerOne reported paying out more than $300 million in cumulative bounties to researchers by 2023, and its 2023 Hacker-Powered Security Report counted over 66,000 valid vulnerabilities resolved that year across customer programs. Bugcrowd's 2023 "Inside the Mind of a Hacker" report put average payouts for critical findings at over $3,000, with top researchers earning six figures annually. These programs typically embed the disclosure clock directly in their policy pages — Google's Vulnerability Reward Program, for instance, asks researchers not to disclose until Google confirms a fix is available or 90 days have elapsed, mirroring Project Zero's own internal standard. The programs exist precisely because uncoordinated public disclosure of a bounty-eligible bug can void the payout entirely.
Are Security Researchers Legally Protected When They Disclose Responsibly?
In the US, researchers acting in good faith gained meaningful legal cover starting May 19, 2022, when the Department of Justice announced it would not charge good-faith security research under the Computer Fraud and Abuse Act (CFAA). Before that policy, the CFAA's broad "unauthorized access" language had been used to threaten researchers even when their intent was purely defensive — the 2013 prosecution threat against weev (Andrew Auernheimer) over an AT&T iPad data exposure is a frequently cited chilling example. Separately, many vendors now publish explicit "safe harbor" language in their disclosure policies — Safeguard's own included — stating that good-faith testing within scope won't trigger legal action. The EU's NIS2 Directive, which member states had to transpose into national law by October 17, 2024, similarly pushes toward standardized coordinated vulnerability disclosure (CVD) processes and safe-harbor expectations across critical-infrastructure sectors.
What Should a Responsible Disclosure Report Actually Contain?
A usable report contains a reproducible proof of concept, the affected version and configuration, and an assessed severity — not just a description of the bug. CERT/CC's own vulnerability reporting form (VRF) asks specifically for affected product/version, attack vector, and any existing CVE or advisory reference, because vague reports are the single biggest cause of vendor triage delays. CVSS scoring (currently version 4.0, published November 2023) gives both sides a shared severity language, which matters when a vendor is deciding whether a fix ships in the next scheduled release or as an out-of-band emergency patch — the distinction that separated Heartbleed (CVE-2014-0160, patched same-day given its severity) from lower-severity findings that vendors legitimately bundle into quarterly release trains.
How Safeguard Helps
Safeguard turns disclosed CVEs into prioritized, actionable work instead of another line item in a spreadsheet. Reachability analysis determines whether a newly disclosed vulnerability — say, one still inside its 45- or 90-day embargo — is actually exercised by your application's call paths, so teams aren't racing to patch code that's never invoked. Griffin AI cross-references incoming disclosures against your live SBOM inventory (generated automatically or ingested from existing CycloneDX/SPDX feeds) to flag exposure the moment a CVE goes public, and can open an auto-fix pull request with the vendor-recommended patched version already applied. That combination lets security teams respond within a coordinated disclosure's remaining window rather than discovering exposure after the deadline has already passed.