0.2 The advanced learning flow: think in attack paths, assume breach

The first guide taught the loop READ -> EXPLAIN -> DO IT -> BREAK IT -> CHECK -> WRITE. Keep it. Add two habits of mind that separate intermediate from advanced practice.

1. Think in attack paths, not findings. A vulnerability scanner produces a list. An attacker produces a route: "anonymous -> this SSRF -> instance metadata -> this over-scoped role -> this S3 bucket -> customer PII". The individual steps might each be "medium"; the path is "critical". Your job is to find the paths and cut them at the cheapest chokepoint.

   FINDING VIEW                    ATTACK-PATH VIEW
   -----------                    ---------------
   - SSRF in image proxy (medium)  anon
   - EC2 role can read S3 (info)    -> SSRF (image proxy)
   - S3 bucket has PII (info)       -> 169.254.169.254 (IMDSv1 enabled)
   - IMDSv1 enabled (low)           -> AssumeRole creds for app-role
                                    -> app-role: s3:GetObject on data-bucket
                                    -> data-bucket: 40M customer records
                                    = CRITICAL, and one hop-limit change
                                      (IMDSv2) breaks the whole path

2. Assume breach. Perimeter thinking asks "how do they get in?" Assume-breach thinking says they are already in — a phished laptop, a leaked CI token, a compromised dependency (G1 Ch 47) — and asks "now what can they reach, how fast, and would we see it?" Every design decision in this guide is judged by how much it limits an attacker who already has a foothold.

The advanced loop, per topic:

   MODEL     draw the attack-path graph for this component
   BUILD     stand it up in your lab (cloud sandbox / kind cluster)
   ATTACK    walk the path yourself, with the real tools
   DETECT    can your telemetry see each step? build the rule
   DEFEND    cut the path; re-attack to prove it's cut
   WRITE     a short report: the path, the fix, the detection