Red/Blue Review
Use opposing lenses to find what breaks and what defends it. Do not list generic risks. Produce concrete attack paths, failure paths, and mitigations.
Inputs To Gather
- The artifact: code, diff, design, ADR, spec, migration, runbook, or launch plan.
- The asset at risk: money, data integrity, availability, privacy, developer time, customer trust.
- The threat or failure model: malicious actor, operator error, dependency failure, scale, bad data, ambiguous requirements.
- The deployment context: environments, permissions, observability, rollback path.
Red Team
Act like the system will be misused, overloaded, misconfigured, or attacked.
Check:
- Trust boundaries and privilege escalation.
- Input validation and malformed data.
- Authentication, authorization, and tenant isolation.
- Secrets handling and accidental leakage.
- Retry storms, duplicate effects, race conditions, and idempotency gaps.
- Silent data corruption and partial writes.
- Missing timeouts, circuit breakers, and backpressure.
- Operational mistakes: bad deploy, bad config, bad rollback, stale docs.
Blue Team
Defend with practical controls, not wishful thinking.
For each credible issue:
- Prevention: code/design change that stops it.
- Detection: logs, metrics, traces, alerts, invariants, tests.
- Containment: rate limits, circuit breakers, feature flags, kill switches.
- Recovery: rollback, replay, reconciliation, data repair.
- Ownership: who notices and who acts.
Output
## Red Team Findings
### Critical
- Attack/failure path:
Evidence:
Impact:
Why current controls fail:
### High
- Attack/failure path:
Evidence:
Impact:
Why current controls fail:
## Blue Team Plan
- Control:
Covers:
Implementation:
Validation:
## Launch Gate
- Ship:
- Block:
- Spike:
Rule
If there is no evidence for a control, say "control not demonstrated." A design promise is not a control.
1---2name: red-blue-review3description: Examine concrete attack and failure paths, then design prevention, detection, containment and recovery. Use for red team, blue team, threat models, attack paths or defense plans. General engineering review belongs to morpheus; component failure inventories belong to failure-analysis.4---56# Red/Blue Review78Use opposing lenses to find what breaks and what defends it. Do not list generic risks. Produce concrete attack paths, failure paths, and mitigations.910## Inputs To Gather1112- The artifact: code, diff, design, ADR, spec, migration, runbook, or launch plan.13- The asset at risk: money, data integrity, availability, privacy, developer time, customer trust.14- The threat or failure model: malicious actor, operator error, dependency failure, scale, bad data, ambiguous requirements.15- The deployment context: environments, permissions, observability, rollback path.1617## Red Team1819Act like the system will be misused, overloaded, misconfigured, or attacked.2021Check:2223- Trust boundaries and privilege escalation.24- Input validation and malformed data.25- Authentication, authorization, and tenant isolation.26- Secrets handling and accidental leakage.27- Retry storms, duplicate effects, race conditions, and idempotency gaps.28- Silent data corruption and partial writes.29- Missing timeouts, circuit breakers, and backpressure.30- Operational mistakes: bad deploy, bad config, bad rollback, stale docs.3132## Blue Team3334Defend with practical controls, not wishful thinking.3536For each credible issue:3738- Prevention: code/design change that stops it.39- Detection: logs, metrics, traces, alerts, invariants, tests.40- Containment: rate limits, circuit breakers, feature flags, kill switches.41- Recovery: rollback, replay, reconciliation, data repair.42- Ownership: who notices and who acts.4344## Output4546```markdown47## Red Team Findings4849### Critical50- Attack/failure path:51 Evidence:52 Impact:53 Why current controls fail:5455### High56- Attack/failure path:57 Evidence:58 Impact:59 Why current controls fail:6061## Blue Team Plan6263- Control:64 Covers:65 Implementation:66 Validation:6768## Launch Gate6970- Ship:71- Block:72- Spike:73```7475## Rule7677If there is no evidence for a control, say "control not demonstrated." A design promise is not a control.
CassioRoos