Vulnerability Disclosure Program
A standing safe channel for unsolicited reports. Recognition rather than reward, no audience to manage.
Program design
Choose the right shape
Nine ways to structure a security program
A program model is the contract between your organisation and the people testing it: who may test, what they may test, how findings are rewarded, and how public the process is.
Models can run in parallel against the same scope — most mature programs use more than one.
Platform viewLive
- Submittednew
- Triagedvalid
- Duplicate checkclear
- Rewardapproved
The models
What each model is for
Pick by how much control you need, whether you are paying for findings, and how sensitive the targets are.
Responsible Disclosure Program
Disclosure with a formal coordination process and defined timelines — for organisations that need the paper trail.
Private Bug Bounty
Invited researchers only, rewarded per validated finding. The usual starting point before a program goes public.
Hybrid Bug Bounty
A trusted core plus a wider audience, opened in phases once triage volume is understood.
Ad hoc and time-limited bounty
A defined audience and window for a specific release, migration, launch or compliance deadline.
Challenges and contests
Competitive formats aimed at a specific problem, a target class or community recruitment.
Crowdsourced security testing
A vetted community on a structured engagement — more control than an open bounty, more breadth than a boutique test.
PTaaS engagement
Certified experts, named testers, scheduled depth and evidence built for review.
Combined programs
Disclosure as the always-on channel, a bounty for continuous coverage, expert engagements for scheduled depth.
At a glance
Choosing between the models
The three questions that usually settle it: depth or breadth, paying or not, and how sensitive the target is.
| Capability | Disclosure | Crowd-sourced bounty | Expert engagement |
|---|---|---|---|
| Who tests | Anyone following policy | Invited or public researchers | Certified, named experts |
| Continuous coverage | |||
| Scheduled depth | |||
| Rewarded findings | Contractual | ||
| Evidence for auditors | |||
| Rules of engagement | |||
| Source code review | |||
| Certification artefacts | |||
| Access to internal systems |
Source code review, retesting, VPN access and compliance exports are Professional-tier. Dedicated tester pools and SLA guarantees are Enterprise-tier.
Common machinery
What every model shares
Because the machinery is shared, changing or adding a model does not mean rebuilding your process.
- 01
Scope
In-scope and out-of-scope assets, grouped by type, tier and priority.
- 02
Rules and governance
Engagement policy, participation requirements and approval queues.
- 03
Onboarding
Invitations, policy or NDA acceptance, and participation status.
- 04
Communications
Program announcements, realtime chat and retained history.
- 05
Report handling
Classification, duplicate checks, reviewer guidance and lifecycle state.
- 06
Remediation and money
Ownership and deadlines, proof of closure, rewards and metering.
Documentation
Model selection, in detail
Program models
All nine models, what each is for and how to combine them.
Read the docScope and rules of engagement
What to write into the policy for each model.
Read the docPTaaS engagement lifecycle
The expert-led model from planning to certification.
Read the docCommon questions
Program design questions we hear most
Where should we start?
Most organisations start with disclosure — it establishes scope, response habits and a safe inbound channel with no reward budget. A private bounty on a defined asset set usually comes next.
Can we change models later?
Yes. Scope, severity bands, rules of engagement and the triage pipeline are shared, so moving from private to hybrid or adding expert engagements reuses the work already done.
Do we need a bounty if we buy expert testing?
Not necessarily, but they answer different questions. Expert engagements give scheduled depth and evidence; a bounty keeps testing running between engagements. Most programs eventually run both.
How do we avoid testing the same things twice?
Because both models read the same scope definition, a target is defined once. Coverage is a planning question, not a duplication problem.
Not sure which model fits?
Tell us the assets, the constraints and what your stakeholders need to see. We will recommend a model and a rollout order rather than a menu.