Warmup Guide — Authorization, Containment, and Evidence from First Principles

Zero-to-expert primer for Phase 00. Read this before the labs. It builds every concept the phase depends on — authorization as data, scope as machine-checkable policy, network isolation, evidence provenance, responsible disclosure, and the legal frame — from the ground up, assuming only basic programming. By the end you should be able to refuse an unsafe request and name the exact reason, prove a lab is contained, and preserve evidence that survives scrutiny. Security capability without this discipline is not a junior version of the job; it is a liability.

Table of Contents

Chapter 1: Why a Safety Phase Comes First

Zero background. A security engineer's daily work overlaps mechanically with the work of an attacker: you send unexpected input, you probe authorization, you read memory you were not meant to read, you handle malicious files. The single difference between a professional and a criminal is not skill — it is authorization, containment, and discipline. Those three are the load-bearing walls of the entire role. A vulnerability researcher who cannot prove they were authorized, who contaminates the host they were testing from, or who leaks a victim's personal data while writing a report has done net harm regardless of how clever the finding was.

Why it exists. Every later phase in this curriculum hands you a sharper tool: fuzzers (Phase 08), container-escape primitives (Phase 06), Android instrumentation (Phase 04), cloud IAM attack-path analysis (Phase 07), AI agents that can take actions (Phase 11). Each of those is dual-use. Phase 00 installs the reflexes that make the rest safe to learn. You build the muscles that fire automatically: Am I authorized? Is this contained? Is my evidence sound? Should I stop? When those questions are automatic, the offensive tooling that follows is an engineering instrument rather than a hazard.

How it connects to production. At a top-tier security team, you will not be trusted with production access, red-team scope, or a VRP queue until you demonstrate exactly the behaviors this phase teaches. The "operating manual" capstone is not busywork — a real engagement begins with a rules-of-engagement document, a contained environment, an evidence plan, and a stop-condition list. Interviewers probe this directly: the fastest way to fail a security interview is to answer "the client asked me to test an asset not in scope" with anything other than "I stop and get it in writing."

Misconception to kill now. "Safety is the boring part before the real hacking." Inverted. The real differentiator at the staff/principal level is judgment under ambiguity — and judgment is exactly what this phase trains. Anyone can run a scanner. Few can be trusted to run one against a system that matters.

Chapter 2: The Legal Ground — What the Law Actually Prohibits

Zero background. You do not need to be a lawyer, but you must understand the shape of the laws that govern this work, because the boundary they draw is the boundary of your career. The recurring theme across jurisdictions is authorization: accessing a computer system without authorization (or exceeding authorized access) is the criminal act, independent of harm.

The major statutes (conceptually).

  • United States — Computer Fraud and Abuse Act (CFAA). Criminalizes accessing a "protected computer" without authorization or in excess of authorization. "Protected computer" is broad — effectively anything internet-connected. The 2021 Van Buren v. United States Supreme Court decision narrowed "exceeds authorized access" to mean accessing areas of a system you are not permitted to enter, rather than merely using permitted access for a forbidden purpose — but this is a thin shield, not a license. The 2022 DOJ policy declined to prosecute good-faith security research, but DOJ policy is not law and protects no one in a civil suit.
  • United Kingdom — Computer Misuse Act 1990. Unauthorized access (s.1), unauthorized access with intent to commit further offenses (s.2), and unauthorized acts impairing operation (s.3).
  • European Union — Directive 2013/40/EU on attacks against information systems, transposed into member-state law.
  • Sector and data law. GDPR (EU), HIPAA (US health), PCI DSS (cards — contractual, not statutory, but binding), and export-control regimes (EAR/Wassenaar) that can restrict sharing certain intrusion tooling across borders.

Why "the system was reachable" is never a defense. None of these statutes contain a "but the port was open" exception. An unlocked door is still trespass. This is the single most important legal intuition in the field: reachability is not permission.

How it connects to production. Real engagements are governed by a contract (statement of work, master services agreement) plus a rules-of-engagement (ROE) document, and frequently a safe harbor clause in a VRP that promises the organization will not pursue legal action for good-faith testing within stated scope. Your protection is the intersection of statute, contract, and written authorization — never any one alone.

Misconception to kill now. "Bug bounty pages mean everything is fair game." A VRP scope page is a narrow grant with explicit exclusions (no DoS, no social engineering, no testing of third-party-hosted assets, no automated scanning above a rate). Acting outside it forfeits safe harbor and re-exposes you to the statutes above.

This curriculum is authorized-lab-only. Everything you build and break, you own or have explicit written permission to test. When in doubt, obtain qualified legal advice for your jurisdiction — this chapter is orientation, not legal counsel.

Chapter 3: Authorization Is Data, Not a Vibe

The problem. A human agreement ("you may test our staging API next week") is prose. Your tools operate on concrete facts: IP addresses, hostnames, cloud resource IDs, account identifiers, timestamps, technique names, request rates, data volumes. The gap between the prose and the facts is where accidents live. An IP can be reassigned to a different tenant after the agreement is signed. A wildcard domain *.example.com can silently include a vendor-hosted subdomain you have no right to touch.

The fix: convert authorization into runtime state. Treat authorization as a versioned policy object evaluated before every consequential action. The decision is a function of:

engagement + operator + target + resolved asset identity + technique
           + time window + rate/data budget + safety state + policy version

Every one of those is a fact a program can check. The first lab (Engagement Guard) makes you build exactly this evaluator. The discipline you learn — resolve identity, then reject ambiguity, then fail closed — is the same discipline that reappears as cloud IAM (Phase 07), Kubernetes admission control (Phase 07), Android component-export checks (Phase 04), sandbox policy (Phase 06), and AI-agent tool gating (Phase 11). Deny-by-default authorization is the spine of the whole curriculum; here is where you first build it.

Fail closed, defined. When the system cannot establish that an action is permitted — because ownership is unclear, the policy is stale, an identifier won't resolve, or a predicate is missing — the answer is deny with a reason, never allow because probably fine. "Fail open" (allow on uncertainty) is how good intentions become incidents.

Misconception to kill now. "I'll just keep the scope in my head." Human memory is not an auditable control. If a teammate, an auditor, or a court asks "what authorized this packet?", the answer must be a record, not a recollection.

Chapter 4: Scope as a Machine-Checkable Policy

Build the model. An engagement is a small data structure:

Engagement
  approved assets        # exact identifiers, no wildcards you haven't resolved
  approved techniques    # e.g. {web-app-test} — NOT {load-test, social, physical}
  UTC start / end        # the window
  request ceiling        # max rate / total requests
  data ceiling           # max bytes / records of proof
  stop conditions        # state that overrides everything (Chapter 5)

The decision predicate. An action is allowed only if every clause is true:

asset ∈ approved_assets
  AND technique ∈ approved_techniques
  AND start ≤ now ≤ end
  AND observed_rate ≤ request_ceiling
  AND requested_data ≤ data_ceiling
  AND no stop_condition is active

This is a conjunction, which means any single false clause denies the action. That asymmetry is the whole point: it is hard to accidentally allow something and easy to deny it.

The five classic scope-drift failures — memorize these; each is a real-world incident pattern:

  • Adjacent-host drift. A redirect, DNS alias, load balancer, or freshly discovered hostname is assumed in scope. It is not. Discovery does not extend authorization.
  • Technique drift. "Web testing" silently becomes load testing, denial-of-service, social engineering, or physical entry. Each technique class needs its own explicit grant.
  • Account/tenant drift. Access to one test tenant is treated as permission to read another tenant's data. Multi-tenancy boundaries are scope boundaries.
  • Time drift. A scan launched inside the window keeps running after it closes. The window governs traffic, not just button presses.
  • Data drift. "Minimum proof of the vulnerability" balloons into a bulk export of real records. Prove the bug with one record, not the database.

Why UTC, strictly. Timestamps without a timezone are ambiguous, and ambiguity in a time window means an action might be inside or outside scope depending on interpretation. The lab forces strict UTC parsing because an unparseable or naive timestamp must fail closed — you cannot prove you acted inside the window if you cannot pin the window to an absolute instant.

Misconception to kill now. "Canonicalizing the asset means resolving DNS and following redirects to see what's really there." No — resolving to discover new assets is itself drift. You canonicalize to compare against the approved list, not to expand it.

Chapter 5: Stop Conditions and Incident Conversion

Zero background. A stop condition is a precommitted rule that says: if state X becomes true, all permissions are revoked and active work halts immediately. It is a circuit breaker. The value of precommitting is that the decision to stop is made calmly in advance, not under the pressure of a live engagement where momentum and sunk cost push you to continue.

The canonical stop conditions:

  • unexpected third-party or personal data appears;
  • the target shows instability, degradation, or safety impact;
  • scope becomes ambiguous;
  • cloud cost runs away;
  • evidence integrity fails (a hash mismatch you cannot explain);
  • you see signs of a real intrusion unrelated to your testing;
  • the owner or an incident commander says stop.

Stop conditions override permissions. This is the key structural property. In the decision predicate of Chapter 4, the stop-condition clause is ANDed last and dominates: even a perfectly in-scope, in-window, in-budget action is denied if a stop condition is active. The lab models this as state that short-circuits the allow decision.

Incident conversion. Sometimes during a test you encounter activity that may not be yours — a shell you didn't drop, beaconing you didn't start, data already exfiltrated. The assessment may have just walked into a real incident. The correct sequence:

  1. Freeze automated activity (stop generating new events).
  2. Preserve telemetry and your own action log.
  3. Separate tester-generated events from unknown events — this is why you keep a precise log of everything you did, with timestamps and request IDs.
  4. Escalate via the incident-command path; do not investigate beyond the authority the incident lead grants you.

Why your action log matters. Incident responders' first hard problem is "which of these events were the authorized tester and which were the adversary?" If your activity is logged precisely, you hand them a clean subtraction. If it isn't, you have made the incident harder to investigate.

Misconception to kill now. "Stopping is failure." Stopping correctly is the success metric of this phase. A tester who recognizes a stop condition and halts has performed flawless risk control.

Chapter 6: Network Isolation from First Principles

Zero background — what a network boundary actually is. When a machine wants to talk to another machine, the operating system consults its routing table to pick an outbound interface and a next hop. A firewall sits in that path and applies rules: allow or drop a packet based on source, destination, port, and protocol. "Isolation" means the only paths that exist are the ones you intend, and you have proven the others are absent. A virtual machine is not isolation — it is a container for an operating system that, by default, often has full LAN and internet access through the host.

Defense in depth — layers, each independently enforcing deny-by-default:

host firewall                         # the host won't route lab subnets to your home LAN
  → isolated virtual switch           # guests share a switch with no uplink to the real network
    → lab router (default-deny)       # explicit allow rules only for declared zone pairs
      → workload egress policy        # per-VM/container outbound restrictions
        → DNS/HTTP proxy allowlist    # only when an exercise truly needs outbound access

The reason for layers is that any single control can be misconfigured. If the virtual switch is accidentally bridged, the host firewall still blocks the LAN. Independent layers turn one mistake into a near-miss instead of a breach.

Test the negative path — the core discipline. A diagram claims isolation; packets prove it. From every vulnerable or analysis host, you must demonstrate that prohibited routes fail:

  • your home/corporate LAN is unreachable;
  • cloud metadata service addresses (169.254.169.254 and the link-local IPv6 equivalents) are unreachable — these endpoints hand out credentials and are a top cloud-pivot target;
  • public egress is denied unless the exercise explicitly routes through a controlled proxy;
  • management services accept only the management identity over the management path.

Canary technique. Place a synthetic secret (a "canary") in a forbidden location and confirm the vulnerable host cannot reach it. If denial is observed, you've proven the policy works — not merely that the target happened to be absent. This distinction (policy-proven vs. coincidentally absent) is what separates a tested control from an assumed one.

Management plane vs. experiment plane. The experiment (the vulnerable systems, the attacker workstation) must never be able to administer or impersonate the management plane (source control, the evidence vault, orchestration, telemetry). If a compromised victim VM could reach your evidence store, your evidence is no longer trustworthy. Separate the planes and prove the experiment plane cannot touch the management plane.

Misconception to kill now. "I'm behind NAT / on a VPN, so I'm isolated." NAT (Network Address Translation — rewriting private addresses to a shared public one so many hosts share one IP) and VPNs change addressing and confidentiality, not authorization or containment. A NATed host can still reach the internet; a VPN just moves where it egresses. Neither stops a victim VM from reaching your LAN or the internet.

Chapter 7: Evidence, Hashing, and Provenance

Zero background — what a cryptographic hash proves. A hash function (SHA-256) maps any input to a fixed 256-bit fingerprint such that (a) the same input always yields the same output, and (b) it is computationally infeasible to find two inputs with the same output (collision resistance) or to reverse it. Therefore, if you record \( \text{SHA-256}(\text{file}) = h \) at collection time and later recompute it and get the same \( h \), the bytes have not changed since collection.

What hashing does not prove — and this is the crux. A matching hash proves integrity since the recorded moment. It says nothing about:

  • who collected the bytes,
  • when (was the clock correct? synced to what source?),
  • whether the source was trustworthy (a hash of a planted file is still a valid hash),
  • what context was omitted during collection.

Integrity is necessary but not sufficient. The missing piece is provenance.

Provenance as a graph. Real evidence is a chain from origin to claim:

source → collector (tool + version) → collection time (UTC + clock source)
       → raw hash → transformation (decompress / filter / redact / convert)
       → derived hash → analyst claim → linked artifact

Every transformation creates a new artifact with a new hash and a recorded reason. You analyze copies and keep the original read-only, so the original's hash stays valid forever. This is the engineering meaning of chain of custody: an unbroken, recorded sequence from acquisition to conclusion, where every hop is attributable and every transformation is logged.

Minimum fields of an evidence record:

  • stable evidence ID;
  • source and collector (with tool version);
  • collection time in UTC and the clock source;
  • SHA-256 digest of the raw artifact;
  • storage location and access controls;
  • every transformation applied, each with its own derived hash.

The tamper demonstration (Lab 03 / evidence drill). Hash a fixture; flip one byte; show the manifest rejects it; restore the original; show it passes. The operational lesson: analysis tooling must fail loudly on integrity mismatch. Silent acceptance of altered evidence is how a report gets destroyed in review.

Why screenshots are weak evidence. A screenshot omits source state, collection method, searchable structure, and transformation history. It is a presentation artifact, not primary evidence. Collect the underlying log, pcap, or file; derive the screenshot from it.

Misconception to kill now. "Hashing makes evidence trustworthy." Hashing makes evidence tamper-evident from a point in time. Trustworthiness comes from the full provenance graph plus access controls plus a trustworthy collection process.

Chapter 8: Privacy, Data Minimization, and Redaction

Zero background. During testing you will brush against real personal data — names, emails, tokens, health or financial records. The governing principle is data minimization: collect the least data that proves the finding, and remove sensitive content from anything you share.

Proof, not plunder. To prove broken object-level authorization, you need one record you shouldn't be able to read — not the table. The size of your evidence is a liability, not a trophy. A report that includes a bulk export has converted a vulnerability finding into a data breach you caused.

Redaction as a deterministic transformation. The evidence-redaction lab models redaction as a pipeline that replaces sensitive tokens with stable placeholders and counts the transformations, so the report can state "17 email addresses redacted" auditably. Two properties matter:

  • Determinism: the same input always redacts to the same output, so the same entity gets the same placeholder and analysts can correlate without seeing the raw value.
  • Counting: the number of redactions is itself evidence of thoroughness and a check against leaks.

Redaction is irreversible by design. A good redaction cannot be undone from the published artifact. Beware "redactions" that merely overlay (black box over still-present text, metadata that retains the original, reversible hashing of low-entropy values like phone numbers). Redact the bytes, not the appearance.

Misconception to kill now. "I'll redact before publishing." Redact before storing in any shared location. The published report is not the only leak surface — chat messages, ticket attachments, and screenshots leak just as effectively.

Chapter 9: Safe Handling of Malware and Dangerous Fixtures

Zero background. Later phases triage malicious files (Phase 09) and run fuzzers that produce crashing inputs (Phase 08). A malicious sample is live ordnance: opening it in the wrong place executes attacker code with your privileges and network position.

The handling rules, and why each exists:

  • Inert fixtures first. Prefer a benign file that exhibits the behavior you're studying (e.g. the EICAR test string for AV pipelines) over a real sample. You learn the workflow without the hazard.
  • Isolated network, snapshots. Detonate only in a guest with no path to your LAN, internet, or management plane (Chapter 6), and snapshot before so you can roll back to a clean state.
  • No shared folders, no clipboard, no host credentials. Each of these is a bridge the malware can cross from guest to host. Disable them for any malware-adjacent VM.
  • Controlled transfer. Move samples as encrypted, password-protected archives so they don't auto-execute or get scanned/quarantined in transit, and so they can't accidentally detonate on an intermediary.

Why this lives in Phase 00. You set up these handling reflexes before you ever touch a real sample, so that when Phase 09 hands you one, the containment is already instinct.

Misconception to kill now. "It's just a sample in a VM." A VM with clipboard sharing, a shared folder, and internet access is a launch pad, not a sandbox. Containment is a property you prove (Chapter 6), not a checkbox you assume.

Chapter 10: Responsible Disclosure and the VRP Lifecycle

Zero background. When you find a real vulnerability in someone else's system (within authorized scope), responsible disclosure (a.k.a. coordinated disclosure) is the process of reporting it privately to the owner, giving them time to fix it, and only then — with permission — publishing. The goal is to get the bug fixed without arming attackers in the interim.

The VRP lifecycle (Vulnerability Reward Program / bug bounty):

discover → validate (reproduce, minimize proof) → report (clear writeup, repro steps, impact)
        → triage (vendor confirms / deduplicates / scores severity) → remediation (vendor fixes)
        → verification (you confirm the fix) → disclosure (coordinated, with permission)
        → optional reward

The friction points you must understand:

  • Duplicates. Someone may have reported the same bug first; VRPs reward the first valid report.
  • Severity disputes. You and the vendor may disagree on impact; argue with a clear exploitation scenario and a CVSS-style rationale, not indignation.
  • Embargoes. A period during which neither party publishes, so a coordinated fix can ship — often aligned with a CVE assignment and patch release.
  • Publication permission. You do not unilaterally publish. Even after a fix, you coordinate timing. Publishing a working exploit before users can patch is harmful disclosure.

Severity, briefly (CVSS intuition). A finding's severity combines exploitability (how easy to trigger: attack vector, complexity, privileges/interaction required) and impact (confidentiality, integrity, availability). A pre-auth remote bug that leaks all tenant data is critical; a self-XSS requiring the victim to paste an attacker's payload into their own console is low. You will justify severity in every report you write.

Explaining disclosure to an executive who wants to publish immediately. Frame it as risk to users: until a fix ships and is adopted, a public writeup is a roadmap for attackers against your own customers. Coordinated timing maximizes the number of users protected at publication.

Misconception to kill now. "Finding it gives me the right to publish it." Authorization to test is not authorization to disclose. They are separate grants with separate timing.

Chapter 11: The Hat Taxonomy and Why Labels Never Grant Permission

The community uses color labels; know them so you can speak the language, but internalize that none of them is a legal or ethical status — only authorization is.

  • White hat — authorized, ethical testing to improve security.
  • Black hat — unauthorized, malicious.
  • Gray hat — acts without clear authorization, often disclosing afterward; legally exposed regardless of intent.
  • Red team — authorized adversary emulation, broad scope, tests detection and response.
  • Blue team — defenders: detection, response, hardening.
  • Purple team — red and blue working together to close detection gaps in a feedback loop.
  • Green/blue-hat — informal terms (newcomers; external invited testers, e.g. pre-release programs) with no consistent industry meaning.

The load-bearing point: calling yourself a "white hat" does not make an action authorized. The label describes intent; authorization (Chapters 3–4) describes permission. Only the latter keeps you on the right side of Chapter 2. A "gray hat" who finds a real bug in a stranger's system and discloses it is still legally exposed — good intent is not a defense to unauthorized access.

Lab Walkthrough Guidance

The three runnable labs operationalize this guide. Build them in this order:

Lab 01 — Engagement Guard and Evidence Verifier. This is the flagship. Implement in sub-steps:

  1. Parse strict UTC timestamps; a naive or unparseable timestamp must fail closed (Chapter 4).
  2. Canonicalize asset identifiers for comparison only — do not resolve or discover adjacent assets (Chapter 4 misconception).
  3. Validate the engagement policy object (assets, techniques, window, ceilings).
  4. Implement the allow decision as the conjunction from Chapter 4.
  5. Make stop conditions override all permissions (Chapter 5) — verify an in-scope action is denied when a stop condition is active.
  6. Hash and verify evidence files; reject a tampered fixture (Chapter 7).
  7. Emit structured decision records that name the failed predicate and contain no secrets.

Lab 02 — Range Containment Verifier. Encode the zone reachability matrix (Chapter 6): only declared zone pairs may communicate; LAN, internet, OT, metadata, and management reachability from vulnerable zones must be proven absent.

Lab 03 — Evidence Redaction Pipeline. Deterministic redaction with transformation counts (Chapter 8); the same secret always maps to the same placeholder; the count is reported.

Run each lab against both your implementation and the reference solution:

pytest test_lab.py -v
LAB_MODULE=solution pytest test_lab.py -v

Success Criteria

You are ready for Phase 01 when you can, without notes:

  1. Refuse an out-of-scope target and name the exact failed predicate (asset / technique / window / rate / data / stop).
  2. Stop an otherwise-permitted action because a stop condition is active, and explain the override semantics.
  3. Detect modified evidence and explain why integrity ≠ provenance.
  4. Prove a forbidden network path is absent using packets, not a diagram, including the metadata endpoint and your home LAN.
  5. Explain why a VM, VPN, disclaimer, or public bug-bounty page is not sufficient authorization.
  6. Convert a test into an incident workflow without contaminating evidence or losing the tester/adversary distinction.
  7. Disclose responsibly — describe the VRP lifecycle, embargoes, and why publication needs coordination.

Common Mistakes

  • Treating public reachability as authorization (Chapter 2 — the defining error).
  • Using a VPN, disclaimer, or VM as a substitute for written scope.
  • Letting vulnerable images keep internet or LAN access; never testing the negative path.
  • Capturing excessive data and calling it "evidence" (Chapter 8).
  • Hashing evidence but never recording provenance, then being unable to defend it.
  • Treating "stop" as failure rather than as the primary success behavior.
  • Publishing a finding before the owner authorizes disclosure.

Interview Q&A

Q: What would make you stop an assessment immediately? A: Any active stop condition — unexpected third-party/personal data, target instability or safety impact, scope ambiguity, runaway cloud cost, an unexplained evidence-integrity failure, signs of a real intrusion, or an owner/IC stop request. Stop conditions override all other permissions, so I halt even mid-action, preserve state and my action log, record the reason and time, notify the owner, and require explicit re-authorization before resuming.

Q: A redirect points from an approved hostname to an unlisted hostname. Do you continue? A: No. Redirects, aliases, and discovered hosts do not extend scope — that's adjacent-host drift. I stop that path, preserve the response as evidence, and obtain written clarification from the asset owner before touching the new host.

Q: The client verbally asks you to test a new asset during a call. What do you do? A: Record the request, but do not test until the authorized scope is updated in writing by the right owner. A verbal request from someone on a call is not proof of authorization, and I can't later show what authorized the traffic.

Q: How do you preserve evidence while minimizing personal data? A: Collect the minimum that proves the finding — one record, not the table. Preserve the raw artifact read-only with a recorded hash and full provenance (collector, tool/version, UTC time, clock source). Analyze copies. Redact secrets and personal data deterministically before the artifact enters any shared location, and report the redaction counts.

Q: Why hash evidence more than once? A: I hash at acquisition to anchor integrity, and again after each transformation boundary (transfer, normalization, redaction). Matching hashes prove the bytes are unchanged since each point; the chain of derived hashes plus recorded reasons preserves provenance. A single hash proves integrity from one instant; the chain proves the whole custody path.

Q: When does a security assessment become an incident response engagement? A: When I encounter activity that may not be mine — a foothold I didn't create, beaconing, evidence of prior exfiltration. I freeze my automated activity, preserve telemetry and my action log, mark every event I generated so responders can subtract my activity, and escalate through incident command without investigating beyond the authority the IC grants.

Q: Explain responsible disclosure to an executive who wants to publish immediately. A: Until a fix ships and customers adopt it, a public writeup is an attacker roadmap against our own users. Coordinated disclosure — private report, remediation window, optional embargo aligned with the patch — maximizes the number of users protected when we publish. We lose nothing by sequencing it; we expose users by rushing it.

References

Standards and government guidance

  • NIST SP 800-61 Rev. 2 — Computer Security Incident Handling Guide (preparation, IR lifecycle).
  • NIST SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response (evidence concepts, order of volatility, chain of custody).
  • NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment (scoping, rules of engagement, methodology).
  • ISO/IEC 29147 — Vulnerability disclosure; ISO/IEC 30111 — Vulnerability handling processes.
  • FIRST CVSS v3.1 / v4.0 specification — severity scoring (exploitability vs. impact).

Law and policy

  • Computer Fraud and Abuse Act, 18 U.S.C. § 1030; Van Buren v. United States, 593 U.S. (2021).
  • UK Computer Misuse Act 1990; EU Directive 2013/40/EU on attacks against information systems.
  • U.S. DOJ, "Policy Regarding Charging Under the CFAA" (2022) — good-faith research declination (policy, not law).
  • EFF, Coders' Rights Project — vulnerability reporting and reverse-engineering FAQs.

Disclosure and program practice

  • disclose.io — open-source safe-harbor and disclosure policy templates.
  • Major VRP policy pages (Google, Apple Security Research, Microsoft MSRC) — compare scope, prohibited testing, data handling, and disclosure terms (Phase 00 required reading).
  • CERT/CC Guide to Coordinated Vulnerability Disclosure.

Books

  • Jon Erickson, Hacking: The Art of Exploitation (lab-only mindset, foundations).
  • Dafydd Stuttard & Marcus Pinto, The Web Application Hacker's Handbook (methodology discipline).
  • Bruce Schneier, Secrets and Lies (security as a risk-management process, not a product).