Bug Bounty Program

A bug bounty program is a standing offer to pay outside researchers for valid security vulnerability reports within a published scope. Also called a vulnerability reward program (VRP), it combines a scope, a severity-to-payout table, safe-harbor terms, and a triage team. A bug bounty program buys discovery. In open source, 2026 proved discovery is no longer the scarce resource.

Mechanically, a bug bounty program is a price signal with three paying parties. The owner pays per valid finding. Researchers pay in hours and choose targets where the expected payout beats the effort. The owner's triage team pays a third cost that rarely appears in the budget: reading, reproducing, and rejecting every report, valid or not. That third cost is what broke in 2026. In nine months, curl shut down its bug bounty, the Internet Bug Bounty paused and Node.js lost its rewards, GitHub gated its public program, and Google stopped paying for product vulnerabilities in its open source projects. Each traces back to the same cause. AI tooling made a plausible report nearly free to produce, and disproving one still costs a maintainer hours.

Our position has two parts. In open source, money should follow remediation, not discovery. And no bug bounty program, however well funded, covers the attack that dominates the software supply chain: a malicious package is not a bug in anyone's scope.

A bug bounty program works as a public contract with four clauses, published before anyone starts testing.

Scope lists the assets that qualify, such as domains, repositories, or release versions, and the classes that do not, such as denial of service or social engineering. Rules of engagement say what testing is allowed, and the safe harbor promises no legal action against good-faith research that follows them. The payout table maps severity to money. Duplicates and already-known issues earn nothing, so only the first valid reporter gets paid. Triage is the people who reproduce each report, rate it, coordinate the fix, and publish a security advisory, usually with a CVE ID.

The front door is a security.txt file served from /.well-known/, defined by RFC 9116. Ours is six lines:

$ curl -s https://socket.dev/.well-known/security.txt
Expires: 2030-01-31T17:00:00.000Z
Contact: mailto:security@socket.dev
Preferred-Languages: en
Canonical: https://socket.dev/.well-known/security.txt
Policy: https://socket.dev/security/disclosure
Hiring: https://socket.dev/careers

RFC 9116 requires only Contact and Expires. The Policy line points at the contract. Our disclosure policy is a small self-hosted program: it pays from $50 for minor issues to $1,000 or more for serious ones, and promises acknowledgment within five business days. It also states a limit that matters later in this article. Our safe harbor cannot authorize research against third-party systems.

Larger programs add tiers and gates. GitHub restructured its program for reports filed on or after July 27, 2026. As of October 2026, the public tier pays one fixed amount per severity: $250 low, $2,000 medium, $5,000 high, $10,000 critical. An invite-only VIP tier pays $30,000 or more for a critical. New researchers below a HackerOne reputation threshold get four initial submissions. GitHub's stated logic: "you don't earn more by submitting more. You earn more by submitting better."

A vulnerability disclosure program (VDP) is the same intake and coordinated disclosure process with no payout table. The choice between them, and the alternatives, comes down to what each one makes you pay for.

The verdict: run a VDP unconditionally, and add money only after triage capacity exists to absorb what the money attracts. The EU Cyber Resilience Act agrees on the baseline. It requires manufacturers to "put in place and enforce a policy on coordinated vulnerability disclosure" and provide a reporting contact, and it requires no bounty. For an open source project in 2026, a funded audit or a remediation grant buys more security per dollar than an open public bounty.

Open source bug bounties collapsed in 2026 because AI tools made reports cheap to produce while triage stayed manual and mostly unpaid. The sequence took nine months.

The numbers explain the mechanism. Daniel Stenberg reported that curl's confirmed rate was "somewhere north of 15%" in earlier years and fell below 5% in 2025. The OpenJS Foundation's Q2 2026 update counts 352 Node.js HackerOne reports over the prior two years, then 65 in March 2026 alone. On Express and Lodash, 70 to 90% of incoming reports are rejected. Every rejected report still costs a maintainer the time to disprove it.

The IBB stated the problem without hedging. Its pause notice on HackerOne says: "The balance between findings and remediation capacity in open source has substantively shifted." The same notice says 80% of IBB rewards supported new findings and 20% supported remediation. That split encoded the old assumption that finding bugs was the hard part.

Removing money did not remove the flood. curl went further and closed security intake from July 1 to August 3 to give its team rest, expecting the deluge to continue. Node.js security maintainer Rafael Gonzaga said the bounty pause "didn't change anything," because many reporters "just want a CVE assigned to their name." The Node.js public-workflow proposal would move most low-severity reports into the open. A CVE credit is a reward too, and it costs the reporter nothing to chase.

AI use is not itself the dividing line. In January 2026, OpenSSL shipped fixes for 12 vulnerabilities reported by AISLE, an AI code-analysis startup. Those reports were tightly scoped, reproducible, and paired with validation. The problem is unvalidated volume pointed at a queue staffed by volunteers.

That is why we joined the OpenJS Foundation's Security Stewardship Program as an inaugural partner. The program splits pooled money equally between bug bounties and maintainers doing triage, patching, backporting, and releases. A 50/50 split is not a law of nature, but it is closer to where the cost now sits than 80/20.

A bug bounty program does not cover malicious code that reaches your build through dependencies. A bounty pays for accidental flaws in code the program owner controls. A malicious package is not a flaw in anyone's code. The attacker is the publisher, the behavior is intended, and there is no vendor whose program it falls under. Malware does not get a CVE, so advisory-driven scanners miss it as well.

Third-party code is usually out of scope by default, with a few deliberate exceptions. Google's open source VRP covers third-party dependencies of Google projects, with prior notification to the dependency. Microsoft's "In Scope by Default" policy, announced December 11, 2025, pays for critical flaws in third-party or open source code that directly affect Microsoft online services. Microsoft's own Open Source Bounty still lists dependency confusion issues as out of scope.

Supply chain compromise of the program owner's own pipeline is a different matter, and it is the category Google kept paying for. As of October 2026, Google's open source VRP pays up to $31,337 for a supply chain compromise of a flagship project such as Go, Angular, or Bazel. In 2021, Alex Birsan's original dependency confusion research earned $30,000 each from Apple, Shopify, and PayPal and $40,000 from Microsoft Azure. Those payouts rewarded flaws in how each company's own builds and tools resolved packages, which fell inside their programs. Nobody paid for spotting an attacker's package in someone else's tree.

The bottom layer is where the malicious packages we report every week live, and it is the layer with no bounty. The defense is to analyze what each package actually does before it is installed, not to wait for someone to be paid to report it.

Bug bounty research becomes a supply chain attack when a researcher publishes a proof-of-concept package to a public registry. A dependency confusion test only works if a real package with a real install-time payload sits on npm or PyPI, where any developer or CI job can pull it. Birsan's tests ran with permission from every target, "either through public bug bounty programs or through private agreements."

Not every researcher asks first. In January 2025, npm packages named after internal Cursor components collected environment variables and sent them to servers controlled by the publisher, which later described them as dependency confusion research. A Cursor developer said the company had not commissioned the work. npm's Open-Source Terms prohibit malicious content and add: "This includes content submitted for research purposes."

A safe harbor protects research against the program owner's systems. The registry, and every unrelated developer who installs a proof-of-concept package, are third parties it cannot cover. If your program scope includes your build pipeline, write the registry rules down. Require an agreed name and a benign payload for any public package. Limit callbacks to data that identifies the host and nothing else, never environment variables or tokens. Require removal of the package as soon as the finding is confirmed.

Setting up a bug bounty program for an open source project starts with intake and a threat model, not money. In the order we would build it:

1. Publish a private intake channel. Add a SECURITY.md and enable GitHub private vulnerability reporting under Settings, then Advanced Security. Qualifying open source projects can also use HackerOne Community Edition for free. curl moved to GitHub and returned to HackerOne within a month, because GitHub could not publish invalid reports or keep team-only comments. Pick the tool that lets you show your rejections.
2. Write the threat model before the payout table. It defines what is not a vulnerability, and it is the document that closes most reports. Node.js has expanded its threat model specifically to narrow what counts as a security report.
3. Decide the advisory path. Know who requests the CVE, either through a CNA such as the OpenJS Foundation or through GitHub Security Advisories, and how the fix release gets coordinated.
4. Gate intake on reproducibility. Node.js now requires reproducible examples in JavaScript. Require a working proof of concept against a supported release, and publish closed reports so reporters can see the bar.
5. Add money last, and pay for fixes too. Fixed payouts beat ranges. Fund the person who reads the queue before you fund the people who fill it.

A minimal SECURITY.md covers the intake channel, points at the threat model, and states the reward position:

# Security Policy

## Reporting
Report vulnerabilities privately via GitHub: Security > Report a vulnerability.
Do not open public issues for security reports.

## Supported versions
Only the latest minor release line receives security fixes.

## What we do not treat as vulnerabilities
See THREAT_MODEL.md. Reports outside it are closed and published.

## Rewards
We do not currently pay bounties.

Every 2026 change worked on the intake side: signal thresholds, submission limits, fixed payouts, reproduction requirements, or no money at all. None of them priced the maintainer's reading time, which is the scarce resource. curl floated a "security report club" with an entrance fee, and a deposit refunded only for legitimate findings, while acknowledging that a fee would unfairly exclude some contributors. Google committed only to an update on its open source product rewards in Q1 2027.

A bug bounty program pays for the finding. Until someone also pays for the reading, open source projects will keep closing their front doors to survive the queue.