The three are often presented as levels of the same thing, as if a red team were a better penetration test and a bug bounty a cheaper one. They are not. Each answers a different question, and the wrong choice gives a precise answer to a question you did not ask.
Three questions
A penetration test asks: what vulnerabilities does this system have? A contracted team examines an agreed scope for an agreed time and reports everything it found, together with what it covered. The value is in the coverage: you know what was tested and how.
A bug bounty asks: what can people outside find that we missed? Independent researchers look at what interests them, for as long as they like, and are paid for valid findings. The value is in the diversity and the persistence. Nobody promises coverage.
A red team operation asks: would we notice an attack, and could we stop it? A team pursues a concrete objective the way a real adversary would, while your defenders do not know. The value is in what it shows about detection and response. Finding many vulnerabilities is not the goal; reaching the objective through one is enough.
Side by side
| Criterion | Penetration test | Bug bounty | Red team |
|---|---|---|---|
| Question | What is vulnerable? | What did we miss? | Would we notice? |
| Scope | Agreed, fixed | Published, open-ended | Defined by objectives |
| Duration | Days to weeks | Continuous | Weeks to months |
| Who knows | Everyone | Everyone | A small control group |
| Coverage | Documented | Not guaranteed | Not the purpose |
| Payment | For the work | For valid findings | For the work |
| Result | Report with all findings | A stream of reports | Attack narrative and detection gaps |
The usual order
Most organisations should take these steps in order, because each is wasted without the one before it.
- Penetration test. Find and fix what a systematic examination finds. This is also what auditors and customers ask for.
- Disclosure policy. Publish a channel for reports from outside. It costs little and it is the baseline for everything that follows.
- Private bug bounty. Invite a limited group of researchers to a scope that has already been tested. Rewards are then paid for what is hard to find.
- Public bug bounty. Open the program when response times and fix times hold under the private one.
- Red team. Test detection and response when the basic vulnerabilities are gone and a team exists whose work can be tested.
Starting at the end is expensive. A public bug bounty on an untested application pays high rewards for findings that a fixed-price test would have delivered in its first days. A red team operation against an organisation with no monitoring proves in a week what was known in advance.
When the order changes
- A regulator prescribes the test. Threat-led penetration testing under DORA is a red team exercise with a defined structure. If you are in scope, the question is not whether but how.
- The product ships every week. A yearly test describes a system that no longer exists. Continuous testing replaces the single engagement.
- The system holds funds directly. For smart contracts the audit comes before deployment, and a bounty with meaningful rewards starts on the day of deployment.
What to ask a provider
- What exactly will be covered, and how will I see that it was?
- Who will do the work, and who reviews the report?
- What happens when a critical vulnerability is found on the second day?
- Is a retest included, and until when?
- What do you need from us to start?
A provider who cannot answer the first question is selling time, not assurance.
In short
Choose the penetration test when you need to know the state of a system. Choose the bug bounty when you know it and want to find out what you missed. Choose the red team when you want to test the people and the processes that are supposed to notice. If you are not sure which question is yours, describe the situation and we will say which one we would start with, and why.