red-team-adversarial

name	red-team-adversarial
description	Adversarial security and resilience analysis — auto-triggered during /review and /test based on task classification. Provides attack surface analysis, boundary testing, auth bypass attempts, dependency chain attacks, and Beast Mode stress testing.

Red Team / Adversarial Testing

Overview

This skill applies adversarial thinking to code changes: instead of checking against a compliance list (that's what security_guardrails.md does), it actively asks "how would an attacker exploit this change?" and "what breaks under extreme conditions?"

It complements — never replaces — the existing OWASP security scan in /review.

Ironclad Rules

1. No bypass of governance: This skill executes within /review and /test phases only. It cannot override gates, skip phases, or alter classification.
2. Severity honesty: Only mark CRITICAL when there is a concrete, exploitable attack path with evidence (file:line). Speculative risks are HIGH at most.
3. Additive only: Red Team findings supplement existing security findings — never contradict or override them.

When to Use (Auto-Trigger Matrix)

AI MUST check the task classification from the Work Log and apply this matrix automatically:

Classification        │ /review          │ /test
──────────────────────┼──────────────────┼─────────────────
tiny-fix              │ —                │ —
quick-win             │ —                │ —
hotfix                │ Lite Red Team    │ Lite Adversarial (1-2 cases)
feature               │ Full Red Team    │ Adversarial Cases
architecture-change   │ Full Red Team    │ Adversarial Cases + Beast Mode

Auto-trigger logic: During /review or /test, read Classification: from the active Work Log. If classification is hotfix, feature, or architecture-change, execute the corresponding mode below. No user action required.

Modes

Lite Red Team (hotfix)

Minimal overhead (≤300 tokens output). Focus exclusively on the fix point:

1. Fix-Point Attack Vector: Does the fix itself introduce a new attack surface? (e.g., a validation fix that changes error behavior, a permission fix that alters fallback logic)
2. Regression Attack: Could an attacker exploit the old behavior to bypass the fix? (e.g., race condition in the fix window)

Output: 1-2 findings max, using the Red Team Report format below.

Full Red Team (feature / architecture-change)

Comprehensive adversarial analysis of all changed files:

1. Attack Surface Analysis: What new attack vectors does this change expose?
   • New endpoints, inputs, or data flows
   • Changed trust boundaries
   • New external dependencies or integrations
2. Boundary Testing: What happens at the extremes?
   • Empty/null/undefined inputs
   • Maximum-length strings, overflow values
   • Special characters, unicode edge cases
   • Type confusion (string where number expected, etc.)
3. Authorization Bypass Attempts: Can the validation logic be circumvented?
   • Direct object reference (IDOR)
   • Privilege escalation paths
   • Missing checks on alternative code paths
   • Token/session manipulation
4. Dependency Chain Attacks: Are new dependencies trustworthy?
   • Known CVEs in added packages
   • Typosquatting risk
   • Unmaintained dependencies
   • Transitive dependency risks

Output: All findings using the Red Team Report format below.

Beast Mode (architecture-change only)

In addition to Full Red Team, analyze systemic resilience:

1. Concurrency: Race conditions, deadlocks, TOCTOU vulnerabilities
   • Identify shared mutable state across the change
   • Check for missing locks, atomic operations, or serialization
   • File:line references for each scenario
2. Resource Exhaustion: Memory leaks, unbounded growth, CPU-intensive loops
   • Unbounded collections or caches
   • Missing pagination or limits
   • Recursive calls without depth guards
3. Fault Injection: What happens when dependencies fail?
   • Database connection drops mid-transaction
   • External API returns 500/timeout
   • File system full or permissions denied
   • Network partition scenarios

Output: Use the Beast Mode Analysis format below.

Output Formats

Red Team Report (embedded in /review output, after Security Findings)

## Red Team Findings

### [CRITICAL|HIGH|MEDIUM|LOW] — [Attack Vector]: [Brief Description]
- **File**: [path:line]
- **Attack Scenario**: [1-2 line attack narrative]
- **Impact**: [What attacker gains]
- **Mitigation**: [Concrete fix]

Adversarial Test Cases (embedded in /test output)

## Adversarial Test Cases

| # | Category | Input / Scenario | Expected Behavior | Priority |
|---|----------|------------------|--------------------|----------|
| 1 | Boundary | [extreme input]  | [should reject/handle] | HIGH |
| 2 | AuthZ Bypass | [bypass attempt] | [should deny] | CRITICAL |

Beast Mode Analysis (architecture-change only, embedded in /test output)

## Beast Mode Analysis

### Concurrency
- [race condition scenarios with file:line references]

### Resource Exhaustion
- [memory/CPU/disk scenarios]

### Fault Injection
- [what happens if dependency X fails? if network drops?]

Heading-Scoped Read Note

For phase-entry loading, read only:

• Ironclad Rules
• When to Use (Auto-Trigger Matrix)
• Modes

Load Output Formats, Blocking Rules, Work Log Integration, Red Team Findings, and Common Mistakes on full read or cache miss only.

Blocking Rules (Different from Security Guardrails)

Red Team findings use a graduated blocking model:

                    │ Security Guardrails (OWASP)  │ Red Team Skill
────────────────────┼─────────────────────────────┼──────────────────
CRITICAL            │ Hard block                  │ Hard block
HIGH                │ Hard block                  │ Soft block (record decision)
MEDIUM              │ Flag, proceed allowed       │ Advisory
LOW                 │ Informational               │ Advisory

• CRITICAL: Blocks /review verdict. MUST fix before proceeding.
• HIGH: Does NOT block. MUST record risk decision in Work Log (## Red Team Findings section). Recommend using /decide to document accept/defer rationale.
• MEDIUM / LOW: Advisory only.

Rationale: Red Team analysis is inherently more speculative than OWASP checklist scanning. Hard-blocking on HIGH would create excessive false positives. But CRITICAL findings (e.g., a directly exploitable auth bypass path) must be treated as blocking.

Work Log Integration

All Red Team findings MUST be recorded in the Work Log under ## Red Team Findings:

## Red Team Findings
- [date] /review: [N] findings ([severity breakdown])
- [date] /test: [N] adversarial cases generated
- HIGH risk decisions: [accepted/deferred — see /decide #N]

Common Mistakes

• Marking speculative risks as CRITICAL without a concrete file:line attack path.
• Running Full Red Team on tiny-fix or quick-win (wastes tokens, no value).
• Treating Red Team findings as replacements for OWASP checks (they are complementary).
• Skipping Beast Mode on architecture-change (this is where systemic failures hide).