lissy93/bug-bounties: a community directory of 3,000+ disclosure programs

What the bug-bounties directory actually collects

A researcher who wants to report a vulnerability has to find out, per company, whether there is a program, where it lives, and whether it pays. That information is scattered across Bugcrowd, HackerOne, Intigriti, Immunefi, YesWeHack, and company pages that are not on any platform at all. lissy93/bug-bounties compiles those entries into one repository and publishes them at bug-bounties.as93.net.

The README describes it as "a compiled list of companies who accept responsible disclosure." The list is broader than paid bounties: the key in the README marks a money symbol for bounty, a medal symbol for shout-out, and a gift symbol for swag, so a company that only acknowledges reports still appears. The repository description puts the count at 3,000+ active programs and VDPs.

The intended audience is not only human hunters. The topics list ai-security and mcp, and there is a top-level mcp/ directory, so the project is also aimed at agents and tooling that need a machine-readable program list rather than a web page.

YAML files, a JSON schema, and an MCP server

The data layer is two YAML files at the repository root: platform-programs.yml and independent-programs.yml. The split matters. Platform programs are hosted on a bug bounty platform and are grouped by that platform; independent programs are run directly by the company. A consumer that only trusts platform-mediated programs can read one file and ignore the other.

The Makefile documents the pipeline. populate fetches and merges bounty data from public sources by running lib/populate-bounties.py with --stats. validate checks the program YAML against lib/schema.json using lib/validate-bounties.py. readme runs lib/insert-bounties.py to insert the generated table into .github/README.md. The Python scripts live in lib/ alongside requirements.txt, so the build is Python, while the repository's primary language is TypeScript for the web and MCP parts.

The web/ directory is the static site at bug-bounties.as93.net, and mcp/ is the server that exposes the same data to MCP clients. Those two consumers are why the schema step exists: if the YAML drifts, the site and the MCP server both break.

Running the pipeline and querying the data

The Makefile is the documented entry point. The all target chains install, populate, validate, and readme in that order, and the Makefile sets .DEFAULT_GOAL to all, so a bare make runs the whole chain. Run it from a clone:

make

The first thing it does is install the Python dependencies from lib/requirements.txt, then fetch and merge data, then validate, then rewrite the README table. If you only want to check that the checked-in YAML still satisfies the schema, run the single target:

make validate

That invokes python3 lib/validate-bounties.py against platform-programs.yml and lib/schema.json. A clean run prints nothing beyond the script's own output; a schema violation is where you would see the failure, and the README does not document the exit codes.

If you are building on the data rather than regenerating it, the YAML files are the interface. The repository does not document a hosted REST API in the README even though the description mentions an API, so the files and the MCP server are the paths the repository layout actually shows. For the MCP route, look at mcp/ for how the server is started; the README does not give a start command, so treat the directory as the source of truth.

Where the directory stops being useful

This is a list, not a source of truth about any individual program. Bounty ranges, scope, and eligibility rules live on the program's own page, and the README links out to those pages rather than reproducing terms. If you are deciding whether a target is in scope, the directory entry cannot answer that.

Freshness is the other limit. The last push was on 2026-09-09, so the repository is recently touched, but that says nothing about whether a specific entry was re-checked. Programs close, change scope, and move between platforms. The README does not document a per-entry last-verified field, so you cannot tell from the data alone which rows are stale.

There is also a quality signal problem in the data itself. The README table shows near-duplicate entries such as multiple Acorns rows and an "ABNAMRO BANK" row whose link points at personal.rbs.co.uk, plus at least one entry whose link is plainly a company homepage rather than a disclosure page. That is what community-maintained data looks like. It is usable, but it needs filtering before it reaches an automated workflow.

Finally, the project has no scanner, no recon tooling, and no report submission. It will not find a vulnerability or file a report for you.

Compared with HackerOne and Bugcrowd program directories

The obvious alternatives are the platform directories themselves. HackerOne and Bugcrowd each publish their own program listings, and those listings are authoritative for the programs they host: scope, rewards, and status come from the platform that runs the program.

The difference in approach is coverage versus authority. lissy93/bug-bounties aggregates across platforms and adds independent programs that no platform hosts, which is the only way to get one list that includes a company running its own disclosure page. In exchange, every row is a pointer with a community-maintained link, and the terms always live elsewhere. A platform directory cannot show you an independent program; this directory cannot guarantee that a platform program's terms are current. If you need contract-grade terms, use the platform. If you need breadth and a machine-readable format, use this.

Licence, maintenance, and the cost of keeping the data current

The licence is MIT, which is permissive and places few obligations on reuse: you can consume the YAML, fork the pipeline, and ship derived data. The licence covers the repository's code and data as published. It does not grant you any rights over the linked program pages, and it is not a statement about the programs themselves. This is a description of the licence file, not legal advice; if you are redistributing the data commercially, read the LICENSE file and take your own advice.

Upgrade cost is low in the code sense and non-zero in the data sense. The pipeline is a Makefile plus a handful of Python scripts, so pulling upstream changes is a git pull and a make. The recurring cost is validation: community submissions arrive through the issue template at .github/ISSUE_TEMPLATE/add.yml, and someone has to run make validate before the site and MCP server can trust the result. If you fork the data for internal use, that maintenance becomes yours, and the repository does not document an automated freshness check you could inherit.

Editorial conclusion

Adopt it if you want a machine-readable starting list of disclosure programs for a security workflow, an MCP-aware agent, or a research project, and if you are willing to check each program's own page before acting on it. Do not adopt it if you need contractual bounty terms, guaranteed payouts, or a program list that is verified at request time; the files are community-maintained and the README does not document any freshness guarantee. Before building on it, run make validate and confirm the schema in lib/schema.json accepts the fields you plan to consume.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. lissy93/bug-bounties on GitHub
4. Project website
5. README