Bug Bounty & Crowdsourced Security: What a Good Programme Actually Optimises

The distinction matters.

Coordinated vulnerability disclosure provides a route for reporting and coordinating vulnerabilities.

Bug bounty adds an incentive and market mechanism.

A bounty programme therefore also has to define things such as:

• reward eligibility;
• bounty ranges;
• severity/impact logic;
• duplicate rules;
• first-to-report treatment;
• researcher reputation;
• dispute handling;
• payment operations;
• private invitations and campaigns.

The presence of a reward does not change the underlying security rules:

• scope;
• authorised methods;
• minimum sufficient proof;
• data minimisation;
• coordinated disclosure.

For the operating-model distinction, see CVD, Bug Bounty and Penetration Testing Are Not the Same Thing.

High submission volume can indicate:

• broad attack surface;
• healthy researcher participation;
• newly added scope;
• weak submission quality;
• one systemic issue fragmented into many reports;
• unresolved known vulnerabilities repeatedly rediscovered;
• automation-driven triage load.

So:

A mature programme is more interested in:

than raw intake volume.

That distinction is increasingly important as platforms report growing submission volume and more demanding triage conditions in 2026.5

“Paid out $1 million” is not, by itself, a security outcome.

High spend can mean:

• valuable findings;
• a large programme;
• competitive market rates;
• broad researcher participation;
• aggressive bonus campaigns;
• recurring defects that the secure-development lifecycle keeps reintroducing.

Bounty spend needs context.

What matters includes:

• which asset classes attracted attention;
• how many findings represented new root causes;
• how many were actually remediated;
• whether recurring classes declined;
• whether the programme discovered blind spots;
• whether findings changed secure-development controls.

Bug bounty is not simply the purchase of vulnerabilities.

It is a market for external, competitive researcher attention.

A capable researcher has alternatives.

The same week can be spent on:

• your programme;
• another public bounty;
• a private invitation;
• paid penetration testing;
• independent research;
• exploit development;
• open-source work;
• training.

Opportunity cost is real.

ENISA's work on vulnerability-disclosure economics has long noted that researchers are motivated by combinations of financial reward, reputation, career value, learning, challenge and ethical considerations.1

YesWeHack's 2026 hunter survey similarly found that private-program invitations were a major motivation for roughly half of surveyed hunters, while bounty ranges, newly added scope, broad targets and technology fit also influenced programme choice.4

That is a survey of one platform ecosystem, not a universal researcher census.

But it points to the right design question:

Why should a strong researcher spend time on this programme rather than somewhere else?

A programme can be legally clear while economically uninteresting.

For example:

The programme exists.

Researcher attention may not.

At the opposite extreme, an organisation can publish an enormous scope without having the triage or remediation capacity to absorb what comes back.

HackerOne's 2026 Bug Bounty Maturity Framework emphasises clear asset scope, testing support and operational capacity. Its most expansive coverage model is explicitly an aspirational practice requiring strong asset inventory and triage capability.6

A useful scope decision therefore combines:

not only:

A mature bounty programme also needs an explicit layer between scope and finding.

The useful chain is:

scope and policy → permission → reconnaissance / observation → evidence-backed candidate → human validation → finding → report

This distinction matters because an observed endpoint, technology fingerprint, object identifier or unusual response is not yet a vulnerability. It is evidence that may justify a controlled validation step. The candidate should retain where the observation came from, which scope rule applied, what action produced it and which next actions are allowed, blocked or require confirmation.

Reconnaissance is a good place for bounded automation. YesWeHack's Rabhi describes automating recon while keeping deeper vulnerability testing manual, and PortSwigger's current workflow similarly separates scope and attack-surface mapping from vulnerability testing.1516

The programme should therefore optimise for explainable candidates, not raw scanner volume. Discovery tooling must never expand scope on its own, and a candidate must not become a finding until a human or an equivalently controlled validation process has demonstrated the security condition.

A newly launched:

• API;
• mobile build;
• authentication flow;
• payment feature;
• AI capability;
• enterprise workflow

can attract much more serious research than a scope that has been mined for years.

In YesWeHack's 2026 survey, 42% of surveyed hunters prioritised recently added scope, while long-established targets attracted substantially less interest.4

That does not make old assets safe.

It means programmes need ways to refresh attention:

• new scope;
• time-bound campaigns;
• focus bounties;
• specialist invitations;
• targeted vulnerability classes;
• temporarily increased rewards.

In this sense, a bounty programme is partly an attention-allocation system.

A weak reward policy says:

Reward depends on impact at our discretion.

That preserves organisational flexibility.

It creates price uncertainty for the researcher.

A stronger programme explains:

• severity bands;
• asset criticality;
• how business impact affects reward;
• treatment of attack chains;
• systemic issues;
• known issues;
• duplicate logic;
• bonus conditions;
• exclusions.

HackerOne's 2026 maturity guidance recommends non-subjective bounty tables with concrete examples and clear impact-based payment principles.6

Intigriti similarly recommends transparent reward policies covering duplicates, bonuses, exceptional rewards and the factors influencing custom bounty decisions.11

Predictability is part of the compensation.

The researcher does not need to know the exact amount in advance.

They should be able to predict the order of magnitude and the rules.

Bug bounty creates a natural incentive:

That is not a moral failure.

It is an economic property of the system.

The programme should separate:

1. technical severity;
2. actual business/security impact;
3. reward policy;
4. internal risk treatment.

They can correlate.

They are not identical.

HackerOne uses severity as one input for structuring bounty ranges, while its own platform standards distinguish severity assessment from the programme's final risk-treatment decision.89

Intigriti's triage standards make a similar point: platform severity is not automatically equivalent to organisational importance or risk.13

A useful severity dispute therefore asks:

Which demonstrated preconditions, exploitation steps and impacts support the assessment?

not merely:

Which side wants Critical?

Most bounty systems are first-to-report.

That makes sense.

Paying the full reward twice for the same root cause usually creates little additional security value.

But:

duplicate ≠ false finding duplicate ≠ bad researcher

Bugcrowd's current reward model even grants reputation/kudos points for certain higher-priority duplicate submissions once the original issue is accepted.10

Intigriti's 2026 handling guidance defines duplicates around the underlying vulnerability and the same remediation: if two reports share the same root cause and would be fixed by the same change, duplicate treatment is appropriate. A similar vulnerability requiring a different fix may be a related but distinct finding.12

That gives a much more useful test:

Suppose a researcher finds one broken-authorisation endpoint.

The same defective authorisation function is then found across forty endpoints.

Two extremes are bad.

Pay forty full bounties. That incentivises artificial fragmentation.

Pay only for the first URL and treat all additional analysis as worthless. That discourages root-cause investigation and systemic-impact discovery.

HackerOne's platform standards address this by recommending compensation for additional value, rather than simply counting reports.9

A practical programme should distinguish:

• first manifestation;
• root-cause identification;
• materially new impact;
• new privilege boundary;
• different asset class;
• novel exploit chain;
• another URL exposing the same defect.

The programme should reward security value, not formatting.

Consider a Critical vulnerability that remains unresolved for eighteen months.

Independent researchers keep rediscovering it.

To the programme, each later report is a duplicate.

To the researcher:

I independently spent time and found a real vulnerability that is still exploitable.

That creates a fairness problem.

HackerOne's 2026 maturity framework recommends that mature programmes explicitly document how they handle long-lived unresolved duplicates, including possible time-bound deduplication windows or graduated rewards in some cases.6

That is platform guidance, not an industry-wide rule.

But the underlying problem is valid:

When an organisation chooses to leave a vulnerability exposed for a long period, all of the rediscovery cost should not automatically be externalised to future researchers.

Researchers spend more than technical time.

They also absorb waiting risk.

A programme that:

• does not answer for a month;
• argues severity for another month;
• finally declares duplicate after ninety days;
• pays six months later

has worse researcher economics than its bounty table suggests.

HackerOne's maturity framework recommends explicit first-human-response and triage targets, along with status updates on long-running reports.6

Intigriti also ties structured submission handling to efficient remediation, fair researcher evaluation and long-term programme quality.12

Communication latency is therefore an economic programme parameter.

Once a finding is validated and a reward has been decided, the researcher should not become an involuntary lender to the programme.

Payment may legitimately require:

• identity checks;
• tax information;
• sanctions/compliance screening;
• payment-provider processing.

The programme should still make sure that:

• bounty funds exist;
• the amount is reserved where necessary;
• payment status is visible;
• timelines are understandable;
• budget exhaustion does not surprise researchers after valid work has been accepted.

Intigriti's platform, for example, reserves budget during submission validation and can automatically suspend a programme when available bounty budget falls below the configured threshold, explicitly to maintain payment control.14

The broader principle is simple:

Do not invite researchers to create payable security value if the programme is not financially prepared to pay for it.

A public platform can expose a programme to thousands of potential researchers.

That does not mean thousands will meaningfully study the product.

Returning researchers can create a different kind of value:

A researcher who knows the system can reach layers that drive-by scanning never reaches.

HackerOne's 2026 Hacker Engagement dashboard includes unique researcher participation and related engagement metrics, reflecting the operational importance of sustained participation.7

Retention should not become a closed club.

A healthy programme needs both:

• repeat high-quality researchers;
• accessible entry paths for new talent.

It is tempting to draw:

as a universal progression.

It is not.

A public programme can be appropriate for one organisation and reckless for another.

Critical systems, highly sensitive data or narrow production tolerances may justify:

• invite-only scope;
• vetted researchers;
• identity verification;
• scheduled test windows;
• sandboxes;
• enhanced monitoring;
• emergency-stop procedures.

ENISA's CVD work has also noted that bug bounty can be valuable in some contexts while cost, sensitive data and trade-secret exposure can make broad bounty models unsuitable elsewhere.2

The better question is:

Which external-research model can this organisation safely and competently operate?

Platforms use reputation, signal, rankings and private invitations for good reasons.

A researcher with a consistent record can be a strong candidate for:

• sensitive scope;
• a specialist campaign;
• a pre-release programme;
• complex business logic.

But:

Evidence determines whether the vulnerability exists.

Reputation can help decide where scarce triage and invitation capacity goes.

It should not replace reproduction.

Hall-of-Fame entries, CVE credit, public thanks, testimonials, private invitations and other recognition can have real value.

ENISA's economic work explicitly identifies reputation and career benefits as researcher incentives.1

But an organisation should not use:

We will thank you publicly

as a substitute for a bounty it explicitly promised for qualifying work.

Financial and non-financial incentives complement each other.

They are not interchangeable in every context.

If I had to choose one programme output unit, I would not choose report.

I would choose:

a unique, verified security insight that causes a concrete change in security state.

That can be:

• one specific vulnerability;
• a systemic root cause;
• a novel attack chain;
• a variant that materially changes impact;
• an architectural security-boundary defect.

This connects crowdsourced research to actual assurance.

Without that connection, bug bounty can become a parallel ticket factory.

Signal quality

• valid-report ratio;
• duplicate ratio;
• needs-more-information ratio;
• no-security-impact ratio;
• unique root causes;
• materially new-impact findings.

Researcher economics

• first human response time;
• triage time;
• bounty-decision time;
• payout time;
• dispute rate;
• severity-change rate;
• returning-researcher rate;
• retention of consistently useful researchers.

Coverage

• percentage of critical assets receiving real researcher attention;
• findings by asset class;
• findings on newly added scope;
• findings on historically under-tested areas;
• specialist-campaign coverage;
• new vulnerability classes discovered.

Remediation outcomes

• time to mitigation;
• time to fix;
• retest coverage;
• failed-retest rate;
• reopened findings;
• repeated root causes;
• variants found after closure.

Programme safety

• accidental-impact incidents;
• scope disputes;
• data-handling incidents;
• rate-limit/DoS violations;
• legal escalations.

No single metric should become the KPI.

Together they describe programme health.

Not as a mathematical model, but as a programme-design test:

Notice what is not in the objective:

Reports are input.

Security improvement is the outcome.

Before opening a bounty, I would want answers in four groups.

Scope

• Which assets are in scope?
• Which assets are out?
• Which third-party systems are outside our authority?
• How are test accounts provided?
• Which techniques are prohibited?
• How does emergency stop work?

Rewards

• How does severity/impact map to bounty?
• Does asset criticality change reward?
• How are attack chains handled?
• What is a duplicate?
• How are systemic issues rewarded?
• What happens with known but unresolved findings?
• When are bonuses possible?

Operations

• What is the first-human-response target?
• Who performs triage?
• Who decides severity and reward?
• How are disputes handled?
• What is the payout process?
• What happens if budget runs low?

Remediation readiness

• Who owns the fix?
• Can the researcher retest?
• How are long-lived findings handled?
• When is disclosure considered?
• How does the finding enter the Secure SDLC feedback loop?

If the last group has no answers, the organisation is not ready for a bug bounty programme.

It is ready only to receive more reports.

One of the worst possible interpretations is:

We do not need to build securely; the crowd will find it.

Crowdsourced research is unusually good at:

• external adversarial perspective;
• unexpected attack chains;
• diverse techniques;
• production-reality testing;
• continuous pressure over time.

It is not a replacement for:

• threat modelling;
• secure coding;
• code review;
• SAST/DAST;
• dependency management;
• penetration testing;
• architecture review;
• access-control design;
• release gates.

ENISA's work on national vulnerability programmes has explicitly framed this as a policy tension between “paying by impact” through bounty models and continuing to invest in security-by-design and preventive capability.3

A bounty programme should find the residual mistakes.

It should not be the organisation's outsourced conscience.

If a researcher finds an IDOR, the question is not only:

Which endpoint is broken?

It is also:

Why did our authorisation design or test coverage allow this class of defect, and where else does the pattern exist?

If the finding is SSRF:

Which design boundary allowed untrusted input to reach a network fetch capability?

If it is business-logic abuse:

Which product invariant was never formalised or tested?

The mature flow is:

Otherwise, a programme can spend years paying for the same class of mistake in different places.

I would reduce it to six objectives.

1. The right researcher attention

Not the largest possible crowd, but enough relevant expertise on the assets that matter.

2. Novel signal

Not maximum submission count, but new security knowledge.

3. Fair and predictable economics

Researchers can understand scope, reward, duplicate, timing and dispute rules.

4. Low coordination friction

Responsive communication, consistent triage and explainable decisions.

5. Remediation conversion

The finding changes the actual security state.

6. Organisational learning

Root cause feeds back into Secure SDLC rather than ending at Resolved.

A programme designed this way is not trying to buy bugs.

It is using an external researcher market as one layer of security assurance.

A bug bounty programme is not good because many hackers join it.

It is not good because it pays large bounties.

It is not good because a dashboard shows a rising count of Critical reports.

It is good if it can repeatedly do something harder:

attract high-quality external attention to the areas where it matters, reward genuinely new security value fairly, and convert the resulting findings into verified security improvement.

The central unit is therefore not the bounty.

It is not the report.

It is the chain:

trusted researcher → unique evidence → fair decision → remediation → retest → learning.

When that chain works, bounty is a security instrument.

When it does not, it is an expensive submission stream.

Sources checked on 25 September 2026. Platform rules and reward models change over time. The objective function, metric groups and programme-design model proposed here are the author's analytical framework, not a single standard issued by HackerOne, Bugcrowd, Intigriti, YesWeHack or ENISA.

This article analyses bug bounty and crowdsourced-security programme design. It is not legal advice about any specific platform or reward policy.