Chapter 60 — The offensive program: pentest, red team, bug bounty, VDP

How it works

A Vulnerability Disclosure Program (VDP) — the free, foundational baseline every organisation should have:

   A VDP is a published policy telling security researchers: here's how
   to report a vulnerability to us, here's our scope, and here's our
   promise not to pursue legal action against GOOD-FAITH reports made
   within that scope (a "safe harbor" clause -- this is the legal
   protection G1 Ch 0.6's "responsible disclosure" advice depends on
   existing on the RECEIVING end).
   MECHANICS:
     - a `/.well-known/security.txt` file (RFC 9116) pointing researchers
       to your policy and a contact channel -- the single cheapest,
       highest-leverage thing an organisation with NO offensive-security
       budget at all can do TODAY.
     - published disclosure/handling standards to model the policy on:
       ISO/IEC 29147 (vulnerability disclosure) and 30111 (vulnerability
       handling processes).
     - NO bounty payment required -- a VDP's value is the safe-harbor
       legal clarity and the channel itself, not compensation; you can
       add a bounty later (below) once the program is mature enough to
       handle the volume and triage load.
   A VDP is APPROPRIATE FOR EVERY ORGANISATION, immediately, regardless
   of security program maturity -- there is essentially no reason not to
   have one.

Bug bounty programs — paid, scoped, and a real triage commitment:

   Once a VDP is running smoothly (reports are being triaged promptly,
   findings are flowing into the vulnerability-management pipeline,
   Ch 59), a PAID bounty program is the natural next step:
     PLATFORMS: HackerOne, Bugcrowd, Intigriti (managed triage support,
       a built-in researcher community) vs self-hosted (more control,
       no platform fee, but you own 100% of the triage load).
     PROGRESSION: PRIVATE/invite-only (a small, vetted researcher pool,
       lower volume, good for testing your triage process before going
       wider) -> PUBLIC (anyone can participate, much higher volume and
       coverage, requires a mature, well-resourced triage function).
     SCOPE: precisely defined in/out-of-scope assets and vulnerability
       classes -- an ambiguous scope produces both wasted researcher
       effort and disputes over reward eligibility.
     REWARD TIERS by severity (using the same CVSS/impact framing as the
       rest of your vulnerability-management practice, Ch 59, so bounty
       findings integrate into the same prioritisation, not a parallel
       scale).
     THE REAL COST IS TRIAGE, not the bounty payouts themselves --
       under-resourcing the team that reviews incoming reports leads to
       slow response times, frustrated researchers, public criticism, and
       eventually researchers deprioritising your program in favour of
       ones that respond faster. Budget for triage capacity BEFORE
       launching, especially before going public.
     DUPLICATE MANAGEMENT and avoiding TRIAGE BURNOUT are real, ongoing
       operational concerns at any meaningful volume -- most platforms
       provide tooling for deduplication, but the human triage judgment
       calls (is this a legitimate duplicate? does this report actually
       demonstrate impact?) don't fully automate away.

Penetration tests — scoped, time-boxed, methodology-driven:

   SCOPING: black-box (no information given, closest to a real external
     attacker's starting position), grey-box (some information/limited
     access, most common and often most cost-effective -- avoids wasting
     expensive tester time on pure reconnaissance you could have just
     told them), white-box (full source/architecture access, deepest
     coverage per hour, best for complex or high-value targets).
   SELECTING A VENDOR: relevant certifications (OSCP/OSCE/CREST or
     equivalent for the testers actually assigned, not just the firm's
     marketing), a published or requestable METHODOLOGY (PTES -- the
     Penetration Testing Execution Standard, or OWASP WSTG for web-
     specific engagements) rather than "trust us", and REFERENCES from
     past clients in your industry/stack.
   RULES OF ENGAGEMENT: a written document -- scope, timing/blackout
     windows, emergency contact and stop-work procedure, what's explicitly
     OUT of scope (e.g. no destructive testing against production without
     separate, explicit sign-off), and legal authorisation (this is
     exactly the "written permission" G1 Ch 0.6 requires for any offensive
     activity, formalised as a contract).
   THE REPORT AND WHAT HAPPENS NEXT: a pentest report that sits in a
     shared drive unread is money wasted. Every finding goes into the
     SAME vulnerability-management pipeline (Ch 59) with the SAME
     prioritisation and SLA discipline as any other source, and a
     RE-TEST (often included in the engagement, or a cheap follow-up) is
     how you PROVE remediation rather than assuming the fix worked.

Red team engagements — objective-based, testing detection and response, not just finding vulnerabilities:

   DIFFERENCE FROM A PENTEST: a pentest asks "how many vulnerabilities
   can you find in this scope, in this time-box?" A red team engagement
   asks "can you achieve THIS SPECIFIC OBJECTIVE (e.g. reach the
   per-tenant KMS keys, Part 7 Ch 44, or exfiltrate a sample of
   RESTRICTED customer data) WITHOUT BEING DETECTED, and if you are
   detected, how did our response actually go?" -- it tests PEOPLE and
   PROCESS (Part 8's detection and Ch 55's response) as much as
   technology.
   PREREQUISITES: red team engagements are usually only worth the cost
   ONCE a detection program (Part 8) is mature enough to plausibly catch
   something -- running a full red team against an organisation with
   near-zero detection capability mostly just re-confirms "yes, you have
   no detection", which a much cheaper conversation could have
   established. PURPLE TEAMING (Part 1 Ch 2) is frequently BETTER ROI
   than a pure, secretive red team for most organisations, specifically
   because it's collaborative and directly builds detection coverage
   rather than just scoring a single stealthy campaign.
   GOVERNANCE: requires EXECUTIVE SPONSORSHIP, explicit legal/HR
   coordination (a red team that social-engineers real employees or
   tests physical security has real organisational and sometimes legal
   implications distinct from a pure technical pentest), and a clear,
   documented "get out of jail free" authorisation that names exactly
   what's in scope, held by both the red team and a small, informed set
   of defenders (a "white cell") who can vouch for the activity if it's
   detected mid-engagement.

The maturity progression, and the one rule that ties it all together:

   VDP (always, from day one)
     -> private/invite bug bounty (once triage capacity exists)
       -> public bug bounty (once triage is proven at smaller scale)
         -> periodic pentests (for compliance, major releases, or
            specific high-value systems needing white/grey-box depth a
            bounty program's incentive structure doesn't naturally
            produce)
           -> red team engagements (once detection, Part 8, is mature
              enough to be worth testing) -- often via purple teaming
              (Part 1 Ch 2) first, graduating to fuller red team
              exercises as the program matures.

   THE RULE: regardless of source -- a researcher's VDP report, a bounty
   submission, a pentest finding, or a red team's after-action report --
   EVERY finding lands in the SAME vulnerability-management pipeline
   (Ch 59), with the SAME prioritisation discipline, tracked to closure
   with the SAME rigour. An offensive-testing program that produces
   excellent findings which then sit unfixed in a report is strictly
   worse than not testing at all -- it creates documented knowledge of
   the exposure with no corresponding action, which is a liability in
   its own right if it's ever discovered during litigation or a breach
   investigation.