# disclose.io URL: https://disclose.io/ Description: We're here to make vulnerability disclosure safe, simple, and standardized for everyone. -------------------------------------------------------------------------------- ## Contact Us URL: https://disclose.io/contact/ Description: Got questions, suggestions, or want to start a disclose.io project? We’d love to hear from you! Reach out to us at hello@disclose.io. You can also say hello over at the disclose.io Community Discourse — contributors to disclose.io as well as many from the finder, builder, CERT, and facilitator communities are there. -------------------------------------------------------------------------------- ## A brief history of vulnerability disclosure URL: https://disclose.io/history/ Description: Major events in the standardization of vulnerability reporting and disclosure It’s easy to look at the steadily improving relationship between hackers and companies and presume that it has always been this way, but that is far from the truth. This timeline captures some of the major events in the standardization of vulnerability reporting and disclosure, as well as the origins of The disclose.io Project. Got a suggestion for this timeline? Send a pull request! -------------------------------------------------------------------------------- ## Bug Bounty Platforms URL: https://disclose.io/platforms/ Description: A community-powered collection of all known bug bounty platforms, vulnerability disclosure platforms, and crowdsourced security platforms. TLDR: disclose.io maintains a community-curated list of every known bug bounty, vulnerability disclosure, and crowdsourced security platform. Each entry includes the platform's name, primary URL, geographic focus, and disclosure model. The canonical disclose.io database — including both platforms and individual programs — lives at directory.disclose.io. (content lives at external/bug-bounty-platforms/README.md) -------------------------------------------------------------------------------- ## VDP Programs URL: https://disclose.io/programs/ Description: Search vulnerability disclosure and bug bounty programs in our database. TLDR: disclose.io maintains the largest open directory of vulnerability disclosure programs (VDPs) and bug bounty programs on the public internet. Each entry includes the organization, in-scope assets, disclosure policy URL, and any safe-harbor language. The directory is searchable, free to use, and powers downstream tools including lookup.disclose.io. (content lives at the Vultron directory widget embedded on /programs/) -------------------------------------------------------------------------------- ## Security URL: https://disclose.io/security/ Description: disclose.io's own vulnerability disclosure policy — report issues to security@disclose.io. About this policy disclose.io operates under its own framework. The policy below is an instance of the canonical VDP with Coordinated Disclosure Window from dioterms, with our organization and reporting channel filled in. Introduction disclose.io welcomes feedback from security researchers and the general public to help improve our security. If you believe you have discovered a vulnerability, privacy issue, exposed data, or other security issues in any of our assets, we want to hear from you. This policy outlines steps for reporting vulnerabilities to us, what we expect, what you can expect from us. Systems in Scope This policy applies to any digital assets owned, operated, or maintained by disclose.io. Out of Scope Assets or other equipment not owned by parties participating in this policy. Vulnerabilities discovered or suspected in out-of-scope systems should be reported to the appropriate vendor or applicable authority. Our Commitments When working with us, according to this policy, you can expect us to: Respond to your report promptly, and work with you to understand and validate your report; Strive to keep you informed about the progress of a vulnerability as it is processed; Work to remediate discovered vulnerabilities in a timely manner, within our operational constraints; and Extend Safe Harbor for your vulnerability research that is related to this policy. Note that disclose.io does not maintain a Hall of Fame or offer financial compensation for vulnerability reports. Our Expectations In participating in our vulnerability disclosure program in good faith, we ask that you: Play by the rules, including following this policy and any other relevant agreements. If there is any inconsistency between this policy and any other applicable terms, the terms of this policy will prevail; Report any vulnerability you’ve discovered promptly; Avoid violating the privacy of others, disrupting our systems, destroying data, and/or harming user experience; Use only the Official Channels to discuss vulnerability information with us; Provide us a reasonable amount of time (at least 90 days from the initial report) to resolve the issue before you disclose it publicly; Perform testing only on in-scope systems, and respect systems and activities which are out-of-scope; If a vulnerability provides unintended access to data: Limit the amount of data you access to the minimum required for effectively demonstrating a Proof of Concept; and cease testing and submit a report immediately if you encounter any user data during testing, such as Personally Identifiable Information (PII), Personal Healthcare Information (PHI), credit card data, or proprietary information; You should only interact with test accounts you own or with explicit permission from the account holder; and Do not engage in extortion. Official Channels Please report security issues via security@disclose.io, providing all relevant information. The more details you provide, the easier it will be for us to triage and fix the issue. Safe Harbor When conducting vulnerability research, according to this policy, we consider this research conducted under this policy to be: Authorized concerning any applicable anti-hacking laws, and we will not initiate or support legal action against you for accidental, good-faith violations of this policy; Authorized concerning any relevant anti-circumvention laws, and we will not bring a claim against you for circumvention of technology controls; Exempt from restrictions in our Terms of Service (TOS) and/or Acceptable Usage Policy (AUP) that would interfere with conducting security research, and we waive those restrictions on a limited basis; and Lawful, helpful to the overall security of the Internet, and conducted in good faith. You are expected, as always, to comply with all applicable laws. If legal action is initiated by a third party against you and you have complied with this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please submit a report through one of our Official Channels before going any further. Note that the Safe Harbor applies only to legal claims under the control of the organization participating in this policy, and that the policy does not bind independent third parties. -------------------------------------------------------------------------------- ## Thanks URL: https://disclose.io/thanks/ Description: We've received your message Thanks! We’ve received your message and will respond as soon as possible. In the meantime, why not sign up and say hello over at The disclose.io Discourse? Many of the contributors to disclose.io as well as many from the finder, defender, and facilitator communities are there - It’s another great place to ask questions, get assistance, and contribute back! -------------------------------------------------------------------------------- ## Research Threats URL: https://disclose.io/threats/ Description: An ongoing archive of legal threats made against security researchers engaged in good-faith vulnerability disclosure. TLDR: disclose.io maintains the canonical public archive of legal threats made against security researchers engaged in good-faith vulnerability disclosure. Each entry records the date, the organization that made the threat, the researcher(s) targeted, the topic, and the eventual outcome. The archive is open-source at github.com/disclose/research-threats and is updated as incidents are reported and verified. (content lives at external/research-threats/README.md) -------------------------------------------------------------------------------- ## Tools URL: https://disclose.io/tools/ Description: Free, open-source tools from the disclose.io project — for organizations launching a VDP, for researchers finding the right contact, and for everyone working to make vulnerability disclosure simpler. TLDR: disclose.io maintains four free, open-source tools that cover the full disclosure lifecycle: Policymaker generates VDP policy text from canonical templates, Directory and Lookup help anyone find the right disclosure contact for any asset, and Vault cryptographically enforces disclosure deadlines so a committed timeline cannot be reversed. The disclose.io project ships four tools — each free, each open-source, each addressing a specific friction in the vulnerability disclosure pipeline. Policymaker policymaker.disclose.io — Interactive policy generator Generates a customized vulnerability disclosure policy (VDP) for any organization using the canonical legal terms from the disclose.io Framework. Pick a maturity level, fill in the organization name and contact channel, and walk away with safe-harbor language, a security.txt file, and a complete disclose.io-compliant policy. Directory directory.disclose.io — The open VDP and bug bounty programs database Browse every known vulnerability disclosure and bug bounty program. Each entry includes the organization, in-scope assets, policy URL, and any safe-harbor language. Open-source, community-curated, and the data source behind the Lookup attribution tool. Lookup lookup.disclose.io — Security contact attribution Turn any input — domain, IP, URL, email, ASN, npm package, mobile app, hardware product, free-text company name — into the right disclosure contact. The tool chains 11 attribution strategies (security.txt, the Directory, WHOIS, DNS SOA, common security@ aliases, bug bounty platform records, and more) and returns the highest-confidence contact with provenance. Available as a web UI, HTTP API, and MCP server. Vault vault.disclose.io — Cryptographically enforced disclosure deadlines A dead-man’s-switch for vulnerability disclosure. A researcher commits a disclosure with a future publication date; the disclosure is encrypted with a timelock that cannot be bypassed, even by the operators of the vault. On expiry, the disclosure becomes publicly readable — regardless of what happens to anyone involved. Browser extension Chrome extension (also referenced as the Disclose extension) Surfaces the disclose.io directory’s VDP posture for any site you visit — see at a glance whether the organization has a published VDP, what their safe-harbor language is, and where to report a vulnerability. Browse the source Every tool is open-source under the github.com/disclose organization. Contributions, issue reports, and policy improvements all welcome. -------------------------------------------------------------------------------- ## The disclose.io Universe URL: https://disclose.io/universe/ Description: The open standard for safe harbor vulnerability disclosure — and the ecosystem that makes it real. The disclose.io project is the open-source layer between raw standards (ISO 29147, CISA CVD) and commercial platforms — a vendor-agnostic, practitioner-first playbook for coordinated vulnerability disclosure. Below is the full ecosystem. Every component answers a real question someone asks when they hit the VDP wall. The ecosystem, organised around the DIOstatus maturity scale. Core disclose.io — the framework, docs, and project home directory.disclose.io — the canonical disclose.io database of programs and platforms disclose.io/programs — curated programs with safe harbor language disclose.io/platforms — bug bounty platforms supporting safe harbor disclose.io/threats — research on legal threats to security researchers disclose.io/history — 20+ years of coordinated disclosure Tools lookup.disclose.io — vendor → security contact, program, and safe harbor status dnssecuritytxt.org — DNS-based security contact discovery Community community.disclose.io — the forum blog.disclose.io — updates, commentary, and research Open source dioterms — safe harbor policy templates diodb — open database of disclosure programs policymaker.disclose.io — guided VDP policy generator Legal backstop SRLDF — Security Research Legal Defense Fund Contribute, ask questions, or start a program: hello@disclose.io. -------------------------------------------------------------------------------- ## What is disclose.io URL: https://disclose.io/docs/what-is-disclose.io/ Description: A cross-industry, vendor-agnostic standardization project for safe harbor best practices. Disclose.io is a cross-industry, vendor-agnostic standardization project for safe harbor best practices to enable good-faith security research. We provide free, open-source tools and data to help establish and improve vulnerability disclosure programs and an easily recognizable seal for those taking part in “Neighbourhood Watch for the Internet.” Powered by experts With the help of expert maintainers and by harnessing the power of open-source, disclose.io provides: Free boilerplate policies, tools, contact lists, and data-sets; A straight-forward maturity model with recognition of all levels of best practice adoption, and Centralized assistance, information, activism, advocacy for security researchers and those wanting to report security issues. -------------------------------------------------------------------------------- ## Vision and Mission URL: https://disclose.io/docs/vision-and-mission/ Description: Our vision for a healthy Internet Immune System. Vision A healthy and ubiquitous Internet Immune System enabled by security research, reporting, and disclosure. Mission To standardize and promote Neighborhood Watch for the Internet. -------------------------------------------------------------------------------- ## Design Strategy URL: https://disclose.io/docs/design-strategy/ Description: Our design principles for making secure easy and insecure obvious. Vulnerability reporting is tricky by nature - Every security issue is a snowflake, and the laws, languages, and people involved are unique every single time. To compensate for this and help to make secure easy, and insecure (or bad practice) obvious, disclose.io focusses on these design principles: Legal completeness Simplicity Accessibility Universally recognizable Be useful & safe for security researchers while keeping legal teams happy. Help set clear expectations for security researchers & program owners alike. Easy to understand and hard to misinterpret, for as many people as possible. The Green Padlock for Vulnerability Disclosure. -------------------------------------------------------------------------------- ## Key Objectives URL: https://disclose.io/docs/key-objectives/ Description: The key objectives driving the disclose.io project. Key objectives Create a vibrant community that blends security researchers, policymakers, lawyers, and technology vendors to foster collaboration, and creates high-quality tools and data that support a virtuous cycle. Help organizations promote adoption and excellence to their customers, industry peers, and the security community. Maintain a vulnerability disclosure policy maturity model and create a “race to the top” for VDP adoption and the implementation of best practice. Be the system of record for the Disclose.io Status of a policy, provide easy mechanisms for anyone to lookup a target/organization, or to update their status. Drive the state of the art in thinking around legal risks faced for security researchers and the steps organizations can take to reduce them. Make tools and techniques freely available to technology vendors to ease the socialization and adoption of VDP. -------------------------------------------------------------------------------- ## For Finders and Hackers URL: https://disclose.io/docs/for-finders-and-hackers/ Description: How disclose.io helps security researchers and finders. As a finder… …who has discovered a security issue, I need help to understand where I should report my findings in a way that balances my own legal safety with my confidence in the issue actually being addressed. …who is a part of the security community, I want to help my peers solve these problems in the same way I want them to be solved for myself. As a security researcher… …who wants to conduct research, I need to know where I can apply my proactive security research skills without fear of legal recourse. …who has discovered a security issue, I need help to understand where I should report the issue, and whether or not I can feel safe doing so. …who is looking for organizations who value my skills and help, I want to be able to find them and be confident that what they tell me is an accurate reflection of their position as an organization. -------------------------------------------------------------------------------- ## For Organizations and Legal Teams URL: https://disclose.io/docs/for-organizations-and-legal-teams/ Description: How disclose.io helps organizations and their legal teams. As an organization… …who is considering starting a VDP, I want confidence in the fact that this is best practice, and not an overly aggressive risk. …who is running a VDP, I want to be able to clearly show my security maturity to my customers, competitors, and any others interested to know. …who is pursuing security maturity, I need a reference to point to in order to explain and validate what progressive security maturity means to an organization like mine. As a legal team… …who has never considered the idea of inviting hacker input before, we need to understand where successful precedent exists around how to structure terms and conditions. …who is seeking to improve the simplicity and utility of VDP language, we want to be able to refer to the consensus of experts to support our point of view. …who is time poor, we want access to free policy boilerplates that have the power of market and legal consensus behind them. How disclose.io can help Note: While this project engages the legal opinion of many, it does not constitute legal advice. Please consult your legal counsel for the specific suitability of the disclose.io terms in your organization. Whether you’re starting from scratch or updating an existing policy, choose the legal terms that best fit your vulnerability disclosure program (VDP) or bug bounty program (BBP). Publish your new policy, or add the safe harbor terms to your existing VDP or BBP policy. Submit a pull request to add your program to the open-source disclose.io program database. The diodb maintainers will confirm details, validate your disclose.io status, and merge your request. Select the appropriate disclose.io Seal based on your Disclose.io Status. Add the seal to your security page, vulnerability policy or reporting page, checkout page, and whatever else you like and let the world know you’re joining the mission! -------------------------------------------------------------------------------- ## Contributors URL: https://disclose.io/docs/open-source-contributors/ Description: The people behind disclose.io — legends, maintainers, and open-source contributors keeping the Internet safer. disclose.io is open-source, not-for-profit, and volunteer-run. Diversity is what powers our mission, both today and into the future. Internet superheroes Some of the legends working on disclose.io who eat, sleep, and breathe making the Internet safer. Founding Members Casey Ellis @caseyjohnellis Amit Elazari @amitelazari Chloé Messdaghi @chloemessdaghi Maintainers Jack Cable @cablej Harley Geiger @harleygeiger FJ Fred Jennings esquiring Beau Woods @beauwoods Jeremy Manoto @jmanoto Andrew MacPherson @andrewmohawk sick.codes @sickcodes Contributors Daniel Trauner @dantrauner JE Jen Ellis infosecjen Jason Haddix @jhaddix Lisa @its-a-lisa M Max   Luke Stephens @hakluke J Jonathan   Maeesha Lohani @0ddInput Open-source Contributors Folks who have shipped meaningful commits across the disclose.io GitHub org. Thank you. Michael Skelton @codingo Sajeeb Lohani @prodigysml Nikita Stupin @nikitastupin Jeff Boothby @jeffboothby David Chou @bcdavidchou Luiz K. Monteiro @adiffpirate Abhinav Prasad @abhinavprasad47 Khaled Mohamed @xElkomy Famo @dradford Jericho @attritionorg gi-el @gi-el How you can contribute Here are some of the ways you can contribute back: Keeping diodb up-to-date Help us maintain diodb as the most comprehensive source of truth. Send us changes or additions to VDPs and bug bounty programs via PR to our Github repo. Help us translate policies Is your country or native language missing? Translate the dioterms Core Terms into your local language, or contextualize the safe harbor terms to suit your local laws. Join the community Sign up to The disclose.io Community, introduce yourself, share research, coordinate policy activism and responses, collaborate with other hackers, and help finders connect with security teams. Spread the word Working with an organization that doesn’t have an established VDP or lacks safe harbor provisions? Point them towards the disclose.io website and encourage them to join the movement. -------------------------------------------------------------------------------- ## Project Directory URL: https://disclose.io/docs/project-directory/ Description: The full ecosystem of disclose.io projects — standards, tools, data, and community resources for vulnerability disclosure. disclose.io maintains an ecosystem of open-source projects that work together to make vulnerability disclosure safer and more accessible. Standards provide the legal and policy foundation, tools make adoption easy, data tracks progress across the internet, and community resources connect the people doing the work. Everything below is free, open-source, and community-maintained. Standards and Templates The policy and legal building blocks that underpin everything else. dioterms — VDP Policy Templates The core set of boilerplate vulnerability disclosure policy templates. Available in multiple languages and adapted for specific geographies, verticals, and regulatory frameworks. These templates are what the Policymaker tool generates from. Repository dnssecuritytxt — DNS Security TXT A proposed standard for publishing security contact and vulnerability disclosure information via DNS TXT records — extending the security.txt concept to organizations and assets where web-based paths aren’t available. Repository diostatus — The Maturity Model and Seal A five-level maturity model for vulnerability disclosure programs, from “no contact” to “full safe harbor with coordinated disclosure.” The disclose.io seal provides a recognizable mark indicating an organization’s level of best-practice adoption. See the full maturity model documentation. Repository Tools Free tools that put the standards into practice. Policymaker A multi-lingual, guided VDP policy generator. Answer a few questions about your organization and get a ready-to-publish vulnerability disclosure policy, safe harbor language, and security.txt — all based on the dioterms templates. policymaker.disclose.io | Repository lookup.disclose.io A security attribution and contact lookup tool. Given a domain, IP, package name, or other identifier, find the right place to report a vulnerability — pulling from security.txt, DNS, WHOIS, bug bounty platforms, and the disclose.io database. lookup.disclose.io diosts — Security.txt Scanner A Go-based scanner that validates security.txt files at internet scale. Powers the data behind the disclose.io VDP adoption surveys. Repository Data and Research Tracking adoption, documenting threats, and building the evidence base for policy work. diodb — The VDP/BBP Database The definitive community-powered database of every known vulnerability disclosure program and public bug bounty program, along with their disclose.io maturity status. The most active project in the ecosystem — contributions welcome via pull request. Repository data.disclose.io — VDP Adoption Survey Internet-wide survey data on vulnerability disclosure program adoption, generated from diosts scans and community contributions. Used by researchers, policymakers, and organizations for tracking industry progress. data.disclose.io (currently offline) research-threats — Legal Threats Archive A structured archive of legal threats, cease-and-desist letters, and prosecutions targeting good-faith security researchers. Documents the chilling effect and provides evidence for policy advocacy. Repository Community and Content Where the people are. The disclose.io Community A forum for security researchers, program owners, and policy advocates. Get help with disclosure, find security contacts via Hacker Connect, and coordinate on policy responses. community.disclose.io The Blog and PolicyPulse Newsletter News, analysis, and the weekly PolicyPulse newsletter covering cybersecurity policy developments relevant to vulnerability disclosure. blog.disclose.io This Website The documentation site you’re reading now. Also open-source. Repository Get Involved disclose.io is open-source, not-for-profit, and volunteer-run. See Open-source Contributors for ways to help, or Join a Project to get started. -------------------------------------------------------------------------------- ## Join a Project URL: https://disclose.io/docs/join-a-project/ Description: How to get involved with disclose.io projects. If you’d like to work on any of the disclose.io projects and join our community, we’d love your help! Contact us to get started. -------------------------------------------------------------------------------- ## The disclose.io Community URL: https://disclose.io/docs/the-disclose.io-community/ Description: Join our community Discourse forum. Disclose.io Community Our Discourse at https://community.disclose.io is for sharing research, coordinating policy activism and responses, collaborating with other hackers, and helping finders connect with security teams. Sign up and introduce yourself! -------------------------------------------------------------------------------- ## Advocacy and Activism URL: https://disclose.io/docs/advocacy-and-activism/ Description: Public policy work and open letters from disclose.io. advocacy /ˈadvəkəsi/ (noun): public support for or recommendation of a particular cause or policy. activism /ˈaktɪvɪz(ə)m/ (noun): the policy or action of using vigorous campaigning to bring about political or social change. Open Letters and Statements Following is a collection of letters and statements that disclose.io and/or its members have either co-authored or joined as a signatory, in reverse chronological order: Comments on NIST Cyber AI Profile (February 2026) — Joint Cybersecurity Coalition and Hacking Policy Council comments on NIST’s Cybersecurity AI Community Profile, recommending lifecycle-based AI risk management and recognition of red teaming and bug bounty programs for AI systems. Comments on EU CRA Delegated Act on Delaying Incident Notifications (December 2025) — Joint Cybersecurity Coalition and HPC comments urging the European Commission to make the 72-hour timeframe for mitigation measures more flexible. Letter in Support for Reauthorization of the Cybersecurity Information Sharing Act of 2015 (July 2025) — HPC letter to Congress urging reauthorization of CISA 2015 before its expiration. Comments on the Development of an AI Action Plan (March 2025) — HPC comments to the White House on AI security testing and vulnerability disclosure as part of the national AI Action Plan. Resource on Vulnerability Management under the EU Cyber Resilience Act (October 2024) — HPC guidance on vulnerability management obligations under the EU CRA framework. Comments to CISA on Cyber Incident Reporting for Critical Infrastructure (CIRCIA) (July 2024) — HPC comments on how incident reporting requirements interact with security research and vulnerability disclosure. Reply Comments for DMCA Section 1201 Exemption for Generative AI Research (March 2024) — HPC reply comments in the Ninth Triennial Proceeding. The Copyright Office subsequently clarified that prompt injection, jailbreaking, and rate limit bypass do not violate DMCA Section 1201. Joint Letter of Experts on CRA and Vulnerability Disclosure (October 2023) — Open letter signed by 50+ cybersecurity experts opposing the EU CRA’s Article 11 requirement for 24-hour disclosure of actively exploited unpatched vulnerabilities. AI Red Teaming: Recommendations for Legal Clarity and Liability Protections (December 2023) — HPC recommendations establishing that AI red teaming needs legal safe harbors similar to those for traditional security research. Position Statement on State Charging Policies for Security Researchers (August 2023) — HPC statement addressing the risk that state prosecutors can pursue CFAA-style cases that federal prosecutors would decline, calling for reform of state-level charging policies. Joint Letter to OFAC re Vulnerability Guidance (May 2023) — HPC letter requesting OFAC clarify that receiving vulnerability disclosures from individuals in sanctioned countries is not restricted under sanctions. Security Researcher Statement on the DMCA (June 2021) — EFF statement on DMCA exemptions for good-faith security research, co-signed by disclose.io and others. Calling for Cybersecurity in Critical Infrastructure Modernization (May 2021) — Coalition letter urging Congress and the Biden Administration to integrate cybersecurity requirements into infrastructure modernization legislation. An Open Letter on Election Security (November 2020) — Open letter alongside the EFF, Bugcrowd, the Centre for Democracy and Technology, Verified Voting, and others. Open Letter to Columbus City Attorney Zach Klein — Regarding the prosecution of a security researcher who reported vulnerabilities in city election systems. Response to Voatz — Addressing Voatz’s claims about security researchers who identified vulnerabilities in their mobile voting application. Hacking Policy Council In April 2023, disclose.io members helped launch the Hacking Policy Council (HPC) at the Center for Cybersecurity Policy and Law. The HPC brings together Bugcrowd, Google, HackerOne, Intel, Intigriti, LutaSecurity, Microsoft, and Trend Micro to advance policy protections for good-faith security research. Since its founding, the HPC has published 35+ formal comments, position statements, and policy resources spanning NIST, CISA, the U.S. Copyright Office, UK DSIT, the EU Cyber Resilience Act, the Pall Mall Process, and more. The complete archive is available on the Hacking Policy Council page. -------------------------------------------------------------------------------- ## Press Mentions URL: https://disclose.io/docs/press-mentions/ Description: Media coverage and press mentions of disclose.io. Date Type Publication Author Title 1/2026 Reference IoT Security Foundation Copper Horse / IoTSF The State of VDP Usage in Global Consumer IoT in 2025 3/6/2025 Partner Reference Intigriti Intigriti Safe harbor legal framework for ethical hackers officially launches in Belgium 12/11/2023 Press Dark Reading Staff Safe Harbor Programs: Ensuring the Bounty Isn’t on White Hat Hackers’ Heads 12/13/2023 Op-Ed Dark Reading Casey Ellis The Unlikely Romance of Hackers and Government Suitors 4/2023 Press TechTarget Staff Hacking Policy Council launches, aims to improve bug disclosure 4/2023 Reference Center for Cybersecurity Policy Staff Center for Cybersecurity Policy and Law Launches Initiatives To Support Detection and Remediation of Security Vulnerabilities 4/5/2023 Academic Duke FinReg Blog Staff Security Researchers Battle Against The DMCA 2023 Podcast Delinea Joseph Carson 401 Access Denied Ep 94: Crowdsourced Security & Vulnerability Disclosure with Casey Ellis 2022 Press The Daily Swig Staff HackerOne encourages customers to adopt standard policy to protect hackers from legal problems Summer 2022 Reference NASS / Ingalls Ingalls Information Security disclose.io Managing Disclosure of Vulnerabilities and Risk 6/2021 Signatory EFF EFF Standing With Security Researchers Against Misuse of the DMCA 6/2021 Press SecurityWeek Staff Cybersecurity Companies Join Forces Against Controversial DMCA Section 6/2021 Press The Daily Swig Staff Security organizations join forces with EFF to lobby for DMCA reform 6/23/2021 Partner Reference Bishop Fox Bishop Fox Our Position on the Digital Millennium Copyright Act (DMCA) 6/23/2021 Partner Reference Rapid7 Rapid7 Rapid7 Joins Statement On DMCA Lawsuits Against Security Tools 6/23/2021 Partner Reference NCC Group NCC Group NCC Group co-signs the EFF’s Statement on DMCA Use Against Security Researchers 3/9/2021 Reference NASS NASS Coordinated Vulnerability Disclosure Issue Briefing 1/21/2021 Press Dataversity Casey Ellis Cyberwarfare, Ethical Hacking, and Ransomware: 2021 Predictions 11/17/2020 Partner Reference Center for Democracy and Technology William T. Adler CDT Joins EFF, Other Experts in Open Letter on Election Security 11/16/2020 Reference EFF EFF Elections Are Partisan Affairs. Election Security Isn’t. 11/7/2020 Partner Reference AWS AWS Disclose.io adoption 10/28/2020 Press Threatpost Lindsey O’Donnell How the Pandemic is Reshaping the Bug-Bounty Landscape 10/23/2020 Press VentureBeat Chris O’Brien How ethical hackers are trying to protect the 2020 U.S. elections 9/2020 Reference CISA CISA BOD 20-01: Develop and Publish a Vulnerability Disclosure Policy 2020 Press The Hill Staff Voting equipment companies throw weight behind enhanced disclosures 2020 Press CyberScoop Staff Top voting vendor ES&S publishes vulnerability disclosure policy 2020-2025 Reference IoT Security Foundation IoT Security Foundation The State of Vulnerability Disclosure Policy Usage in Global Consumer IoT (Annual Reports) 7/11/2019 Partner Reference Kaspersky Kaspersky Team Building trust together with Disclose.io 5/31/2019 Press TechCrunch Zack Whittaker Security startup Bugcrowd on crowdsourcing bug bounties 5/2/2019 Partner Reference Bugcrowd Jason Haddix Disclose.io - The Movement Marches Forward 1/29/2019 Press Total Security Advisor Staff Open Source Collaborative Hopes to Make Reporting Security Bugs Safer for All 12/3/2018 Partner Reference Bugcrowd Jason Haddix Protecting Hackers (by default) with Disclose.io 11/6/2018 Press The Daily Swig Staff Open source Disclose.io framework bridges legal gap in bug reporting 9/5/2018 Press Threatpost Tom Spring The Vulnerability Disclosure Process: Still Broken 8/9/2018 Press CSO Online J.M. Porup Bug bounties offer legal safe harbor. Right? Right? 8/7/2018 Press AB Open Gareth Halfacree Disclose.io Aims to Protect Security Researchers 8/6/2018 Press Help Net Security Staff Bugcrowd launches Disclose.io to provide a safe harbor for white hat hackers 8/3/2018 Press Washington Post Derek Hawkins The Cybersecurity 202: The law doesn’t protect ethical hackers. This new project could help close that gap. 8/3/2018 Press CyberScoop Zaid Shoorbajee Open source project looks to give legal safe harbor for ethical hackers 8/2/2018 Press ZDNet Charlie Osborne Disclose.io: A safe harbor for hackers disclosing security vulnerabilities 8/2/2018 Press Linux.com Ars Technica New Open Source Effort: Legal Code to Make Reporting Security Bugs Safer 8/2/2018 Press TechTarget Staff Disclose.io launches vulnerability disclosure ‘safe harbor’ 8/2/2018 Podcast TechTarget Staff Risk & Repeat: Can Disclose.io help protect vulnerability researchers? 8/2/2018 Partner Reference Bugcrowd Amit Elazari Standardizing Legal Safe Harbor for Security Research 8/2/2018 Podcast Threatpost Staff Bugcrowd Founder on Printer Bugs, IoT Bounty Hunting, and New VDP Project 8/2/2018 Press Release GlobeNewswire Bugcrowd Bugcrowd Launches Disclose.io Open-Source Vulnerability Disclosure Framework - Reference OWASP OWASP Vulnerability Disclosure Cheat Sheet - Reference CERT/CC CERT/CC Guide to Coordinated Vulnerability Disclosure - Policy Templates - Reference MIT Election Lab MIT Coordinated Vulnerability Disclosure Research - Partner Reference HackerOne HackerOne Safe Harbor Overview & FAQ - Partner Reference Bugcrowd Bugcrowd Disclose.io and Safe Harbor - Reference Wikitia Wikitia Disclose.io -------------------------------------------------------------------------------- ## Conference Talks and Videos URL: https://disclose.io/docs/conference-talks-and-videos/ Description: Talks and presentations about disclose.io and vulnerability disclosure. Featured Talks More Videos Hacking Policy and Policy Hacking — Amit Elazari, BSidesSF 2023 The State of Vulnerability Disclosure The State of Bug Bounties & AMA — Casey Ellis, Bugcrowd LevelUp 0x01, 2017 Leonard Bailey + Casey Ellis + Marten Mickos — Cybertalks 2017 Bug Bounty Legal Discussion How bug bounties can impact critical infrastructure — Casey Ellis, Passcode Security of Things Forum, 2016 Vulnerability Disclosure Best Practices How building a better hacker accidentally built a better defender — Casey Ellis, OWASP AppSec California, 2015 The Art & Value of Bug Bounties — Casey Ellis & Keren Elezari, 2015 Safe Harbor for Security Research Policy Panel Discussion Presenting Bugcrowd (Most Innovative Company) — Casey Ellis, LAUNCH Silicon Valley, 2013 -------------------------------------------------------------------------------- ## Legal Disclaimer URL: https://disclose.io/docs/legal-disclaimer/ Description: Important legal information about disclose.io. Disclaimer While we’ve engaged the legal opinion of many, this does not constitute legal advice. Please consult your legal counsel for the specific suitability of the disclose.io terms in your organization. -------------------------------------------------------------------------------- ## Who is disclose.io for? URL: https://disclose.io/faqs/who-is-this-for/ Hackers and Finders: You want to help, and you’re not sure that you’re welcome - We want to help you make safe decisions and connect you to the right people to take action on your input Legal teams: Vulnerability reporting and research is tricky, and inviting the help of hackers is still legally novel territory - We want to make it simple for you to make consensus-backed recommendations Organizations: Vulnerabilities are inherent to innovation, but it still takes guts to say so - We want to help you say so loudly and proudly Security Researchers: You’ve been waiting for the red carpet - We’ll help you find it -------------------------------------------------------------------------------- ## What is Safe Harbor? URL: https://disclose.io/faqs/safe-harbor/ Most of the existing anti-hacking laws pre-date the notion of hacking for good or widespread knowledge of the “digital locksmiths” who are increasingly influencing modern-day digital safety. These anti-hacking laws have been used by organizations to suppress good-faith security research in the pursuit of limiting negative publicity for the vendor, which nets out to a “chilling effect” on the input from the people the Internet needs to hear from most. If hackers are the Internet’s Immune System, then right now, even in 2026, the Internet still has an auto-immune problem. “Safe Harbor” is the term used to describe clauses added to public policies which allow folks acting in good faith, as defined clearly and proactively by the recipient, to provide security feedback without fear of legal repercussions. disclose.io intends to help define, spread, and reward the adoption of vulnerability disclosure programs with best practices like Safe Harbor. -------------------------------------------------------------------------------- ## How do I interact with or contribute to the disclose.io projects? URL: https://disclose.io/faqs/how-to-interact/ Glad you asked! Start a vulnerability disclosure program (VDP), or upgrade your VDP or bug bounty program to include best practices like Safe Harbor and proactive disclosure timelines Join the community, contribute or assist with vulnerability research, and help finders connect with security teams to alert them of identified risks Help us keep “The Big List” of known VDPs and bug bounty programs up-to-date by submitting a PR to the dioterms repo Contribute to the dioterms open-source vulnerability disclosure policy by raising an issue on the repo… or add a language or regional legal translation by submitting a PR Volunteer as a core contributor/maintainer on one of our existing projects Recommend a new project to support our mission to make vulnerability disclosure safe, simple, and standardized. -------------------------------------------------------------------------------- ## Is disclose.io a 501.c3 (Not For Profit)? URL: https://disclose.io/faqs/not-for-profit/ disclose.io was formed as a merge of separate standardization projects initiated by RainForest Puppy, Bugcrowd, Cipherlaw, Dropbox, Dr. Amit Elazari, UC Berkeley, the National Transport and Information Authority, the US Department of Justice, and others. We’re currently in the process of incorporating and pursuing status as a 501.c3 Not For Profit. -------------------------------------------------------------------------------- ## Is this legal advice? URL: https://disclose.io/faqs/legal-advice/ While we’ve engaged the legal opinion of many, this does not constitute legal advice. Please consult your legal counsel for the specific suitability of the disclose.io terms in your organization. -------------------------------------------------------------------------------- ## Level 0 — Not Present URL: https://disclose.io/framework/maturity/level-0/ Description: No findable contact, no policy, no intake method. The organisation has no findable security contact, no security.txt, no disclosed policy, and no public intake method. A researcher discovering a vulnerability has no safe or sanctioned way to report it. From the ecosystem’s perspective, this organisation is effectively invisible — or worse, implicitly hostile to disclosure. What observers see No /.well-known/security.txt No security@ or equivalent mailbox documented publicly No policy page, no disclosure program, no bug bounty listing No response (or a hostile response) to any informal outreach Researcher protection None. A researcher who finds and reports a vulnerability here is relying on goodwill and has no written protections — legal or procedural — whatsoever. Path to Level 1 Publish a security.txt file at /.well-known/security.txt with at minimum a Contact: line pointing to a monitored mailbox or form. That’s it. You’re now Level 1. -------------------------------------------------------------------------------- ## Accepted Practices for Good-Faith Security Research URL: https://disclose.io/framework/practices/good-faith-security-research/ Description: Operational conduct for good-faith security research, originally published by NextJenSecurity (2026). Aligns with the disclose.io framework. Originally published by NextJenSecurity, 2026. TL;dr Laws and policies that address the security of online systems should support research activities that are undertaken to benefit society by deterring the trespass of online systems and the theft or destruction of data. In reality, however, often this is not the case, and security researchers face enormous personal risk of criminal prosecution or civil litigation. Lawmakers, law enforcement, and systems operators face challenges distinguishing between beneficial, good faith security research and activities conducted with criminal intent, which can result in unwarranted claims being leveled against legitimate security research. This document is designed to help good faith security researchers to navigate this uncertainty and authentically defend their activities as a public good. The Legislative Landscape Malicious cyber activity that extorts, defrauds, steals from, or otherwise intentionally harms victims must be prohibited to protect society. The annual cost of cybercrime on the global economy is estimated in the trillions of dollars, and extensive disruption to critical services such as healthcare, water treatment, education, and food provision has significant impact on safety and quality of life. These threats must be taken seriously and deterred as permitted by the law. Part of defending against these threats is identifying opportunities for malicious actors and understanding the dynamics and dimensions of attacks. This can involve defenders and security researchers undertaking similar activities to those of malicious actors. Such activities serve a public good by identifying and mitigating the technical vulnerabilities and misconfigurations that create opportunities for malicious actors, as well as investigating and documenting the evolving techniques of attackers. While the goal of this legitimate security research is to reduce cyber risk for society, the economy, and national security, it can easily be mistaken as malicious. Security research is critical for increasing the security and resilience of connected systems and mitigating damage or disruption of those systems, yet such research is often hindered by the complex legal landscape surrounding laws governing access to computer systems. So, a challenge lies in helping system owners and law enforcement differentiate between legitimate researchers and malicious actors where their core activities appear the same. How can governments support the work of legitimate researchers without also creating a potential defense for malicious actors? Can researchers adopt practices that will help distinguish between malicious cyber activities and research that is intended to be beneficial? Importantly, some governments are acknowledging this challenge while also recognizing the importance and legitimacy of security research. In May 2022, the U.S. Department of Justice (DoJ) issued guidance to federal prosecutors that they, “Should decline prosecution if available evidence shows the defendant’s conduct consisted of, and the defendant intended, good-faith security research.” The guidance described the characteristics of “good-faith security research” in terms similar to those previously defined and adopted in the Digital Millennium Copyright Act (DMCA) by the Register of Copyrights in Section 1201 Rulemaking: Eighth Triennial Proceeding to Determine Exemptions to the Prohibition on Circumvention, at 258 (Oct. 2021). It states that: "… “good faith security research” means accessing a computer solely for purposes of good-faith testing, investigation, and/or correction of a security flaw or vulnerability, where such activity is carried out in a manner designed to avoid any harm to individuals or the public, and where the information derived from the activity is used primarily to promote the security or safety of the class of devices, machines, or online services to which the accessed computer belongs, or those who use such devices, machines, or online services. Security research not conducted in good faith—for example, for the purpose of discovering security holes in devices, machines, or services in order to extort the owners of such devices, machines, or services—might be called “research,” but is not in good faith." The DMCA is intended to protect copyright owners. Its exemption applies to security research conducted on devices owned by and in the possession of the researcher and conducted in non-production environments. These parameters are fairly clear-cut and easy for researchers, law enforcement, and copyright owners to apply. By contrast, the US’ Computer Fraud and Abuse Act (CFAA - 18 U.S.C. § 1030) addresses accessing computer systems “without authorization” or “exceeding authorized access” placing the activity firmly in murky waters. Under the CFAA, the sometimes nebulous line between authorized and unauthorized conduct, as well as the limitations of such authorization, are central to distinguishing between good faith research and malicious activity. Security researchers are better positioned to operationalize the DoJ guidance by clarifying within the researcher community how legitimate research is conducted. The US is not the only government that has addressed this issue in recognition of the importance of security research. Recital 75 of the European Union’s Cyber Resilience Act (CRA - Regulation (EU) 2024/2847) urges EU Member States “to address, to the extent possible, the challenges faced by vulnerability researchers, including their potential exposure to criminal liability, in accordance with national law.” To date, four EU members - Belgium, Malta, The Netherlands, and Portugal have enacted legislation that codifies the importance of security research and creates protections or carve outs for the related activities, within specific boundaries. These countries are leading the way and we applaud them. More EU member states are currently reviewing their related laws and we hope to see more legislative reform to support security research in the future. If you know of other countries that have implemented legal protections or carve outs for security research, please let us know and we will update our list. As with the US approach, these legal carve outs or protections typically include some parameters for “legitimate activity”; a way of determining that research is indeed conducted in good faith and not for more nefarious purposes. This document is written to broadly align with these parameters. Further Complications As with any document addressing legal considerations, there are of course some caveats… Different Laws in Different Jurisdictions: Your Mileage May Vary It is important to note that while government, law enforcement, and industry attitudes towards good faith security research may be maturing, they are doing so at an uneven rate and with varying outcomes in different jurisdictions. Given the cross-border nature of the internet, the extraterritorial application of some countries’ laws, and the availability of technology products across different markets and jurisdictions, it may be necessary to familiarize yourself with legal considerations in multiple regions and proceed with caution. There’s Nothing Civil about Civil Suits Legal carve outs for security research in those jurisdictions that have them are most likely to address criminal enforcement actions, not civil ones. Many countries have legislation permitting civil lawsuits for unauthorized security research. For example, the DoJ charging guidance described in this document only relates to law enforcement action. It does not address civil actions under section 1030(g) of the CFAA, which states: "(g) Any person who suffers damage or loss by reason of a violation of this section may maintain a civil action against the violator to obtain compensatory damages and injunctive relief or other equitable relief." Nonetheless, while this document primarily focuses on helping researchers meet a standard for protection from criminal prosecution, we hope that following the principles will also defend against civil claims against researchers. Above all, we recommend you document every stage of the research and disclosure process (including interaction with the vendor), and minimize the potential of research activities to cause disruptions or other harms. What is a Researcher? One of the challenges policymakers face around this issue is that it can be hard to draw a clear box around the category of “Researcher”. Formal paid security researcher roles can be hard to come by, and rarely follow a set mold or job description. Many people that regularly and intentionally conduct security research do so in their free time, and what they do with findings, and their expectations of rewards or outcomes will vary. Legislating to cover that is certainly a challenge. Additionally, any research exemption should make provision for incidental or accidental discoverers – sometimes referred to simply as “technology users” – to disclose any valid findings. These users can spam a huge spectrum from professional system administrators to five-year old gamers. Incidental/accidental discoverers cannot be expected to follow standard industry practices or be familiar with the law in this area. However, it is still to the benefit of society for the issue they discover to be disclosed to the technology supplier and users so it can be appropriately mitigated. Law enforcement and policymakers should recognize this need. In the AI of the Beholder AI technologies are evolving rapidly and much has been made of their potential use for vulnerability discovery, verification, exploitation, and patching. The law is yet to catch up with this and it will take time. Regardless of what tooling you are using, the principles detailed in the document apply. Above all, take steps to minimize the risk of causing harm. Automating processes might be seen as being at odds with this goal, particularly if your automation tool of choice is still somewhat untested. Basic Security Research Principles First and foremost, if you are conducting security research, we strongly recommend you familiarize yourself with any relevant anti-hacking and/or disclosure laws applying to the jurisdiction you are in, and that of the headquarters of the company that owns or makes the system/product you are testing. If you are researching security issues related to a regulated sector, there may also be sector-specific regulations of which to be aware. Conducting Vulnerability Discovery Research Activity should be designed to minimize the potential for harm, damage, disruption, or loss of confidentiality, availability, or integrity of company and/or user data. Where possible, test in non-production environments. Where possible, start by familiarizing yourself with any research policies of the technology manufacturer or operator. Some organizations may run bug bounty programs or have vulnerability disclosure policies with clear guidelines for research. Others may have processes for seeking permission to test their systems. You may also need to check licensing agreements. The existence (or lack) of a bug bounty program or permissive policy need not dictate your actions, but it can be a good indicator of how a vendor may respond to research or which systems may be considered more sensitive. This can help you plan how you want to proceed. Researchers should ensure they are adhering to data protection and privacy laws and standards as much as possible. Very minimal data should be accessed, copied, or exfiltrated - only the minimum required to investigate and confirm, demonstrate, and/or mitigate a security flaw or vulnerability. Functionality of the systems being researched, or any systems accessed through them, should not be disrupted, significantly altered, or directly result in downtime resulting in the interruption of the business processes. Changes or additions should not be made to code or any information accessed. Security research is not a defense for stealing information or money, nor for extorting technology manufacturers or users. Nor for exploiting access for any other nefarious activity, such as spying or planting crypto miners. Withholding findings unless payment is made (or even requesting payment before a vulnerability is mitigated) could appear extortionate. If you expect the vendor to pay for research, it is recommended that you stick to vendors that run public bug bounty programs or sign up to participate with private bounty programs. In these instances, you will need to operate within the parameters of those programs. There should be no expectation of other vendors to pay for security research. Conducting Internet-Wide Mass Port Scanning Research Much of the guidance for conducting port scanning research will follow similar lines to those above. In addition, you may want to consider implementing the following: Do not conduct scanning that will or is highly likely to disrupt or impair the operation of a system, even temporarily. Provide a way for people to easily identify where the traffic is coming from and that it is not malicious. This could be a whois lookup that points to a webpage that explains the purpose of the research. A webpage describing the research may include how findings will be used; whether effort is made to specifically identify or conversely pseudonymize IP and domain owners; how long the research is expected to run and how long findings will be kept. Provide an easy way for IP address owners to opt out of participating, and honor such requests. If you plan to limit the time that the request will be honored - which is reasonable given the nature of IP address - it is advisable to state that upfront where you provide details on how to request an opt out. GDPR and other data protection regulations include elements around the right to be forgotten. You may want to provide a way for entities to request that their personally identifiable information (which may include their IP address) can be deleted. Conducting Threat or Forensic Research This section covers research designed to quantify and/or assess the actual real-world impact of active exploitation of an identified vulnerability or abuse of a known weakness. Such research uses free/public services that gather information (ie VT, URL Scan, Censys, etc) Similar to vulnerability research, threat or forensic research should minimize the potential for harm, damage, or disruption to impacted companies and users. In the case of forensic research, one stand out in this area exists around interacting with any artefacts left by an adversary. For example, interacting with a residual webshell could result in triggering unexpected functionality and unintended consequences, or alert the asset’s creator/owner. This kind of research should be approached with considerable caution. As previously stated, researchers should ensure they are adhering to data protection and privacy laws and standards as much as possible. Information collected on potential victims should be limited and anonymized or pseudonymized as far as possible. Whenever it is feasible, researchers should inform any impacted companies or victims prior to sharing their information, even if you believe the information is adequately anonymized. Researchers should respect requests to remove any victim information from reporting. Third party technical assets are often leveraged in attacks and probing them to collect data could create privacy implications for their owners, who may themselves be victims of cybercrime. Research That Does Not Yield Findings Sometimes research does not deliver results. In these situations it is advisable to still follow the guidance above, and to record/document your processes as thoroughly as possible. That way, if any of your actions trigger an investigation, you can show 1) the process you took; 2) the effort made to minimize harm; and 3) the rigor and discipline with which you approached the effort. Disclosing Findings (Reporting and Publishing) Reporting Vulnerabilities to Technology Vendors Findings should be confidentially disclosed as soon as is practical after confirmation of the security issue. Where possible, communicate any vulnerabilities or associated details using the most secure method possible, for example exchanging PGP keys or through a secure portal. Researchers should conduct appropriate research to identify the technology manufacturer or vendor. Initial disclosure should not be made to user/customer organizations. In some cases, you may need to look for a parent company website to find a path for reporting. Any efforts made to contact the vendor should be included in your record of activity to demonstrate good faith. Initial disclosure should be made confidentially either to the technology manufacturer or infrastructure owner, or their designated receiver if applicable, or a relevant government coordinating authority. If you are participating in a bug bounty, follow the guidelines provided by the program manager or vendor. Not every country has a clearly defined government coordinating authority for research disclosures. However, Article 12(1) of the European Union’s NIS2 Directive requires EU Member States to assign a designated Computer Security Incident Response Team (CSIRT) to facilitate the communication between a researcher disclosing a vulnerability and a manufacturer/provider. If additional disclosure is intended (e.g. if you intend to disclose to both the manufacturer and a government coordinating authority, and potentially any additional key stakeholders), a timeline for this disclosure should be provided to both/all parties. To ensure the vulnerability is triaged appropriately, reports must include all technical information and steps required to reproduce your findings. Withholding details at the request of payment could be construed at extortion. If you have a timeline in mind for public disclosure, that should also be provided during your initial disclosures. Otherwise, the timeline should be agreed through coordination with key stakeholders as far as reasonably possible, and prioritizing the security of users. Consider what a realistic timeline for mitigation may be. Setting too short a timeline may seem like an intentional act of bad faith, while agreeing to too long a timeline may result in the vendor dragging their feet or taking evasive action. An appropriate timeline may also vary depending on the complexity of the problem and product, whether coordination with 3rd parties is required, and the reasonable availability of resources for mitigation (big companies likely have more resources than smaller ones!). These factors could be considered, as could standard practices for leading organizations, some of which we have linked to in the resources section of this document. Even if a vulnerability is not very severe, researchers should still consider notifying the vendor. It may not warrant public disclosure, but notifying the vendor gives them a chance to learn from the issue, and hopefully mitigate it in future releases. Public Disclosure of Vulnerability Findings Wait a reasonable amount of time before publicly disclosing any security flaw or vulnerability derived from such activity, taking into consideration the following: (I) the severity of the vulnerability, (II) the difficulty of mitigating the vulnerability, (III) whether all information is needed in the disclosure or details could be held back, (IV) industry best practices, and (IV) the willingness and ability of the owner of the protected computer to mitigate the vulnerability; If sensitive or confidential information was accessed during the research process, this should only be disclosed to the technology owner/operator or information owner/operator, unless it triggers a whistleblower response. Any confidential data accessed should be deleted following disclosure, and this process should be documented by the finder. Public disclosures of vulnerabilities should, where possible, be made in collaboration with the technology manufacturer or operator, and should provide pragmatic and realistic details on severity and mitigations in order to enable affected users to protect themselves. Additional information on the workings of the vulnerability will help the technology and security community learn from your findings and hopefully reduce the prevalence of such vulnerabilities in the future. When providing this detail, consider how best to frame the information to minimize the potential for being accused of arming attackers, while still providing sufficient detail to aid defenders. This is a particularly challenging balance. Evidence of exploitation in the wild will likely accelerate the disclosure timeline. Where possible, this should still be coordinated with the manufacturer in order to reduce confusion and give those affected a clearer path to mitigation. Where vendors are resistant to disclosure or mitigating vulnerabilities, researchers should use their best judgment on when and how to disclose, prioritizing protecting users and minimizing security and safety risk in the manner and tone of disclosure. Working with a vulnerability coordination entity such as a CERT may help with this. Seeking Legal Assistance Should you find yourself subject to legal proceedings resulting from good faith security research activities, we recommend you seek specialist legal counsel as soon as possible. There are some organizations that offer free legal support for qualifying researchers, detailed here. These offerings tend to be country-specific. If you know of free researcher legal services not included below, let us know and we’ll add them. The Electronic Frontier Foundation (EFF) - USA Pwn.Legal - United Kingdom If you are unable to take advantage of free legal counsel and need assistance covering the costs of legal counsel for the defense of good faith security research, check out the Security Research Legal Defense Fund (SRLDF). Additional Reading and Resources Vulnerability Disclosure and Handling Guidances and Policies CERT/CC European Union ISO/IEC 29147: Vulnerability disclosure requirements and recommendations for vendors ISO/IEC 30111: Vulnerability handling processes for vendors JPCERT/CC NCSC Netherlands Luta Security Vulnerability Coordination Maturity Model Project Zero Rapid7 U.S. Department of Homeland Security ZDI Discussions/Campaigns for Shifting Legal Parameters or Practices EFF Coders’ Rights Project The Hacking Policy Council UK CyberUp Campaign Where Are the Red Lines? Towards Ethical Server-Side Scans in Security and Privacy Research, F. Hantke, S. Roth, R. Mrowczynski, C. Utz, B. Stock The Conscience of a Hacker (AKA Hacker’s Manifesto), The Mentor, 1986 Legislative or public policy language for researcher protections Text from the DOJ charging guidance: “The attorney for the government should decline prosecution if available evidence shows the defendant’s conduct consisted of, and the defendant intended, good-faith security research. For purposes of this policy, the attorney for the government should apply the definition of “good-faith security research” recommended by the Register of Copyrights in Section 1201 Rulemaking: Eighth Triennial Proceeding to Determine Exemptions to the Prohibition on Circumvention, at 258 (Oct. 2021). That is: “good faith security research” means accessing a computer solely for purposes of good-faith testing, investigation, and/or correction of a security flaw or vulnerability, where such activity is carried out in a manner designed to avoid any harm to individuals or the public, and where the information derived from the activity is used primarily to promote the security or safety of the class of devices, machines, or online services to which the accessed computer belongs, or those who use such devices, machines, or online services. Security research not conducted in good faith—for example, for the purpose of discovering security holes in devices, machines, or services in order to extort the owners of such devices, machines, or services—might be called “research,” but is not in good faith. CCIPS can consult with prosecutors about specific applications of this factor. Language developed by Harley Geiger as a proposed amendment for the CFAA, again, based on the language in the DMCA exemption: The term “good faith security research” means good faith testing or investigation to detect one or more security flaws or vulnerabilities in software, hardware, or firmware of a protected computer for the purpose of promoting the security or safety of the software, hardware, or firmware. (A) The person carrying out such activity shall (i) carry out such activity in a manner reasonably designed to minimize and avoid unnecessary damage or loss to property or persons; (ii) take reasonable steps, with regard to any information obtained without authorization, to minimize the information the person obtains, retains, and discloses to only that information which the person reasonably believes is directly necessary to test, investigate, or mitigate a security flaw or vulnerability; (iii) take reasonable steps to disclose any security vulnerability derived from such activity to the owner of the protected computer or the Cybersecurity and Infrastructure Security Agency prior to disclosure to any other party (iv) wait a reasonable amount of time before publicly disclosing any security flaw or vulnerability derived from such activity, taking into consideration the following: (I) the severity of the vulnerability, (II) the difficulty of mitigating the vulnerability, (III) industry best practices, and (IV) the willingness and ability of the owner of the protected computer to mitigate the vulnerability; (v) not publicly disclose information obtained without authorization that is (I) a trade secret without the permission of the owner of the trade secret; or (II) the personally identifiable information of another individual, without the permission of that individual; and (vi) does not use a nonpublic security flaw or vulnerability derived from such activity for any primarily commercial purpose prior to disclosing the flaw or vulnerability to the owner of the protected computer or the [government vulnerability coordination body]. (B) For purposes of subsection (A), it is not a public disclosure to disclose a vulnerability or other information derived from good faith security research to the [government vulnerability coordination body]. Research carve-out language in Washington State’s anti hacking law (again, developed by Harley Geiger): (11) “White hat security research” means accessing a data program, service, or system solely for purposes of good faith testing, investigation, identification, and/or correction of a security flaw or vulnerability, where such activity is carried out, and where the information derived from the activity is used, primarily to promote security or safety. (12) “Without authorization” means to knowingly circumvent technological access barriers to a data system in order to obtain information without the express or implied permission of the owner, where such technological access measures are specifically designed to exclude or prevent unauthorized individuals from obtaining such information, but does not include white hat security research or circumventing a technological measure that does not effectively control access to a computer. The term “without the express or implied permission” does not include access in violation of a duty, agreement, or contractual obligation, such as an acceptable use policy or terms of service agreement, with an internet service provider, internet website, or employer. The term “circumvent technological access barriers” may include unauthorized elevation of privileges, such as allowing a normal user to execute code as administrator, or allowing a remote person without any privileges to run code. Relevant translated text from Portugal’s security research safe harbor: Article 7 Addition to Law 109/2009 of 15 September Article 8-A is added to the Cybercrime Law, approved by Law 109/2009 of 15 September, in its current wording, with the following text: Article 8-A Acts not punishable due to public interest in cybersecurity 1 — Acts that could constitute the crimes of unlawful access and unlawful interception, as set out in articles 6 and 7 respectively, are not punishable if all of the following circumstances are cumulatively met: a) The individual acts with the sole intention of identifying vulnerabilities in an information system or in information and communication technology products or services, which were not created by them or by any third party on whom they depend, and with the purpose of contributing to cyberspace security through their disclosure. b) The individual does not act with the intention of obtaining an economic advantage or a promise of economic advantage arising from their action, without prejudice to any remuneration received as compensation for their professional activity. c) The individual immediately reports any vulnerabilities identified to the owner or to the person designated by the owner to manage the information system, product, or information and communication technology service, as well as to the holder of any data obtained that is protected under applicable personal data protection legislation, namely the General Data Protection Regulation (GDPR), approved by Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016, Law 26/2016 of 22 August (as amended), Law 58/2019 of 8 August, and Law 59/2019 of 8 August. d) The individual’s actions are proportionate to their purposes and strictly limited to them, consisting only of what is necessary to identify the vulnerabilities and not causing: i) Any disruption or interruption of the system or service; ii) The deletion or deterioration of computer data or its unauthorized copying; iii) Any harmful or adverse effect on the person or entity affected, directly or indirectly, or on any third parties, excluding effects inherent to the unlawful access or unlawful interception itself, as defined in articles 6 and 7, as well as effects that would, with high probability, already result from the vulnerability detected or its exploitation. e) The individual’s actions do not constitute a violation of personal data protected under applicable personal data protection legislation, namely Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016, Law 58/2019 of 8 August, and Law 59/2019 of 8 August. 2 — The notification referred to in point c) above must also be made to the national cybersecurity authority, which shall forward it to the Polícia Judiciária whenever it may have criminal relevance. 3 — When assessing whether the individual acted proportionately, consideration must be given to whether the action was necessary to detect the vulnerability and whether the scope of systems or data accessed, viewed, and/or copied was strictly required by the aim of contributing to cyberspace security. The following practices are expressly prohibited: a) Denial of service (DoS) or distributed denial of service (DDoS) mechanisms; b) Social engineering, defined as deceiving system owners or users in order to obtain sensitive or confidential information; c) Phishing and its variants; d) Theft of passwords or other sensitive information; e) Intentional deletion or alteration of computer data; f) Intentional infliction of damage to the information system; g) Installation and distribution of malicious software. 4 — Without prejudice to the applicable data protection rules, any computer data communicated to the owner or person responsible for managing the information system, product, or ICT service, or to the national cybersecurity authority, must be deleted within 10 days from the moment the vulnerability is corrected, and its confidential nature must be ensured throughout the process. 5 — Acts performed with the consent of the owner or administrator of the information system, product, or ICT service are also not punishable, without prejudice to the obligation to notify the national coordinating authority responsible for responding to cybersecurity incidents of any vulnerabilities identified, in accordance with the legal framework on cybersecurity. -------------------------------------------------------------------------------- ## Vulnerability Disclosure Policy URL: https://disclose.io/framework/terms/vdp/ Description: Canonical VDP boilerplate with safe harbor, from the disclose.io framework. Introduction [Organization Name] welcomes feedback from security researchers and the general public to help improve our security. If you believe you have discovered a vulnerability, privacy issue, exposed data, or other security issues in any of our assets, we want to hear from you. This policy outlines steps for reporting vulnerabilities to us, what we expect, what you can expect from us. Systems in Scope This policy applies to any digital assets owned, operated, or maintained by [Organization Name]. Out of Scope Assets or other equipment not owned by parties participating in this policy. Vulnerabilities discovered or suspected in out-of-scope systems should be reported to the appropriate vendor or applicable authority. Our Commitments When working with us, according to this policy, you can expect us to: Respond to your report promptly, and work with you to understand and validate your report; Strive to keep you informed about the progress of a vulnerability as it is processed; Work to remediate discovered vulnerabilities in a timely manner, within our operational constraints; and Extend Safe Harbor for your vulnerability research that is related to this policy. Our Expectations In participating in our vulnerability disclosure program in good faith, we ask that you: Play by the rules, including following this policy and any other relevant agreements. If there is any inconsistency between this policy and any other applicable terms, the terms of this policy will prevail; Report any vulnerability you’ve discovered promptly; Avoid violating the privacy of others, disrupting our systems, destroying data, and/or harming user experience; Use only the Official Channels to discuss vulnerability information with us; Provide us a reasonable amount of time to resolve the issue before you disclose it publicly; Perform testing only on in-scope systems, and respect systems and activities which are out-of-scope; If a vulnerability provides unintended access to data: Limit the amount of data you access to the minimum required for effectively demonstrating a Proof of Concept; and cease testing and submit a report immediately if you encounter any user data during testing, such as Personally Identifiable Information (PII), Personal Healthcare Information (PHI), credit card data, or proprietary information; You should only interact with test accounts you own or with explicit permission from the account holder; and Do not engage in extortion. Official Channels Please report security issues via [reporting channel], providing all relevant information. The more details you provide, the easier it will be for us to triage and fix the issue. Safe Harbor When conducting vulnerability research, according to this policy, we consider this research conducted under this policy to be: Authorized concerning any applicable anti-hacking laws, and we will not initiate or support legal action against you for accidental, good-faith violations of this policy; Authorized concerning any relevant anti-circumvention laws, and we will not bring a claim against you for circumvention of technology controls; Exempt from restrictions in our Terms of Service (TOS) and/or Acceptable Usage Policy (AUP) that would interfere with conducting security research, and we waive those restrictions on a limited basis; and Lawful, helpful to the overall security of the Internet, and conducted in good faith. You are expected, as always, to comply with all applicable laws. If legal action is initiated by a third party against you and you have complied with this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please submit a report through one of our Official Channels before going any further. Note that the Safe Harbor applies only to legal claims under the control of the organization participating in this policy, and that the policy does not bind independent third parties. -------------------------------------------------------------------------------- ## VDP with Coordinated Disclosure Window URL: https://disclose.io/framework/terms/vdp-with-cvd/ Description: Canonical VDP with an explicit coordinated-disclosure timeline. Introduction [Organization Name] welcomes feedback from security researchers and the general public to help improve our security. If you believe you have discovered a vulnerability, privacy issue, exposed data, or other security issues in any of our assets, we want to hear from you. This policy outlines steps for reporting vulnerabilities to us, what we expect, what you can expect from us. Systems in Scope This policy applies to any digital assets owned, operated, or maintained by [Organization Name]. Out of Scope Assets or other equipment not owned by parties participating in this policy. Vulnerabilities discovered or suspected in out-of-scope systems should be reported to the appropriate vendor or applicable authority. Our Commitments When working with us, according to this policy, you can expect us to: Respond to your report promptly, and work with you to understand and validate your report; Strive to keep you informed about the progress of a vulnerability as it is processed; Work to remediate discovered vulnerabilities in a timely manner, within our operational constraints; and Extend Safe Harbor for your vulnerability research that is related to this policy. Our Expectations In participating in our vulnerability disclosure program in good faith, we ask that you: Play by the rules, including following this policy and any other relevant agreements. If there is any inconsistency between this policy and any other applicable terms, the terms of this policy will prevail; Report any vulnerability you’ve discovered promptly; Avoid violating the privacy of others, disrupting our systems, destroying data, and/or harming user experience; Use only the Official Channels to discuss vulnerability information with us; Provide us a reasonable amount of time (at least [number of days] days from the initial report) to resolve the issue before you disclose it publicly; Perform testing only on in-scope systems, and respect systems and activities which are out-of-scope; If a vulnerability provides unintended access to data: Limit the amount of data you access to the minimum required for effectively demonstrating a Proof of Concept; and cease testing and submit a report immediately if you encounter any user data during testing, such as Personally Identifiable Information (PII), Personal Healthcare Information (PHI), credit card data, or proprietary information; You should only interact with test accounts you own or with explicit permission from the account holder; and Do not engage in extortion. Official Channels Please report security issues via [reporting channel], providing all relevant information. The more details you provide, the easier it will be for us to triage and fix the issue. Safe Harbor When conducting vulnerability research, according to this policy, we consider this research conducted under this policy to be: Authorized concerning any applicable anti-hacking laws, and we will not initiate or support legal action against you for accidental, good-faith violations of this policy; Authorized concerning any relevant anti-circumvention laws, and we will not bring a claim against you for circumvention of technology controls; Exempt from restrictions in our Terms of Service (TOS) and/or Acceptable Usage Policy (AUP) that would interfere with conducting security research, and we waive those restrictions on a limited basis; and Lawful, helpful to the overall security of the Internet, and conducted in good faith. You are expected, as always, to comply with all applicable laws. If legal action is initiated by a third party against you and you have complied with this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please submit a report through one of our Official Channels before going any further. Note that the Safe Harbor applies only to legal claims under the control of the organization participating in this policy, and that the policy does not bind independent third parties. -------------------------------------------------------------------------------- ## Level 1 — Contact Only URL: https://disclose.io/framework/maturity/level-1/ Description: security.txt published; a researcher can reach someone. No policy yet. The organisation is findable and has a working intake method for security reports. This is typically evidenced by a security.txt file and/or a dedicated security contact (email, form, or URL). The bar is deliberately low — it just means a researcher can reach someone. There is no policy document, no legal commitment, and no defined process. But you exist, and you can be found. What observers see security.txt published at /.well-known/security.txt (RFC 9116) At least one valid Contact: entry (email, URL, or phone) Optionally: Policy:, Encryption:, Acknowledgments:, Hiring:, Preferred-Languages: Researcher protection None in writing. There’s an address to send things to, but no promises about what will happen after you do. Path to Level 2 Publish a VDP document at the Policy: URL listed in your security.txt. At minimum it should describe: What you accept reports about (scope) How to submit a report What researchers can expect back (response cadence, resolution process) See terms/core-vdp.md for a starting template. -------------------------------------------------------------------------------- ## Safe Harbor URL: https://disclose.io/framework/terms/safe-harbor/ Description: Standalone full safe-harbor clause for attaching to an existing policy. Safe Harbor When conducting vulnerability research, according to this policy, we consider this research conducted under this policy to be: Authorized concerning any applicable anti-hacking laws, and we will not initiate or support legal action against you for accidental, good-faith violations of this policy; Authorized concerning any relevant anti-circumvention laws, and we will not bring a claim against you for circumvention of technology controls; Exempt from restrictions in our Terms of Service (TOS) and/or Acceptable Usage Policy (AUP) that would interfere with conducting security research, and we waive those restrictions on a limited basis; and Lawful, helpful to the overall security of the Internet, and conducted in good faith. You are expected, as always, to comply with all applicable laws. If legal action is initiated by a third party against you and you have complied with this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please submit a report through one of our Official Channels before going any further. Note that the Safe Harbor applies only to legal claims under the control of the organization participating in this policy, and that the policy does not bind independent third parties. -------------------------------------------------------------------------------- ## Simple Safe Harbor URL: https://disclose.io/framework/terms/simple-safe-harbor/ Description: Condensed safe harbor clause for quick adoption. We will consider your security research to be authorized if you make a good faith effort to comply with this policy during your security research. If your activities violate certain restrictions in our Acceptable Use Policy, we will waive those restrictions for the limited purpose of allowing security research. We will not sue you for attempting to circumvent the technological safeguards we have put in place to protect the applications in scope. If a third party takes legal action against you for activities carried out in accordance with this policy, we will make this authorization known. For inadvertent, good-faith violations of this policy, we will not take civil action or file a report with law enforcement. Before doing anything that may be inconsistent with or unaddressed by this policy, please contact us by submitting a report. -------------------------------------------------------------------------------- ## Level 2 — Basic VDP URL: https://disclose.io/framework/maturity/level-2/ Description: Public policy document and a real submission channel. No legal protection. There is an actual, publicly accessible document describing how the organisation wants vulnerabilities reported, plus a real communication channel to do it through. The intent is in writing. This is the minimum threshold to be considered a functioning Vulnerability Disclosure Program — but there are no legal protections for the researcher yet. What observers see A public VDP document at a stable URL (often /security/ or /security/policy) Scope language — what’s in, what’s out A concrete submission channel (form, email, platform) Expected response cadence or triage commitments No safe harbor language, OR only passive “we appreciate research” language with no legal commitment Researcher protection None legally. The policy exists as a statement of intent. A researcher doing good-faith testing still has no defence against a CFAA claim, a DMCA claim, or a TOS-based action. Path to Level 3 Add language that promises the organisation will not pursue legal action against researchers who act in good faith and follow the policy. See terms/core-vdp.md sections on Safe Harbor for baseline language. -------------------------------------------------------------------------------- ## Bug Bounty Program Policy URL: https://disclose.io/framework/terms/bbp/ Description: Canonical BBP boilerplate with rewards structure and safe harbor. Introduction [Organization Name] welcomes feedback from security researchers and the general public to help improve our security. If you believe you have discovered a vulnerability, privacy issue, exposed data, or other security issues in any of our assets, we want to hear from you. This policy outlines steps for reporting vulnerabilities to us, what we expect, what you can expect from us. Systems in Scope [INSERT LIST HERE] This policy applies only to any digital assets owned, operated, or maintained by [Organization Name] for which [Organization Name] can legally authorize security testing. Any assets not listed above are out-of-scope for security testing under this policy. Out of Scope Assets or other equipment not owned by parties participating in this policy or not listed in “Systems In Scope.” Vulnerabilities discovered or suspected in out-of-scope systems should be reported to the appropriate vendor or applicable authority. Rewards Our Commitments When working with us, according to this policy, you can expect us to: Respond to your report promptly, and work with you to understand and validate your report; Strive to keep you informed about the progress of a vulnerability as it is processed; Work to remediate discovered vulnerabilities in a timely manner, within our operational contraints; and Extend Safe Harbor for your vulnerability research that is related to this policy. Our Expectations In participating in our vulnerability disclosure program in good faith, we ask that you: Play by the rules, including following this policy and any other relevant agreements. If there is any inconsistency between this policy and any other applicable terms, the terms of this policy will prevail; Report any vulnerability you’ve discovered promptly; Avoid violating the privacy of others, disrupting our systems, destroying data, and/or harming user experience; Use only the Official Channels to discuss vulnerability information with us; Provide us a reasonable amount of time (at least [number of days] days from the initial report) to resolve the issue before you disclose it publicly; Perform testing only on in-scope systems, and respect systems and activities which are out-of-scope; If a vulnerability provides unintended access to data: Limit the amount of data you access to the minimum required for effectively demonstrating a Proof of Concept; and cease testing and submit a report immediately if you encounter any user data during testing, such as Personally Identifiable Information (PII), Personal Healthcare Information (PHI), credit card data, or proprietary information; You should only interact with test accounts you own or with explicit permission from the account holder; and Do not engage in extortion. Official Channels Please use [reporting channel] to report security issues, providing all relevant information. The more details you provide, the easier it will be for us to triage and fix the issue. Safe Harbor When conducting vulnerability research, according to this policy, we consider this research conducted under this policy to be: Authorized concerning any applicable anti-hacking laws, and we will not initiate or support legal action against you for accidental, good-faith violations of this policy; Authorized concerning any relevant anti-circumvention laws, and we will not bring a claim against you for circumvention of technology controls; Exempt from restrictions in our Terms of Service (TOS) and/or Acceptable Usage Policy (AUP) that would interfere with conducting security research, and we waive those restrictions on a limited basis; and Lawful, helpful to the overall security of the Internet, and conducted in good faith. You are expected, as always, to comply with all applicable laws. If legal action is initiated by a third party against you and you have complied with this policy, we will take steps to make it known that your actions were conducted in compliance with this policy. If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please submit a report through one of our Official Channels before going any further. Note that the Safe Harbor applies only to legal claims under the control of the organization participating in this policy, and that the policy does not bind independent third parties. -------------------------------------------------------------------------------- ## Level 3 — Partial Safe Harbor URL: https://disclose.io/framework/maturity/level-3/ Description: A commitment not to pursue legal action. Report safely; test uncertainly. The policy makes a promise not to pursue legal action against researchers acting in good faith. The key word is promissory — language like “we will not pursue” or “we will not take legal action.” This is where researcher protection begins. However, it stops short of explicitly authorising testing — think of it as “you’re safe to report” rather than “you’re safe to test.” The protection is real but incomplete. What observers see Policy language that commits the organisation to non-pursuit for good-faith research Often phrased as “we will not initiate legal action” or “we waive claims against” Scope of the promise is sometimes narrow — only reports through the official channel, only current policy adherents, etc. Testing itself is NOT explicitly authorised Researcher protection Partial. If a researcher reports responsibly and the organisation honors its word, the researcher is protected from action by this organisation. But: Third parties (platforms, law enforcement) are not bound Anti-circumvention laws (DMCA) still apply TOS/AUP violations remain open for action The protection often requires the researcher to already have adhered to the policy — a chicken-and-egg problem if testing itself is the question Path to Level 4 Upgrade the Safe Harbor section to explicitly authorise security testing, and carve out specific exemptions from anti-hacking laws (CFAA, CMA), anti-circumvention laws (DMCA), and the organisation’s own TOS/AUP. See terms/core-vdp.md Safe Harbor section for canonical language. -------------------------------------------------------------------------------- ## Level 4 — Full Safe Harbor URL: https://disclose.io/framework/maturity/level-4/ Description: Explicit testing authorisation and carve-outs from CFAA / DMCA / TOS. The meaningful legal leap. The organisation doesn’t just promise not to sue — it explicitly grants permission to test, and carves out exemptions from the specific laws that typically get researchers in trouble: Anti-hacking laws (CFAA, CMA, or equivalent) Anti-circumvention laws (DMCA, or equivalent) The organisation’s own Terms of Service / AUP Scope, compensation, communication channels, and disclosure process are all clearly defined. A researcher can point to this policy as a legal defence. This is the gold standard for researcher protection. What observers see Policy explicitly authorises security research conducted under the terms as “lawful” and “not an infringement” Specific waivers for CFAA / CMA / anti-hacking law applicability Specific waivers for DMCA / anti-circumvention law applicability Explicit TOS/AUP carve-out for security research activity Clear scope definition, clear communication channels, clear expectations on both sides Often includes third-party-threat language (“if legal action is initiated by a third party against you and you have complied with this policy, we will take steps to make it known…”) Researcher protection Full — for testing. A researcher operating within scope, via the official channels, in good faith, has explicit written authorisation and can point to the policy as a defence in any challenge. What’s still missing at Level 4: public accountability on disclosure timing. The organisation has invited research, but hasn’t committed to a public coordinated-disclosure timeline. Path to Level 5 Add a proactive, public coordinated-disclosure timeline (typically 90 days) with a defined process for extensions. See practices/coordinated-disclosure.md for implementation guidance. -------------------------------------------------------------------------------- ## Level 5 — Full Safe Harbor + CVD URL: https://disclose.io/framework/maturity/level-5/ Description: Level 4 plus a public coordinated-disclosure timeline. Accountable. Everything in Level 4, plus a proactive, public coordinated disclosure timeline — typically 90 days — with a defined process for adjusting it. This creates accountability on the organisation’s side of the equation: researchers know that even if a vendor is slow to act, the vulnerability will eventually see daylight. It transforms the relationship from reactive to collaborative. What observers see Everything in Level 4 A published coordinated-disclosure timeline (commonly 90 days, sometimes 120) A defined extension mechanism — what justifies extending, how it’s negotiated, what the cap is An explicit commitment to public disclosure if the timeline is not met Typically: a CVE issuance process, advisory authoring, researcher credit norms Researcher protection Full — for testing and disclosure. A researcher at Level 5 has: Authorised access for testing (Level 4 properties) A predictable path to public disclosure that doesn’t require consent from the vendor Accountability on both sides: the organisation must actually act, or the vulnerability becomes public Beyond Level 5 diostatus stops at 5 intentionally — the jump from “no program” to Level 5 is already a years-long journey for most organisations. Beyond Level 5, differences become practice- and culture-based rather than policy-based: Proactive outreach to researchers Published payout scales (for BBPs) Public transparency reports Participation in industry-wide CVD coordination (CERT/CC, national CSIRTs, multi-party disclosure) See practices/ for operational guidance beyond the policy surface. --------------------------------------------------------------------------------