domains / families / general / thinking-red-team

thinking-red-team

separate

For authorized security review of code, auth, or APIs you control, model the attacker, map the attack surface, and report only findings with a reproducible exploit path and verified mitigation.

When to use

• Security review of code, authentication, authorization, APIs, data handling, or infrastructure you control and are permitted to probe.
• Pre-launch hardening of systems that handle auth, money, personal data, or privileged actions.
• Checking whether a specific vulnerability class (injection, XSS, IDOR, auth bypass, SSRF, secret exposure, etc.) is present with a real path.
• Validating that a claimed control actually blocks the attack, not only that a scanner is quiet.

When not to use

• No authorization to attack the target — stop; do not probe systems you do not own or have written leave to test.
• Speculative "best practice" notes without a reproducible exploit path — drop them; they are not findings.
• Plan, strategy, or decision stress-testing — use pre-mortem (how the plan fails) or steel-manning (strongest case against the decision).
• Architecture resilience without a security objective — use systems or pre-mortem.
• Scanner output alone as a report — patterns are leads; red-team requires an exploit path.
• Non-security root-cause or hypothesis localization — use scientific-method or five-whys-plus.

Skill page

Source