thinking-red-team

1# Red Team
2 
3Adversarial security review of systems you are authorized to assess. Attack before an outsider does, but report only what you can actually break: every finding needs a concrete exploit path and a check that the proposed fix closes it.
4 
5## When to Use
6 
7- Security review of code, authentication, authorization, APIs, data handling, or infrastructure you control and are permitted to probe.
8- Pre-launch hardening of systems that handle auth, money, personal data, or privileged actions.
9- Checking whether a specific vulnerability class (injection, XSS, IDOR, auth bypass, SSRF, secret exposure, etc.) is present with a real path.
10- Validating that a claimed control actually blocks the attack, not only that a scanner is quiet.
11 
12## When NOT to Use
13 
14- No authorization to attack the target — stop; do not probe systems you do not own or have written leave to test.
15- Speculative "best practice" notes without a reproducible exploit path — drop them; they are not findings.
16- Plan, strategy, or decision stress-testing — use pre-mortem (how the plan fails) or steel-manning (strongest case against the decision).
17- Architecture resilience without a security objective — use systems or pre-mortem.
18- Scanner output alone as a report — patterns are leads; red-team requires an exploit path.
19- Non-security root-cause or hypothesis localization — use scientific-method or five-whys-plus.
20 
21## Procedure
22…