Exercise 3: Scoped-Engagement Authorization vs. Bug Bounty Authorization — Possible Solution ==================================================================== HOW A FORMALLY SCOPED PENTEST'S AUTHORIZATION WORKS ------------------------------ Per this chapter's own explanation, a formal penetration test is authorized through a written scope agreement or Rules of Engagement (RoE) document, individually signed by someone with real, specific legal authority over the exact systems being tested. This is a one-to-one arrangement: a specific tester (or firm) is granted permission for a specific, time-boxed engagement against a specific, enumerated set of systems. HOW BUG BOUNTY AUTHORIZATION WORKS DIFFERENTLY ------------------------------ Per this chapter's own explanation, a bug bounty program's authorization instead comes from "the program's own published policy" — a publicly posted document defining what's in scope, what testing techniques are permitted, and the terms under which anyone (not one specific pre-vetted individual) can participate. Rather than an individually signed contract, the authorization is a standing, public offer: anyone who follows the published rules is authorized; anyone who doesn't is not. WHY TESTING OUTSIDE A BUG BOUNTY'S OWN SCOPE IS STILL UNAUTHORIZED ------------------------------ Per this chapter's own explanation, "the same underlying principle holds" between the two models: authorization is defined by its own specific, stated boundaries, not by a company's general attitude toward security research. A company running a bug bounty program has authorized testing SPECIFICALLY within that program's own published scope — certain domains, certain systems, certain techniques. Testing something outside those explicit boundaries (a different subdomain never listed, a technique the policy explicitly excludes, a system the policy doesn't mention at all) was never actually covered by that authorization, no matter how welcoming the company seems toward security research in general. Per this chapter's own closing point in that section, doing so "is exactly as unauthorized as testing a company with no bug bounty program at all" — the company's general openness to being tested doesn't substitute for the specific, bounded permission the policy actually grants. WHY THIS WORKS AS AN ANSWER ------------------------------ It explains both authorization models using the chapter's own stated mechanics (individually signed RoE vs. a published standing policy), and explains precisely why scope boundaries — not a company's general attitude — are what actually define what's authorized under a bug bounty program, directly quoting the chapter's own equivalence to testing a company with no program at all.