Red Team

Adversarial 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.

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.

Procedure