Fund a Bug Bounty or CVE Research Project From Followers

Independent security researchers can fund a bug bounty or CVE research project by setting a Goal on Brillay with a stated target (lab hardware, disclosure time, tooling) and a visible progress bar, letting followers back the research directly instead of waiting on a single vendor payout. A Goal is one named goal with a progress bar: followers make one-time contributions and every contribution is yours whether or not the goal is reached — no deadline unless you set one, and nothing to ship.

Each contribution is one-time, and supporters do not need an account to pay; the fee that applies is outlined on the pricing page.

Vulnerability research is unpaid until a finding lands: triage, reproduction, write-up, and coordinated disclosure all happen before any bounty check clears, if one clears at all. HackerOne's 9th Annual Hacker-Powered Security Report found that bug bounty programs on its platform collectively paid researchers $81 million, a 13% increase over the prior year (HackerOne press release). That money is also concentrated: HackerOne's same 9th Annual Hacker-Powered Security Report reports that the platform's top 10 programs alone accounted for $21.6 million of the $81 million paid out (HackerOne — Hacker-Powered Security Report, 9th Edition), so the exploratory hours that lead to a finding are rarely what gets rewarded.

What counts as a fundable research project?

A fundable research project is a scoped piece of independent security work with a named target, a stated budget, and a stopping point — reverse-engineering one device class, auditing an open-source dependency for a specific bug class, or covering the disclosure work behind a single CVE candidate. An open-ended "pay me to hack things" ask is not fundable.

On Brillay, the researcher sets a target amount and description for a scoped Goal, supporters contribute one time toward it, and a progress bar shows how close it is to funded (how it works). A Goal collects one-time contributions toward a stated research target, with no reward tiers and nothing to ship; contributions support the research effort itself rather than buy equity or guarantee a deliverable.

Typical funded scopes include a specific target device or codebase, the disclosure-coordination window itself, testing hardware or lab time, or a defined research sprint (for example, "two weeks auditing this library's auth flow"). Naming the scope up front is what makes a research ask fundable rather than vague. Scale is the reason a named target matters: the CVE Program's own site states that more than 367,000 CVE Records are currently accessible by keyword search or download (CVE.org), so "security research" as a category tells a backer nothing until a researcher names the thing being researched.

Is this different from a company's bug bounty program?

Yes. A Brillay Goal funds a researcher's time before or alongside any bounty submission, while a vendor's bug bounty program pays only for an accepted, validated finding on the vendor's own severity scale and process. The two run in parallel: supporters fund the work, and the vendor's program (if one exists) rewards the report.

Corporate and platform bounty programs operate at a different scale from Brillay: HackerOne's 9th Annual Hacker-Powered Security Report draws on more than 580,000 validated vulnerabilities reported to date across nearly 2,000 enterprise programs active in the past year. Bug bounty payouts on HackerOne are earned per validated report, after vendor triage, and are entirely separate from any Brillay goal.

A Goal instead funds the researcher directly, on the researcher's own timeline, regardless of whether any single submission is ultimately accepted or rewarded. Funding the work up front and getting paid per accepted finding are two different economics, and a researcher can use both at once.

How do you write a fundable project description?

A fundable project description names the research target, the deliverable, the budget line items, and what happens with the outcome. If asking for donations feels awkward, name the target, the amount you need, what the money covers, and when the research sprint ends so supporters know exactly what they are helping fund.

Include what you're researching, why it matters, what the money covers, and what supporters can expect you to share after responsible disclosure—without promising a reward or guaranteed deliverable. Do not promise access to unpatched vulnerability details before disclosure, because early release would undercut the coordinated-disclosure process the research depends on.

The CVE Program's own numbering authorities and rules govern CVE assignment. A CVE Numbering Authority (CNA) assigns and publishes a record only once a report meets the published criteria, and the CVE Board approved CNA Operational Rules Version 4.2.0 on August 20, 2026, effective August 25, 2026. Funding covers a researcher's ability to do the work; funding does not shortcut or replace CVE assignment. Finding the right CNA is itself part of the funded disclosure work: the CVE Program's Q1 CY 2026 report counts 514 partner organizations — 511 CNAs and 3 CNAs of Last Resort — across 43 countries (CVE.org — Q1 2026 Program Report).

Should this be a funded goal or a paid Q&A instead?

Use a Goal to fund your own open-ended research, and use Paid Questions when someone else wants a quick expert opinion on something specific. A Goal can bring together one-time contributions from several supporters; Paid Questions let a follower pay your set price to ask you one private question, and you send back one written reply, privately, so price and describe them separately.

Paid Questions fit a narrow, one-off ask — "does this link look like phishing?" — where a supporter pays for a written answer to their question, and the creator replies in writing on their own time. Independent CVE research, by contrast, has no single asking supporter and is funded by many people backing a goal the researcher defined.

Most independent researchers fit this work around employment: 81% of the more than 2,000 hackers surveyed for Bugcrowd's Inside the Mind of a Hacker 2026 report work full-time in a security-related field (Bugcrowd — Inside the Mind of a Hacker), and a Goal lets supporters fund those research hours with one-time contributions.

If a supporter instead wants a structured audit of their product or codebase rather than your independent research, that work is a paid deliverable rather than a goal. Scope a paid audit separately from a research fund so backers never confuse "support my research" with "hire me for a security review."

How does CVE and disclosure timing affect a funded project?

Disclosure timing on a funded research project is set by the CVE Program, the affected vendor, and any coordinating body — never by the goal. A CVE Record publishes only after a CNA processes and releases it, so a project description should warn backers that disclosure can lag the funded research by weeks or months.

Published output is steady but externally paced: the CVE Program's own quarterly report recorded 12,796 CVE Records published in Q4 CY 2025, a 9% increase over the 11,738 records published in Q3 CY 2025. Enrichment behind those records is under strain — NIST has said its National Vulnerability Database cannot keep pace with submission volume:

"We enriched nearly 42,000 CVEs in 2025 — 45% more than any prior year. But this increased productivity is not enough to keep up with growing submissions." — NIST, April 2026

Vendor-facing deadlines are equally external to any funding page. Google Project Zero publishes a fixed deadline policy that researchers frequently adopt as a reference point:

"Project Zero follows a 90+30 disclosure deadline policy, which means that a vendor has 90 days after Project Zero notifies them about a security vulnerability to make a patch available to users." — Google Project Zero, Vulnerability Disclosure Policy

Coordinators apply their own clocks too: CISA states that where a vendor is unresponsive or will not commit to a reasonable remediation timeframe, CISA may disclose a vulnerability as early as 45 days after initial contact (CISA — Coordinated Vulnerability Disclosure Program). Set supporter expectations around the vendor, coordinator, and CVE Program timelines: fund the research phase, then explain through your usual channel that disclosure and CVE publication are outside your control.

What should the goal actually cover?

A goal should cover concrete, named research costs rather than a general living stipend, because a named cost lets a supporter see exactly what a contribution buys. Common line items include lab or test hardware, cloud and VM time for fuzzing or analysis, dataset or tool licenses, and blocked-off research hours aimed at one specific target — the same named-cost structure works for crowdfunding an open dataset release when the deliverable is data rather than a vulnerability report.

Tool licenses are the easiest line item for a backer to picture, because they carry a published price: PortSwigger's own store lists Burp Suite Professional at $499 per user per year (PortSwigger — Buy Burp Suite Professional). The four fund targets in this section's table are illustrative starting points rather than a pricing guarantee, because actual costs depend on the research target, the tooling involved, and the researcher's own pace. Build the goal amount from named costs—for example, a $499 Burp Suite Professional license plus hardware and blocked-off research time—and choose whether supporters see exact progress, a percentage, or no progress figure.

Frequently asked questions

You can launch a Goal without a certification, a large following, or platform approval—start with one named cost that a small group of supporters can understand. The answers below cover Brillay's fee, what supporters can see before disclosure, and when to use a Goal instead of selling a paid security audit.

Does Brillay pay out bug bounties itself?

No. A Goal funds independent research time, and any per-finding bounty still comes from the vendor or platform whose bug bounty program the researcher submits to.

Can backers see the vulnerability details before disclosure?

In your Goal description, explain the research scope without publishing unpatched vulnerability details before coordinated disclosure completes. Share safe progress updates through your usual channel, but do not publish exploit details that could put users at risk before a fix ships.

What's the difference between this and a paid security audit?

A funded Goal supports a researcher's own work, while a paid security audit is a defined deliverable for one client, sold through Custom Work with a set price and delivery time. If a supporter wants a review of their codebase rather than funding for independent research, that request is a service, not a goal.

What does Brillay charge on a funded project?

No monthly fee, you only pay a small platform fee when you get paid. 8% platform fee when a follower pays for work, 5% platform fee on tips and goals. Card processing is separate: Stripe pays you out in 41 supported countries after you connect your bank, and its published US rate of 2.9% + 30¢ per successful card transaction, plus 1.5% for international cards, applies on top of Brillay's fee (Stripe — Pricing & Fees).

Do I need to be a professional pentester to fund research this way?

You can create a Goal without a professional certification.

Create your free Brillay page and put Goals, Paid Questions, and Custom Work in the one link you already share.