This talk is an update on The disclose.io Project in 2021, some of the new things we've been working on, and the general state of hacker safety in 2021. This was a part of the https://www.hackingisnotacrime.org and Red Team Village event - I highly recommend checking out the other videos from this event!

Disclose.io: Building Neighborhood Watch for the Internet

Adapted from a talk at Red Team Village / Hack Not Crime

The law thinks hacking is probably a crime. That's the root of the problem we've been trying to solve with disclose.io — and the reason the "Hacking is Not a Crime" movement exists in the first place.

The CFAA, the Computer Misuse Act, and their equivalents around the world largely don't account for good faith. If you're touching a computer you don't own, the default legal assumption skews toward criminal intent. That creates a real problem for the people trying to help.

The friction that sparked disclose.io

I first saw this friction play out in the early days of Bugcrowd. Organizations that wanted to receive vulnerability reports from security researchers needed to create a legal exception for finders — and the lawyers tasked with drafting those exceptions did what lawyers do when they're uncertain: they wrote a lot of words.

The resulting policies were long, dense, full of legalese, and frankly impenetrable to most of the people who needed to read them. Many researchers don't have legal training. Some are reading in English as a second language. And let's be honest — most people don't read terms and conditions cover to cover anyway. When you're a researcher eager to report a vulnerability, you're skimming for scope and getting to work.

The consequence? Researchers can easily create legal risk for themselves without even realizing it. The chilling effect is real: the threat of legal repercussions stymies security research, and even suppresses incidental reporting when someone stumbles onto a vulnerability they weren't looking for.

How do we make it easy to do this well?

That was the question I kept noodling on. We weren't the first to ask it — Rain Forest Puppy published the RFPolicy back in 2001, codifying how researchers and vendors should interact. Bugcrowd and CipherLaw created the open source vulnerability disclosure framework in 2014. ISO published standards. The DOJ weighed in. Amit Elazari did groundbreaking work surfacing the Safe Harbor problem and driving awareness that got people to actually care.

By 2018, the landscape had shifted. Bug bounties and vulnerability disclosure had gained enough traction that the concept of a hacker as a "digital locksmith" — rather than a burglar — was starting to land. The idea that someone finding a broken lock on your front door might actually be trying to help you, not rob you. That shift gave us a window.

I grabbed the disclose.io domain and built a focal point: a place to consolidate the fragmented efforts, create tools people could actually use, and start making the adoption of vulnerability disclosure programs go viral.

The vision: an internet immune system

Our vision is a healthy and ubiquitous internet immune system, enabled by security research, reporting, and disclosure. The mission is to standardize and promote neighborhood watch for the internet.

Standardization matters because it sets precedent and reduces friction. Promotion matters because organizations need to know this is something they should be doing. And desirability matters — if the market wants this, adoption takes care of itself.

Here's my firm belief: between now and the heat death of the universe, anyone running IT infrastructure is going to have to deal with a security researcher who's found a problem with their stuff. That's a physics issue, not a choice. The question is whether you're ready for that conversation or not.

The endgame is a virtuous cycle. I'd love for the disclose.io seal to become like the green padlock once was — a recognizable trust signal that eventually becomes so standard we don't even need it anymore. We're a long way from that, but that's the direction.

What disclose.io actually is

Disclose.io started as a collection of open source projects and has grown into a movement. We're currently filing for 501(c)(3) status to formalize the initiative, enable funding, and establish it as a truly independent, community-powered effort. There are about 50 core members, 200+ contributors, and 2,300 organizations in the database.

The project has five core pillars:

1. The Terms

Boilerplate vulnerability disclosure policy templates, created and refined by lawyers, program owners, and policymakers. The key design principle: balance legal completeness with brevity and readability.

How can a researcher — who may not understand law, may not be a native English speaker — read a disclosure policy and actually understand what's going on? That's the problem the terms solve.

For finders, the terms provide an easy reference to encourage organizations to start a VDP or adopt Safe Harbor. For organizations, they make an otherwise foreign piece of policy creation simple and de-risked. The open source, consensus-driven nature of the project means you're not just trusting one person's legal interpretation — you're building on community-validated language.

We've seen this language get picked up by voting machine manufacturers, adopted by state governments ahead of the 2020 election, and embedded in programs across the industry.

2. The List

A community-powered, vendor-agnostic directory of all known VDPs and bug bounty programs. It's open source (CC-BY 4.0), maintained in JSON and CSV, and used broadly — Bugcrowd powers its own directory from this dataset.

For researchers, the list helps make safe decisions. Not just feeling safe, but actually assessing which organizations are friendly to work with and which might not be. It also fosters empathy — seeing organizations at various stages of maturity helps researchers think about what's happening on the other side of the disclosure conversation.

For organizations, it's a tool for internal conversation: "Here are all these other companies doing this. Maybe we should too."

3. The Seal

The disclose.io seal builds on two core concepts:

Partial Safe Harbor — permission to report. The organization commits not to pursue legal action against good-faith reporters.

Full Safe Harbor — permission to hack. The organization proactively authorizes security research under defined good-faith terms, providing exemptions from anti-hacking laws (CFAA), circumvention laws (DMCA), and acceptable use policy violations, along with a general acknowledgement of good faith.

For researchers, the seal is a recognizable signal of where an organization stands on security. For organizations, it's a validated trust mark — a way to demonstrate participation in internet neighborhood watch to customers, peers, and the security community.

Here's what I find most compelling: vulnerability disclosure is one of the rare things in cybersecurity you can explain to your grandparents and they'll probably get it. "Neighborhood watch, but for the internet" is an intuitive concept in a way that most security controls aren't. That translates to genuine consumer confidence and, ultimately, business benefit.

What's new

Disclose.io Status

We've extended the Safe Harbor framework into a recognizable maturity ladder. At the bottom: deploying a security.txt to point people to the right place. At the top (what I consider the current gold standard): full Safe Harbor with a proactive coordinated vulnerability disclosure timeline and policy.

The power here is aspirational. An organization with just a security.txt looks up at the organization at the top of the hill and thinks, "I want to be there. How do I get there?" That visibility creates a natural educational pathway.

DNS Security.txt

A new approach to making security reporting information more accessible: putting the equivalent of security.txt content into DNS zone files as TXT records. This makes the information more discoverable (researchers are already looking at DNS) and more authoritative (DNS TXT records are broadly understood as official organizational statements).

The Community

When researchers find something and need help — whether they're afraid, can't find the right contact, or just don't know the process — there's historically been a handful of people who get the phone call. I'm one of them, and while I think that's great, it's not scalable.

We've built a community at community.disclose.io where volunteers provide support for researchers navigating the disclosure process. First-time disclosure is inherently scary on both sides. The community exists to reduce friction, prevent misunderstandings, and help information get to the right place.

The virtuous cycle

Put it all together and it works like this: A company wants to create or update a program. They use the disclose.io terms. They update the database. They earn the seal. Another company sees that and asks, "Where am I on this? This seems to be becoming normal." And the cycle repeats.

Get involved

We're always looking for more contributors — whether that's from a coding, design, legal, or evangelism standpoint:

• Browse the database: disclose.io
• Join the community: community.disclose.io
• Check out the terms: Help your organization adopt Safe Harbor language
• Contribute to the project: Reach out at hello@disclose.io

The goal is to make this snowball big enough that it rolls itself down the hill. Every organization that adopts best-practice disclosure, every researcher who reports safely, and every contributor who improves the tools moves us closer to that healthy, ubiquitous internet immune system.

If you're not a lawyer, I'm not a lawyer, and we're all just trying to make the internet safer — disclose.io is how we level the playing field.