bug-bounty-platforms: a community maintained catalog of disclosure programs

A catalog, with the documentation and the data in one file

bug-bounty-platforms is described as a community-powered collection of all known bug bounty platforms, vulnerability disclosure platforms and crowdsourced security platforms currently active on the Internet.

What it actually is, structurally, is a Markdown table in a README, published as a web page. The repository is a Jekyll site, with a _config.yml, a _layouts directory, a CNAME file for the custom domain, a CODEOWNERS file, a docs directory for the marquee image and a scripts directory. The published page is at disclose.io/platforms/, and the repository is part of a wider disclose.io project that the README describes as open, vendor-neutral infrastructure for vulnerability disclosure.

The data is the README, and that is a deliberate choice rather than an artifact of a lazy setup. The project invites corrections by pointing readers at the edit link for the README file itself, and the badge in the header says pull requests are welcome. There is no database, no API and no account, which means the path from a wrong entry to a fixed entry is a pull request against a text file.

The licence is CC0-1.0, which is the most permissive of the Creative Commons dedications, and that choice matches the intent of a public catalogue. The last push to the repository was on 2026-09-14, and the badge claims 121 or more platforms tracked. There are no tagged releases, since the live content is the repository itself.

The taxonomy: six categories and a strict precedence rule

Every platform lives in exactly one category section, and the README gives the rule for deciding which one.

If a platform fits more than one, the first match in a stated precedence order wins: Government and public-interest, then AI, then Web3, then brokered disclosure, then ecosystem-specific, and finally general. There is a second rule for the maintenance of the taxonomy itself. If a category ever drops below two entries, it is folded into General.

That second rule is the interesting one, because it constrains the categories in a way most directories do not. A category has to justify itself by having enough platforms to be a category, so the list cannot fragment into a dozen sections of one entry each. A platform that could sit in government, AI and Web3 all at once goes to government, because that is the first branch of the precedence chain.

The jump links at the top of the list mirror the categories.

For a user, the taxonomy is the point of the list. Searching for a program is not one query, because a government CERT, a national CSIRT and a commercial bug bounty all accept reports under different conditions and reward in different ways, and the categories let you narrow to the kind of programme you are looking for before reading rows.

The eight columns, and why the format is enforced

The table schema is fixed, and the README is explicit that CI enforces the column count. The eight columns are the platform name, the URL, the region, the Twitter or X account, the program types, whether it has a leaderboard, the leaderboard URL, and the public programs URL.

| Platform Name | URL | Region | Twitter/X | Program Types | Has Leaderboard | Leaderboard URL | Public Programs URL |

The program types column is the one that carries the most meaning, and the values in use are Public, Private, and Private plus Public.

The difference matters for a researcher. A public program publishes its scope and its rules and accepts submissions from anyone. A private program typically requires an invitation or an agreement before you can take part, so a row marked Private is a door you cannot walk through, and a row marked Private plus Public is a programme with two tracks.

The leaderboard columns are a smaller signal but a useful one. A platform with a public leaderboard is publishing who is finding what, which is a sign of an active programme, and the public programs URL column points at the subset of programmes that accept outside participation.

Fixing the schema is what makes the list usable as data rather than as prose. A consistent column count means a row can be parsed, and a parsed list can be filtered by region, by type and by whether the programme is open, which is the operation most users actually want.

What the government and public-interest section actually contains

The first section is the government and public-interest one, and reading it is a good way to understand what the list is for.

The rows are national and regional government bodies: the Australian Government VDP from the Department of Home Affairs, CCB Belgium CVD, CERT Polska, CERT-In RVDCP in India, the CISA VDP Platform in the United States, DIVD in the Netherlands, HITCON ZeroDay in Taiwan, Japan Vulnerability Notes, KISA KNVD in South Korea, NCIIPC RVDP, the NCSA Bug Bounty Programme in the Maldives, NCSC-FI, NCSC-NL, NKSC Lithuania, the Qatar Bug Bounty, Singapore GovTech VDP, the Swiss NCSC Bug Bounty, the Taiwan Vulnerability Note and the UK NCSC VDP.

The pattern is that these are national computer emergency response teams and their vulnerability reporting programmes, and the region column is filled in for almost every one of them, with Australia, Belgium, Poland, India, the USA, the Netherlands, Taiwan, Japan, South Korea, the Maldives, Finland, Lithuania, Qatar, Singapore, Switzerland and the UK all appearing.

The public interest dimension is what separates this section from the rest of the list. These programmes generally do not pay, and they are not bounty programmes in the commercial sense. They exist so that a researcher who finds a flaw in government or critical infrastructure systems has somewhere legitimate to report it, and the region column is the field that tells you whether the programme covers the system you are looking at.

The list also shows which of them publish a leaderboard and which keep a public list of resolved advisories, with the CERT-In Hall of Fame and the Japanese and Taiwanese vulnerability note pages linked in that column.

The other categories: Web3, AI, brokered and ecosystem specific

The remaining sections are the ones that have appeared in the security world more recently.

The Web3 and smart-contract platforms section is separate because smart contract vulnerabilities have their own disclosure norms, with bug reports against deployed contracts rather than against running services, and the platforms listed there tend to work with specific protocols rather than with general software.

The AI and LLM security platforms section exists because the same split applies to model and inference vulnerabilities, and it sits high in the precedence order, above Web3. That placement is a signal: a platform that is both an AI programme and a Web3 one is filed under AI.

Vulnerability acquisition and brokered disclosure is the section that differs most from the rest, because those are commercial brokers who sit between a researcher and a customer, and the relationship is a contract rather than a reporting channel. Ecosystem-specific platforms are the ones tied to a language, a runtime or a toolchain, which is where a researcher working on a particular stack will look first.

General crowdsourced platforms come last in precedence and last in the document, which makes them the fallback for everything that does not fit the more specific categories.

The three or four program types seen in the government section, public, private, and private plus public, are reused across the list, so the type column is the same vocabulary everywhere.

How the list is maintained, and where it can go wrong

The maintenance model is worth understanding, because it is both the strength and the weakness of the project.

The strength is the low friction of a correction. The README points at the edit link for itself, and a wrong row is a pull request. The category rules, the alphabetical ordering and the column count are all written down in the same file, so a contributor knows exactly what to do without reading a contribution guide first. The CODEOWNERS file suggests that review responsibility is assigned rather than left to whoever happens to look, and the scripts directory in the repository presumably holds the tooling behind the published page.

The weakness is the same property seen from the other side. Every row is a claim by a contributor, and a claim can be wrong in three ways. The programme may have changed its scope, its type or its region. The programme may have closed, and the row will keep pointing at it. Or the row may have been added optimistically, with a link to a page that does not describe a working programme.

The HTML comment markers around the generated section, with a platforms start marker, suggest that part of the file is managed and part is hand written, which is a good structure for a published page, but it also means the boundary between maintained and generated content is a technical detail of the build rather than something a reader of the file can see.

The honest position is that this is a good map and not a source of truth. A researcher should open the program page, read its scope, and confirm that it accepts the kind of report they intend to send, and an operator who wants to publish a vulnerability should treat the list as a way to find the right door rather than as a description of what is behind it.

Editorial conclusion

Adopt this catalog if you need to find the right disclosure program for a report, whether for a government CERT in your own region, a Web3 or AI specific program, or a general crowdsourced platform, because the taxonomy makes the choice systematic rather than a search. Do not treat it as authoritative, since every row is a community contribution and a program can change its scope or disappear without the list being updated. Before you submit a report, open the program page itself and confirm its scope and policy, and use the pull request page to correct anything the list has wrong.

Frequently asked questions

Official sources

1. disclose/bug-bounty-platforms on GitHub
2. Issues
3. License: CC0-1.0
4. Project website
5. README