opelpleple Red Team
Switch sides. Become the attacker, the competitor, the failure mode, or Murphy's Law — and try to break the thing the user just built, on purpose.
When to use
- Right before shipping, launching, publishing, or signing.
- Security/abuse review: "how would someone exploit this?"
- A strategy or plan that an opponent (competitor, regulator, adversary) could counter.
- A claim or argument going in front of a hostile audience.
- Anything where the cost of a missed weakness is high and rises after commitment.
When NOT to use
- Early brainstorming, where attacking ideas kills the generative phase. Diverge first, red-team later.
- When the user needs encouragement to start, not reasons to stop.
- Trivial, reversible decisions where the failure cost is near zero.
The method
- Define the target and the win condition precisely. What exactly are you attacking, and what counts as "broken"? "The plan fails" is vague; "an attacker reads another user's data" or "the launch misses its date" is a target.
- Pick your adversaries and put on each mask in turn. Run distinct passes, e.g.:
- The malicious attacker — wants to exploit, steal, abuse, or cheat.
- The competitor — wants to out-maneuver, copy, or undercut you.
- Reality / Murphy — no intent, just everything that can fail will: outages, edge cases, bad inputs, scale, time.
- The hostile critic — wants to discredit the argument publicly.
- For each mask, ask "how do I win against this?" Generate concrete attacks, not vague worries. Name the exact input, move, or condition.
- Probe the seams. Attacks live at boundaries: trust boundaries, handoffs, assumptions, "this will never happen," default configs, the unhappy path, the 10x-load path, the malicious-input path.
- For each attack, rate severity × likelihood. A devastating-but-impossible attack and an annoying-but-certain one are different problems. Sort by the product.
- Steelman the defense, then attack again. For the top attacks, imagine the best fix, then try to break that. Stop when remaining attacks are low-severity or genuinely hard.
- Deliver the kill list. Ranked attacks, each with: the exact exploit, why it works, severity × likelihood, and the cheapest mitigation.
What good looks like
- Specific, reproducible attacks — a concrete input/move, not "security could be better."
- At least one finding the user clearly hadn't considered.
- Honest severity ratings, including downgrading scary-sounding but trivial issues.
- Every finding paired with a mitigation, so it's actionable, not just discouraging.
- Coverage across multiple adversary types, not just one favorite angle.
Anti-patterns
- Vague FUD: "this might not scale" with no scenario. Name the load and the breaking point.
- Attacking the person, not the work. Red-team the artifact, never the author.
- Only finding flaws you already know how to fix. Push into uncomfortable territory.
- No prioritization: a flat list of 30 issues is as useless as none. Rank them.
- Forgetting the boring adversary: most real failures are Murphy, not a genius hacker.
Example
Target: a referral feature giving $10 credit per signup. Win condition: extract money without real referrals. Attacker mask: "I script 10,000 throwaway emails, self-refer, cash out $100k in credit." Seam probed: the trust boundary assumes one human per email. Reality mask: "two legit users refer each other in a loop." Severity × likelihood: high × high — this will be hit on day one. Mitigation: credit only unlocks after the referred account makes a verified action with cost (a real payment), not at signup. Re-attack the fix: "I make one real $1 purchase to unlock $10" — so cap credit at the verified spend. Kill list delivered, ranked, with the cheapest patch first.