# Participation routes, program selection, and disclosure

Program existence is not a promise that every asset is currently open, every researcher is eligible, or every accepted report earns money. Facts below come from official program pages and documentation. Recommendations and the selection model are editorial judgments.

## The distinctions that determine whether your work pays

Treat **access, target scope, testing permission, finding eligibility, payment, and disclosure** as six separate decisions. A public program may require registration, identity verification, geographic eligibility, or a minimum reputation. An asset can accept reports without offering rewards. A legitimate vulnerability can be outside the program's accepted threat model. A private program can be unpaid. A public repository can have a private reporting channel. None of those terms are interchangeable.

| Dimension | Record before choosing a target |
|---|---|
| Participation | Public, registered-only, application, invitation, vetted specialist, event registration |
| Program model | Ongoing bounty, unpaid VDP, discretionary reward, audit contest, paid assessment, patch incentive |
| Technical scope | Exact domains/paths, API endpoints, mobile IDs, repositories/branches, packages, versions, cloud services, contracts/chains, hardware |
| Environment | Production, sandbox, researcher tenant, self-hosted lab, supplied appliance, local chain fork |
| Eligible behavior | Explicitly permitted tests, rate limits, prohibited actions, proof requirements, stopping conditions |
| Reward | Eligible asset tier, vulnerability classes, severity model, duplicates, caps, contest sharing, payout prerequisites |
| Confidentiality | Program existence, code access, findings, collaborators, permitted AI processing, publication rules |

GitHub's private vulnerability reporting routes reports to repository maintainers; it is not a blanket GitHub-funded bounty. A `security.txt` file tells you where to find the reporting policy. RFC 9116 expressly says its presence does not imply permission to test, and the file does not automatically cover parent domains or subdomains. [GitHub private reporting](https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/report-privately), [RFC 9116, sections 3.1 and 5.5](https://www.rfc-editor.org/rfc/rfc9116.html).

## Platform and participation comparison

The table covers 26 useful routes, including some that must now be treated as unavailable for new paid OSS research. Links point to official entry or policy pages. Re-read the exact brief before allocating time.

| # | Platform or route | Access and reward model | Best fit and decisive limitation |
|---|---|---|---|
| 1 | [HackerOne](https://www.hackerone.com/bug-bounty-programs) | Public and private BBPs/VDPs; invitations and qualifying private opportunities | Broad web/API/mobile/product work. Distinguish bounty programs from response-only listings; private access is conditional and confidential. [Invitation rules](https://docs.hackerone.com/en/articles/8470802-invitations). |
| 2 | [Bugcrowd](https://docs.bugcrowd.com/researchers/participating-in-program/finding-program/) | Public programs and selected private engagements; BBPs, VDPs, other engagement models | Broad scopes and specialist matching. Read the engagement brief, identity/geography requirements, status and disclosure terms. A private invitation is not proof of payment. |
| 3 | [Intigriti](https://kb.intigriti.com/en/articles/13175939-program-confidentiality-levels) | Public, registered, application, invite-only; BBPs and VDPs | Useful application-based route to restricted programs. Registered is different from invited; participation restrictions and payout ID verification can apply. [Settings](https://kb.intigriti.com/en/articles/5928505-program-settings). |
| 4 | [YesWeHack](https://helpcenter.yeswehack.io/en/collections/875314-programs) | Public/private programs, grey-box credentials, possible VPN access | Web/API and product programs with documented scope/reward grids. Invitations depend on skills, activity, geography and customer requirements. [Selection](https://helpcenter.yeswehack.io/en/articles/376664-invite-new-hunters-on-a-program). |
| 5 | [Huntr](https://blog.huntr.com/huntr-2-0-faq) | **Now challenge-based AI competitions**; traditional OSS intake closed | OSS submissions stopped **30 June 2026**; all OSS submissions froze **31 July 2026**. Model File Format submissions were still open when this FAQ was published; independently confirm that specific route now. Do not plan ordinary repository bounties from old huntr lists. |
| 6 | [Google OSS VRP](https://bughunters.google.com/about/rules/open-source/google-open-source-software-vulnerability-reward-program-rules) | Funded rewards for qualifying Google OSS research | Check project tiers, dependency criteria and evidence conditions in the current policy. The official [2026 rule-update page](https://bughunters.google.com/blog/ossvrp-rule-updates-2026) exists, but its body and the live policy body were unavailable to this review on **14 September 2026**. Detailed eligibility, amounts and the update date are not reverified; do not substitute launch-era tables. |
| 7 | [Google Patch Rewards](https://bughunters.google.com/about/rules/open-source/patch-rewards-program-rules) | Security-hardening patch incentive | A separate security-hardening route from reporting a newly discovered vulnerability. The official page body was unavailable to this review on **14 September 2026**; verify that the intended project and patch are currently accepted before committing work. |
| 8 | [Internet Bug Bounty](https://hackerone.com/ibb) | **Funding pause confirmed by Node.js; live intake status needs direct recheck** | The official [Node.js notice, updated 2 April 2026](https://nodejs.org/en/blog/announcements/discontinuing-security-bug-bounties), confirms IBB paused and Node.js stopped paying while continuing security intake. IBB’s direct page returned a JavaScript shell on **14 September 2026**; its exact pause date and current submission controls were not independently reverified. |
| 9 | [Repository private vulnerability reporting](https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/report-privately) | Maintainer disclosure channel; no inherent bounty | Excellent for OSS advisories, coordination and fixes. Available when enabled; otherwise follow repository security policy. GitHub hosting alone creates no bounty entitlement. |
| 10 | [GitHub product bounty](https://bounty.github.com/) | Public and invite-only VIP tiers | GitHub platform/products listed in its policy, not every GitHub-hosted repository. [Restructured effective 27 July 2026](https://github.blog/security/next-chapter-restructuring-githubs-bug-bounty-program/); public signal requirements and limited initial submissions apply. |
| 11 | [GitLab product/self-managed research](https://about.gitlab.com/blog/gitlab-bug-bounty-program-policy-updates/) | Product bounty through current HackerOne policy | Strong source-to-runtime route using your own installation. January 2026 policy separates valid scenarios by environment and threat model; do not infer permission over customers' deployments. |
| 12 | [Wordfence](https://www.wordfence.com/threat-intel/bug-bounty-program) | WordPress ecosystem bounty; researcher tiers | Plugins/themes suit local PHP review. Installation thresholds, threat classes, researcher tier and outstanding-report limits affect eligibility. “A plugin bug” is insufficient. |
| 13 | [Patchstack](https://patchstack.com/articles/bug-bounty-guidelines-rules/) | WordPress monthly competition pool plus eligible individual zero-day rewards | Rules updated **1 September 2026**. Latest release, distribution, active-install count, attacker role and impact matter. Managed VDP acceptance can be broader than reward eligibility. |
| 14 | [Microsoft MSRC](https://www.microsoft.com/en-us/msrc/bounty) | Product/service bounty families and coordinated disclosure | Cloud, identity, endpoint, developer tooling. The [December 2025 expansion](https://www.microsoft.com/en-us/msrc/blog/2025/12/in-scope-by-default) covers critical flaws with direct demonstrable impact on Microsoft online services, including relevant third-party code; it is not blanket authorization over unrelated infrastructure. |
| 15 | [Apple Security Bounty](https://security.apple.com/bounty/guidelines/) | Direct product/security rewards | OS, device, sandbox and eligible service research. Reward depends on actionable evidence and current categories; Target Flags can demonstrate exploitability. [Research-device access](https://security.apple.com/research-device/) is a separate application process. |
| 16 | [Mozilla](https://www.mozilla.org/en-US/security/bug-bounty/) | Client and other product/service bounty routes | Browser/client code plus separately scoped web assets. [Client rules](https://www.mozilla.org/en-US/security/client-bug-bounty/) distinguish supported configurations, third-party code, mitigation bypasses and report requirements. Full exploit development is not always required. |
| 17 | [Immunefi](https://immunefi.com/bug-bounty/) | Web3 bug bounties and audit competitions | Smart contracts, protocols and explicitly listed web/infrastructure assets. Exact asset addresses, chains, impact lists and program-specific proof rules decide eligibility; use local forks for impact reproduction where required. |
| 18 | [HackenProof](https://hackenproof.com/) | Public/private bounties and crowdsourced audits | Web3 protocols, exchanges, wallets and listed web assets. Inspect each bounty's scope and reward conditions; platform marketing is not an asset authorization list. |
| 19 | [Cantina](https://cantina.xyz/opportunities) | Bounties, competitions and other security engagements | Onchain and other explicitly offered research opportunities. Check which engagement model you joined, its repository/commit or deployed scope, and judging/payment terms, including any deposit. Its current documentation uses the cantina.security domain. |
| 20 | [Code4rena](https://docs.code4rena.com/) | Competitive audits and separate ongoing bounties | Smart-contract source review. [Bounties](https://docs.code4rena.com/bounties) currently require runnable coded PoCs and generally High/Critical findings; the documented **25 USDC submission deposit** is a real participation cost. Contest terms are different. |
| 21 | [Sherlock](https://docs.sherlock.xyz/audits) | Audit contests, collaborative audits and post-launch bounties | Onchain economics, invariants and protocol logic. Contest finding validity, duplication and payout rules must be learned separately from ordinary web-bounty severity. |
| 22 | [Zero Day Initiative](https://www.zerodayinitiative.com/about/) | Vendor-agnostic vulnerability acquisition and coordination | Product/binary/appliance research. Acquisition is selective and terms-specific; a report is not automatically purchased. Its coordinated-disclosure process differs from reporting straight to a vendor. |
| 23 | [Pwn2Own](https://www.zerodayinitiative.com/Pwn2OwnBerlin2026Rules.html) | Registered, time-bounded exploit competition | Advanced product, virtualization, browser, device and specified AI categories. Berlin 2026 is a completed example; choose a currently announced event, exact target/version/configuration and entry rules. |
| 24 | [Direct vendor PSIRT / security.txt](https://www.rfc-editor.org/rfc/rfc9116.html) | Direct disclosure, sometimes a separate reward program | Reach vendors outside platforms through the official policy/contact route. A security inbox, hall of fame or published source is not a promise of authorization or money. |
| 25 | [Government and institutional VDPs](https://www.cpsc.gov/vulnerability-disclosure-policy) | Usually disclosure and recognition unless a bounty is explicit | A route for useful real-world research. Each institution defines covered systems and stopping conditions. The example policy requires stopping upon confirming the issue or encountering sensitive data. |
| 26 | [Google product and service VRPs](https://bughunters.google.com/report/vrp) | Direct vendor reporting route, separate from the OSS and Patch Rewards entries | Google’s official indexed intake description covers its standard VRP and product families including Android, Cloud, Chrome and ChromeOS. Select the matching program and read its specific rules; the rendered intake body was unavailable on 14 September 2026, so detailed participation and payout conditions are not reverified here. |

**Do not confuse a funded discovery route with a funded remediation route.** OSS-Fuzz infrastructure, advisory databases, CNA status, GitHub Sponsors and a project's grant funding do not by themselves promise payment for your report. Read the specific offer. For example, curl's maintainers explicitly ended its bounty on 31 January 2026 while continuing to value valid reports. [curl bounty policy](https://github.com/curl/curl/blob/master/docs/BUG-BOUNTY.md), [maintainer announcement](https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/).

## Submission rules that change the next action

A common [report template](https://bug-bounty-field-manual.kmahshooq.chatgpt.site/templates.html) keeps evidence consistent. These program-specific gates still need their own check; the examples below were reviewed on **14 September 2026**.

| Route | Practical requirement or limitation | What to prepare |
|---|---|---|
| Apple | Reward priority belongs to the first **complete and actionable** report, which need not be the first message received. Some categories require Target Flags; early publication can remove reward eligibility. | A reproducible package and required target proof before submission; record the permitted publication point. [Apple guidelines](https://security.apple.com/bounty/guidelines/) |
| Code4rena bounties | The 25 USDC deposit is paid through the application; manual transfers are not accepted. Valid or `wontfix` reports receive a refund, invalid/spam reports do not. Bounty submissions cannot be edited after submission. | Review the runnable PoC and exact scope before finalizing; account for the documented deposit and gas. These are bounty rules, not universal contest rules. [Code4rena rules](https://docs.code4rena.com/bounties) |
| Wordfence | Program scope excludes vendor web services not run locally and generally excludes plugins/themes with their own bounty. Its FAQ no longer offers an unrestricted out-of-scope CVE-only route. | Verify the actual component, attacker role, vulnerability class, installation threshold and researcher tier. Use the vendor’s designated route where applicable. [Wordfence policy](https://www.wordfence.com/threat-intel/bug-bounty-program) |
| Immunefi | The directory distinguishes KYC, PoC, paid-submission and primacy-of-impact settings. A program’s settings are not platform-wide defaults. | Record the selected program’s asset/impact rules, submission cost, identity requirements and proof format in the scope record. [Immunefi directory](https://immunefi.com/bug-bounty/) |

If two parts of an official policy appear inconsistent, preserve both references and ask the designated program channel about the specific planned action. Do not choose the most permissive sentence or silently convert a vulnerability taxonomy entry into reward eligibility.

## Preserve research when a reporting route closes

Huntr’s FAQ also discusses access to historical reports, with August and October 2026 milestones and no guarantee of continuing access. If you have prior Huntr submissions, preserve any copies you are permitted to retain while access is available. Record report IDs, affected/fixed versions, advisory links, original evidence and coordination history; keep private material private. The FAQ does not establish that an unresolved frozen report can now be published. [Huntr transition FAQ](https://blog.huntr.com/huntr-2-0-faq).

For any closed route, find the product’s current security policy before reporting a new issue. A platform closure, loss of bounty funding and closure of the underlying vendor’s security intake are different events.

## Self-hosted research: eligibility checks that prevent wasted effort

Self-hosted describes the **test environment**, not a bounty category. Three different cases need different reporting paths:

| Case | Evidence and routing |
|---|---|
| Upstream product flaw reproduced locally | Pin the supported version/commit, use a supported installation, document configuration, show the actual attacker starting privilege and violated boundary; report to the product's designated route. |
| Customer deployment misconfiguration | The customer is the affected operator. The vendor's product bounty might exclude this; verify that customer's scope and authorization separately. |
| SaaS-only flaw in a source-available product | Local source reasoning can suggest the flaw, but local success does not establish the SaaS configuration or reachability. Prove only within permitted SaaS accounts/environment. |

Before committing to a self-hosted target, record: free versus enterprise edition; license or research-license availability; affected maintained branches; default versus optional features; required integrations; tenant model; whether administrator-to-code-execution is expected; and whether the program requires proof on its hosted service. A vulnerability that exists only after you disable authentication or install your own unsafe plugin may have no upstream security impact. Conversely, a low-privilege user crossing a product-promised sandbox or tenant boundary can be meaningful even if the PoC runs locally. These are case-specific judgments; GitLab's January 2026 update is a useful concrete example of explicit environment and threat-model rules. [GitLab policy update](https://about.gitlab.com/blog/gitlab-bug-bounty-program-policy-updates/).

Keep source audit and operational testing permissions separate. A public repository does not authorize triggering its CI with attacker content, publishing a lookalike dependency, using found credentials, probing its production deployment or testing an unrelated customer. Reproduce build pipelines with your own repository, fake tokens and isolated runners whenever possible; seek clarification on any remaining real-system action through the designated program channel.

## Private-program progression

Choose one primary platform and one technical specialty for the first research cycle. For a senior backend engineer, source-assisted authorization, multi-tenant APIs, asynchronous job permissions, import/export processing and integrations are credible specialties. Build evidence of depth through a small number of reproducible reports; uploading scanner output to accumulate activity undermines the quality metrics that matter.

1. **Complete the account correctly:** specialist skills, languages/frameworks, region, permitted contact details, required verification, 2FA and invitation preferences. Use only reports/advisories you are allowed to publicize as portfolio evidence.
2. **Build relevant valid-report history:** take one or two public paid programs with accessible accounts and enough application depth. An unpaid VDP can be worthwhile for learning, impact or platform reputation, but set an explicit time budget.
3. **Use supported access mechanisms:** invitations, application programs and available private opportunities. Accept terms before testing and understand when the engagement actually opens.
4. **Maintain trust:** respond clearly to triage, deliver requested evidence promptly, keep credentials isolated and respect program confidentiality. Track scope changes rather than treating access as permanent.
5. **Reassess invitations commercially:** private access can reduce competition, but slow triage, tiny scope, inaccessible roles or narrow exclusions can still make the program a poor fit. There is no guaranteed invitation schedule.

Platform mechanics differ. HackerOne cites reputation, non-negative signal and a clean conduct record; its documentation also describes available private opportunities. It explicitly prohibits contacting a private program to solicit an invitation. Bugcrowd's newer engagement documentation emphasizes skill match, recent quality submissions, historical performance and customer requirements; older program pages give numerical qualifications, so do not turn those into a universal guarantee. Intigriti includes application programs; YesWeHack describes curated invitations using skills, ranking, location and activity. [HackerOne invitations](https://docs.hackerone.com/en/articles/8470802-invitations), [private opportunities](https://docs.hackerone.com/en/articles/10485859-private-opportunities), [Bugcrowd engagement selection](https://docs.bugcrowd.com/researchers/invites/viewing-and-accepting-engagement-invitations/), [Intigriti confidentiality](https://kb.intigriti.com/en/articles/13175939-program-confidentiality-levels), [YesWeHack invitations](https://helpcenter.yeswehack.io/en/articles/376664-invite-new-hunters-on-a-program).

## Select targets using evidence, not maximum advertised bounty

The following scoring model is a planning heuristic, not measured payout prediction. First apply three hard gates: permission is sufficiently clear; participation/access requirements are satisfied; a currently open reporting route accepts the relevant asset and finding type. For a money-focused sprint, add a fourth gate: an explicit funded reward route exists.

Score each surviving candidate from 0–5, then multiply by weight/5:

| Criterion | Weight | Evidence that earns a high score |
|---|---:|---|
| Your technical advantage | 25 | Familiar language/framework; ability to explain the security boundary; domain knowledge competitors need time to acquire |
| Useful feature/role access | 20 | Two controllable tenants, several roles, enterprise/research features or a fully reproducible local deployment |
| Unexplored surface or recent change | 15 | Recent release, new integration, changed authorization, new API/version or credible under-reviewed component |
| Policy and reward fit | 15 | Your likely findings explicitly accepted, practical proof requirements, clear asset tiers and exclusions |
| Triage and remediation evidence | 15 | Recent legitimate disclosures, maintained release process, public response metrics or your own prior experience |
| Setup and competition cost | 10 | Affordable lab, attainable accounts, bounded setup effort, plausible differentiated angle |

Use **70/100** as an initial active-work threshold and **50–69** as a reserve list; these thresholds are adjustable judgments. Keep only two active targets: a primary deep-research target and a fallback while blocked. For each, write three hypotheses before scanning: “A user removed from a tenant can still export through an asynchronous job,” for example. Each hypothesis needs a starting privilege, reachable feature, expected boundary and a safe observable result.

Timebox setup to one or two sessions initially. Park a target when required roles cannot be obtained, the lab cannot reproduce a supported configuration, policy excludes the research angle, or repeated sessions produce no new reachable surface. Continue when each session resolves uncertainty and opens a plausible boundary violation. Endpoint count, GitHub stars and advertised maximum rewards are weak proxies for expected value.

Track valid/invalid/duplicate outcomes, hours per accepted report, setup time, triage delay, payment delay and recurring root causes. Separate unpaid research goals from income goals. A high CVSS number, CVE assignment, accepted report and cash payment are distinct outcomes; the program's severity and reward policy decides the last one.

## Report-to-disclosure workflow

1. **Validate locally or within the authorized environment.** Use two owned identities/tenants and seeded data where possible. Capture exact versions, requests and preconditions. Add a control case proving that the result depends on the suspected flaw.
2. **Check eligibility and known issues again.** Re-read current scope, exclusions, advisory history, release notes and platform-specific duplicate rules. Distinguish one root cause across endpoints from separate independent vulnerabilities.
3. **Submit one reproducible report through the designated route.** Lead with attacker capability and victim impact; include asset, version/commit, starting role, configuration, numbered reproduction, expected/actual behavior, minimal evidence and cleanup. Provide runnable proof where required. Do not fabricate affected versions, exploit chains or CVSS assumptions.
4. **Coordinate privately.** Answer requests within the program's window. If triage disputes validity or severity, address the specific assumption with evidence, then use the platform's supported mediation/appeal path. Do not threaten publication or route a confidential finding to multiple reward programs to pressure payment.
5. **Support repair and retest.** Agree on the allowed environment; verify the original proof fails for the right reason, the authorized control still works, and a closely related variant is covered. A maintainer-private fork can support an OSS fix without exposing the issue.
6. **Separate payment from publication.** Record the report ID, decision, payout requirements and agreed disclosure date. Follow the applicable policy and coordinated disclosure agreement; neither a fix nor a CVE automatically grants permission to disclose a private program's existence.
7. **Publish only the permitted material.** Remove live tokens, personal data and private-program details. Include root cause, affected/fixed versions, advisory/CVE links and mitigation. Retain a sanitized case study and update your own hypotheses/checklist.

GitHub supports private advisory collaboration and temporary private forks, while Apple, Mozilla, Code4rena and Patchstack have materially different evidence and submission requirements. The common report structure above is a starting template, not a replacement for those rules. [GitHub private reporting](https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/report-privately), [Apple guidelines](https://security.apple.com/bounty/guidelines/), [Mozilla client rules](https://www.mozilla.org/en-US/security/client-bug-bounty/), [Code4rena bounty rules](https://docs.code4rena.com/bounties), [Patchstack rules](https://patchstack.com/articles/bug-bounty-guidelines-rules/).

## Source registry

Original registry accessed **2026-09-11**. A selective follow-up review on **2026-09-14** rechecked the participation mechanics and policy-sensitive claims described above. “Undated/current” records the original retrieval context; it does not certify every program’s present intake. Google’s dynamic policy bodies and the direct IBB policy body could not be reverified. Search-index information is labeled where used, and no inaccessible page is treated as proof that a program closed or reopened.

| Source title | Publisher | Publication/update date | Exact URL | Claim used |
|---|---|---|---|---|
| Bug Bounty Programs | HackerOne | Undated/current | https://www.hackerone.com/bug-bounty-programs | Program discovery route |
| Invitations | HackerOne | 2025-10-15 | https://docs.hackerone.com/en/articles/8470802-invitations | Reputation, signal, conduct, solicitation prohibition |
| Private Opportunities | HackerOne | 2025-01-29 | https://docs.hackerone.com/en/articles/10485859-private-opportunities | Eligible researchers can claim listed opportunities; limited availability |
| Finding a Program | Bugcrowd | Current documentation | https://docs.bugcrowd.com/researchers/participating-in-program/finding-program/ | Public/private access, brief and special requirements |
| Viewing and Accepting Invitations | Bugcrowd | Current documentation | https://docs.bugcrowd.com/researchers/invites/viewing-and-accepting-engagement-invitations/ | Newer engagement matching criteria |
| Viewing and Accepting Program Invitations | Bugcrowd | Current documentation | https://docs.bugcrowd.com/researchers/participating-in-program/viewing-invitations/ | Older numerical criteria differ from newer engagement language |
| Program confidentiality levels | Intigriti | 2025-12-18 | https://kb.intigriti.com/en/articles/13175939-program-confidentiality-levels | Four participation modes |
| Program settings | Intigriti | 2025-12-18 | https://kb.intigriti.com/en/articles/5928505-program-settings | Identity, geography, 2FA and payout restrictions |
| Programs | YesWeHack | Undated/current | https://helpcenter.yeswehack.io/en/collections/875314-programs | Scope grids, grey-box credentials, VPN |
| Invite new hunters on a program | YesWeHack | Relative update label only on 2026-09-14; exact date unverified | https://helpcenter.yeswehack.io/en/articles/376664-invite-new-hunters-on-a-program | Curated invitation criteria |
| Huntr 2.0 FAQ | Huntr / Palo Alto Networks | 2026; retrieved page had no exact date | https://blog.huntr.com/huntr-2-0-faq | OSS intake closure/freeze; challenge pivot; provisional model-format route |
| Google OSS VRP Rules | Google | Undated/current | https://bughunters.google.com/about/rules/open-source/google-open-source-software-vulnerability-reward-program-rules | Current OSS policy route; dynamic body incomplete |
| Streamlining Google's OSS VRP: Key Rule Updates | Google | 2026 title; exact update date not reverified 2026-09-14 | https://bughunters.google.com/blog/ossvrp-rule-updates-2026 | 2026 rule update exists; do not reuse launch-era rules |
| Patch Rewards Program Rules | Google | Undated/current | https://bughunters.google.com/about/rules/open-source/patch-rewards-program-rules | Separate patch incentive |
| Internet Bug Bounty policy | HackerOne / IBB | Direct policy body unavailable 2026-09-14 | https://hackerone.com/ibb | Previous policy reference; current intake controls and exact pause date not reverified |
| Security Bug Bounty Program Paused Due to Loss of Funding | Node.js | Updated 2026-04-02 | https://nodejs.org/en/blog/announcements/discontinuing-security-bug-bounties | IBB loss pauses Node.js payments while intake continues |
| Privately reporting a security vulnerability | GitHub | Undated/current | https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/report-privately | Repository private reporting and private forks |
| Next chapter: Restructuring GitHub's bug bounty program | GitHub | 2026-07-22; effective 2026-07-27 | https://github.blog/security/next-chapter-restructuring-githubs-bug-bounty-program/ | Public/VIP restructuring and signal gate |
| GitHub Security | GitHub | Undated/current | https://bounty.github.com/ | Product program entry point |
| GitLab Bug Bounty Program policy updates | GitLab | 2026-01-20 | https://about.gitlab.com/blog/gitlab-bug-bounty-program-policy-updates/ | Self-managed versus hosted testing and scope |
| Bug Bounty Program | Wordfence | Undated/current | https://www.wordfence.com/threat-intel/bug-bounty-program | Tiers and eligibility conditions |
| Bug Bounty Guidelines & Rules (2026 edition) | Patchstack | Published 2022-07-10; update effective 2026-09-01 | https://patchstack.com/articles/bug-bounty-guidelines-rules/ | Pool/individual reward distinction and recent conditions |
| Microsoft Bounty Programs | Microsoft | Undated/current | https://www.microsoft.com/en-us/msrc/bounty | Program families |
| In scope by default | Microsoft MSRC | 2025-12-11 | https://www.microsoft.com/en-us/msrc/blog/2025/12/in-scope-by-default | Critical online-service impact expansion |
| Guidelines | Apple Security Research | Undated/current | https://security.apple.com/bounty/guidelines/ | Actionable evidence and reward eligibility |
| Security Research Device Program | Apple | Undated/current | https://security.apple.com/research-device/ | Separate research-device program |
| Security Bug Bounty Program | Mozilla | Undated/current | https://www.mozilla.org/en-US/security/bug-bounty/ | Mozilla program entry |
| Client Bug Bounty Program | Mozilla | Undated/current | https://www.mozilla.org/en-US/security/client-bug-bounty/ | Supported client configurations, proof requirements, mitigation scope |
| Bug Bounty Programs | Immunefi | Current directory | https://immunefi.com/bug-bounty/ | Web3 bounty directory |
| Bug bounty and crowdsourced audit platform | HackenProof | Current homepage | https://hackenproof.com/ | Live platform/route types |
| Opportunities | Cantina | Current directory | https://cantina.xyz/opportunities | Bounties, competitions and deposit indicators |
| Welcome to Cantina | Cantina | Current documentation | https://docs.cantina.security/introduction | Current documentation/domain |
| Competitions | Code4rena | Current documentation | https://docs.code4rena.com/ | Competitive audit route |
| Bounties | Code4rena | Current documentation; indexed 2026-03-25 | https://docs.code4rena.com/bounties | Runnable proof, severity and 25 USDC deposit |
| Audits | Sherlock | Current documentation | https://docs.sherlock.xyz/audits | Contest process and judging/payout documentation |
| About Us | TrendAI Zero Day Initiative | Undated/current | https://www.zerodayinitiative.com/about/ | Vendor-agnostic acquisition and coordination |
| Pwn2Own Berlin 2026 Rules | ZDI | 2026 event rules | https://www.zerodayinitiative.com/Pwn2OwnBerlin2026Rules.html | Fixed event, registration and technical target conditions |
| RFC 9116 | IETF / RFC Editor | 2022-04 | https://www.rfc-editor.org/rfc/rfc9116.html | Contact/policy discovery; no implied test authorization |
| Vulnerability Disclosure Policy | US Consumer Product Safety Commission | Undated/current | https://www.cpsc.gov/vulnerability-disclosure-policy | Institutional VDP and stopping conditions |
| BUG-BOUNTY.md | curl project | Current repository policy | https://github.com/curl/curl/blob/master/docs/BUG-BOUNTY.md | End of curl bounty in January 2026 |
| The end of the curl bug-bounty | Daniel Stenberg, curl maintainer | 2026-01-26 | https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/ | Closure effective 2026-01-31 |
| Google-owned product vulnerability intake | Google | Undated; official index checked 2026-09-14 | https://bughunters.google.com/report/vrp | Broader Google product/service reporting route; dynamic body unavailable |