diodb: The Open Database Solving Security Research's Legal Gray Area

Hook

In 2018, a security researcher faced federal charges for testing a website's security—even though he reported the vulnerability responsibly. The problem? The organization had no public disclosure policy, leaving researchers to guess whether their work would be welcomed or prosecuted.

Context

Security researchers face a paradox: organizations want their systems tested for vulnerabilities, but the legal framework around unsolicited security testing remains murky. Without explicit permission, good-faith security research can be prosecuted under laws like the Computer Fraud and Abuse Act (CFAA) in the United States. Even when researchers discover critical vulnerabilities, they often don't know who to contact or whether reporting will result in gratitude or legal threats.

This information asymmetry creates a chilling effect. Researchers avoid testing certain targets, vulnerabilities go unreported, and organizations miss opportunities to improve their security posture. While platforms like HackerOne and Bugcrowd have created centralized bug bounty marketplaces, they only represent a fraction of organizations with disclosure programs. Many companies host independent programs, some offer Safe Harbor protections through security.txt files, and others have informal contact methods scattered across policy pages. Before diodb, there was no comprehensive, vendor-neutral directory that security researchers could consult to answer the simple question: "Can I legally test this organization's security, and who do I contact if I find something?"

Technical Insight

diodb's architecture prioritizes simplicity and accessibility over complexity. At its core, the project is a single JSON file (program-list.json) structured as an array of program objects, each containing standardized metadata about vulnerability disclosure and bug bounty programs. This design choice—favoring a flat file over a database—makes the data trivially consumable by any tool or language without requiring API authentication, SDKs, or complex queries.

Each program entry follows a consistent schema:

{
  "program_name": "Example Corp",
  "policy_url": "https://example.com/security",
  "contact_url": "https://example.com/report",
  "launch_date": "2020-01-15",
  "offers_bounties": true,
  "offers_safe_harbor": true,
  "platform": "independent",
  "program_location": ["US"],
  "managed_by": "internal"
}

The offers_safe_harbor field is particularly significant. Safe Harbor provisions explicitly state that security researchers acting in good faith and following disclosure guidelines will not face legal action. This Boolean flag lets researchers filter programs where they have explicit legal protection, transforming what was previously a legal research project into a simple database query.

Integrating diodb into a researcher's workflow is straightforward. Here's a Python example that searches for programs offering Safe Harbor protections:

import json
import requests

# Fetch the latest program data
response = requests.get(
    'https://raw.githubusercontent.com/disclose/diodb/main/program-list.json'
)
programs = response.json()

# Find programs with Safe Harbor for a specific domain
target_domain = "example.com"
safe_programs = [
    p for p in programs 
    if p.get('offers_safe_harbor') 
    and target_domain in p.get('program_name', '').lower()
]

for program in safe_programs:
    print(f"Program: {program['program_name']}")
    print(f"Policy: {program['policy_url']}")
    print(f"Contact: {program.get('contact_url', 'See policy')}")
    print(f"Platform: {program.get('platform', 'unknown')}")
    print("---")

The repository includes validation scripts that enforce schema consistency and catch common errors before they're merged. Contributors submit updates via pull requests, where maintainers verify that URLs are accessible, data fields are properly formatted, and programs actually exist. This human-in-the-loop validation provides a quality gate that automated scraping can't match—maintainers can verify that a listed email address actually reaches a security team, or that a policy URL contains legitimate disclosure guidelines rather than a generic contact form.

The community contribution model operates through GitHub's native features. If a researcher discovers a new program or finds outdated information, they can open an issue with the details or submit a pull request directly modifying the JSON file. This lowers the barrier to contribution—no specialized tools or accounts beyond GitHub are required. The transparency of the process also builds trust; anyone can review the change history to see how programs were added or modified.

For organizations building security tooling, diodb serves as a reference dataset. You could build a browser extension that checks whether the current domain has a disclosure program, integrate it into reconnaissance tools to automatically identify disclosure contacts during security assessments, or use it to generate compliance reports showing which vendors in your supply chain have mature vulnerability management processes. The CC BY 4.0 license permits commercial use, so security platforms can incorporate the data without legal concerns, provided they attribute the source.

Gotcha

diodb's greatest strength—community curation—is also its primary weakness. Data freshness depends entirely on contributors noticing and reporting changes. When organizations update their security policies, change email addresses, or shut down programs, there's no automated mechanism to detect these changes. A researcher relying on diodb might attempt to contact a discontinued email address or miss new disclosure channels. The database is best viewed as a discovery tool rather than a source of truth; always verify information directly with the target organization before proceeding.

The structured data is also deliberately minimal. diodb tells you whether a program exists and provides contact information, but it doesn't capture nuanced details like scope limitations, reward ranges, response time expectations, or technical focus areas. A program might accept mobile app vulnerabilities but not web issues, or offer rewards only for critical findings—details you'll only discover by reading the full policy. Researchers expecting a comprehensive program directory with detailed metadata will be disappointed; diodb is an index, not an encyclopedia. For complete information, you'll still need to visit HackerOne, Bugcrowd, or the organization's own documentation. Additionally, the lack of an API means consumers must parse the raw JSON file and implement their own caching and update strategies, which can be inefficient for applications needing frequent access to program data.

Verdict

Use diodb if you're a security researcher who needs a comprehensive starting point for discovering which organizations have formal vulnerability disclosure processes, especially when you're evaluating whether to test a particular target and need to quickly check for Safe Harbor protections. It's invaluable for understanding the broader landscape beyond major bug bounty platforms and for organizations looking to benchmark their disclosure programs against industry peers. The open data format makes it perfect for integrating into security automation workflows, reconnaissance tooling, or compliance tracking systems. Skip it if you need guaranteed real-time accuracy for program details, comprehensive scope and reward information, or a production-grade API with uptime guarantees. In those cases, direct platform APIs from HackerOne or Bugcrowd will provide more reliable, detailed data, though you'll sacrifice the vendor-neutral comprehensiveness that makes diodb unique. Also skip it if you're expecting a turnkey solution for managing your own disclosure program—diodb is a directory, not a program management platform.