A vulnerability disclosure program (VDP) is a published policy and intake channel that tells security researchers exactly how to report a flaw in your software, and what happens after they do. It typically specifies scope (which domains, apps, or repos are fair game), a safe-harbor legal promise not to sue good-faith reporters, an intake method (a security.txt file, a form, or a platform like HackerOne or Bugcrowd), and target response times. Unlike a bug bounty, a VDP doesn't have to pay cash — it just has to exist and work. The U.S. government made this concrete in September 2020, when CISA's Binding Operational Directive 20-01 gave every federal civilian agency 180 days to stand up a public VDP. Five years later, VDPs are table stakes: Log4Shell (CVE-2021-44228), the MOVEit breach (CVE-2023-34362), and countless smaller incidents have shown what happens when there's no clear front door for someone who finds a hole in your code.
What is a vulnerability disclosure program, exactly?
A VDP is a documented process for accepting, triaging, and acting on external vulnerability reports — it is a policy, not a marketing page. At minimum it answers four questions a researcher has before they email you: what can I test, how do I report it, will you sue me, and when will I hear back. ISO/IEC 29147:2018 formalizes the researcher-facing half of this (how disclosure should work), while ISO/IEC 30111:2019 covers the vendor-side handling process (triage, remediation, notification). A conforming VDP usually publishes a security.txt file at /.well-known/security.txt (per RFC 9116, finalized in April 2022) pointing to a policy URL, a PGP key, and a contact address — a five-minute engineering task that many companies still skip. Without it, researchers default to public GitHub issues, Twitter/X threads, or reporters, which is how private vulnerabilities become public incidents.
How is a VDP different from a bug bounty program?
A VDP is the legal and procedural foundation; a bug bounty is an optional financial incentive layered on top of it. Every bug bounty program needs a VDP underneath it — you can't pay someone for a report if you haven't defined scope, safe harbor, and intake — but plenty of organizations run a VDP with zero payouts, offering swag, public credit, or nothing at all beyond "thank you." HackerOne's platform data shows the split clearly: as of its 2023 Hacker-Powered Security Report, the platform had paid out over $300 million in cumulative bounties since 2012, but it also hosts thousands of VDPs (including the U.S. Department of Defense's "Hack the Pentagon," running continuously since 2016) that pay nothing. The DoD program alone resolved over 45,000 vulnerability reports in its first eight years without every one carrying a bounty. If budget is the blocker to starting, it isn't a valid excuse — a no-bounty VDP still closes the gap between "someone found a bug" and "someone told no one."
What should a vulnerability disclosure policy actually contain?
A usable disclosure policy states scope, safe harbor, submission method, and response-time commitments in language a non-lawyer researcher can act on in under two minutes. Concretely, that means: (1) a scope list naming in-scope domains/apps and explicitly excluding out-of-scope assets like third-party vendors; (2) a safe-harbor clause committing not to pursue legal action under the CFAA or DMCA §1201 for good-faith testing within scope — language the U.S. Department of Justice explicitly encouraged in its May 2022 CFAA charging policy revision; (3) an intake channel, ideally security@yourcompany.com plus a structured form, monitored by a real human; (4) target SLAs, commonly 24-48 hours for initial acknowledgment and 90 days for remediation before public disclosure (the model Google Project Zero has used since 2015); and (5) a disclosure timeline stating whether and when the researcher may publish. Policies missing safe harbor are the single most common reason researchers report anonymously through third parties instead of directly to the vendor.
What laws and standards actually require a VDP?
Three regimes now push VDPs from "nice to have" to compliance requirement, each with a different trigger date. CISA BOD 20-01 (September 2020) mandated VDPs for U.S. federal agencies within 180 days. The EU's Cyber Resilience Act, which entered into force in December 2024 with core obligations phasing in through December 2027, requires manufacturers of "products with digital elements" to establish a coordinated vulnerability disclosure process and to report actively exploited vulnerabilities to ENISA within 24 hours of awareness. PCI DSS v4.0, mandatory for all assessments since March 31, 2025, references a documented vulnerability management process under Requirement 6 that assessors increasingly interpret to include external reporting channels. None of these regimes mandate a bounty budget — they mandate the policy and the process, which is exactly what a VDP is.
How do you know if a VDP is actually working?
A working VDP is measured by time-to-triage and time-to-fix, not by report volume. Industry benchmarks from HackerOne's 2023 report put median time to first response at under 24 hours for top-performing programs and median time to resolution around 20-30 days for high-severity findings; programs that take weeks to acknowledge a report see researchers escalate to public disclosure far more often. Track three numbers monthly: mean time to acknowledge (target: under 48 hours), mean time to remediate by severity (critical findings inside 15 days is a reasonable internal SLA), and percentage of reports that go stale — unanswered past 30 days — which should trend toward zero. A VDP with a beautiful policy page and a 40-day average acknowledgment time is not a functioning program; it's a legal document nobody operationalized.
What happens to organizations that skip a VDP?
Organizations without a VDP find out about their vulnerabilities from attackers, journalists, or Twitter instead of researchers, usually with less lead time to fix anything. Log4Shell is the textbook case: the flaw (CVE-2021-44228) was disclosed to the Apache Software Foundation on November 24, 2021, patched by December 9, 2021, and mass-exploited within hours of the patch's release because so many downstream consumers had no internal process to even learn a fix existed, let alone deploy it. On the flip side, coordinated disclosure under a real VDP is why most CVEs never make headlines: MITRE assigned over 40,000 CVEs in 2024 alone, and the overwhelming majority followed a private researcher-to-vendor-to-patch pipeline that the public never saw. The absence of a VDP doesn't reduce vulnerability reports — it just routes them somewhere less controlled: a bounty hunter with no safe harbor who posts a proof-of-concept publicly instead of waiting for a fix.
How Safeguard Helps
Running a VDP well means turning inbound reports into fixes faster than attackers can weaponize the same finding, and that's where reachability analysis matters most: Safeguard tells you whether a reported vulnerability sits in code your application actually executes, so triage time drops from days to minutes instead of manually tracing call paths. Griffin AI, Safeguard's security agent, correlates incoming disclosure reports against your live SBOM inventory to confirm affected versions and exploitability in context, cutting out the guesswork that stalls VDP response SLAs. Safeguard's SBOM generation and ingest pipeline gives your security team a real-time, queryable map of every dependency across every repo, so when a researcher reports a CVE, you know in seconds — not after a manual audit — which services are exposed. And once a fix path is confirmed, Safeguard's auto-fix PRs open the remediation directly against the affected repo, shrinking the gap between "acknowledged" and "resolved" that most VDP metrics are built around.