Blockchain Purple Team — Meta-Security & Structural Gap Analysis

When to Use This vs Others

• Use this (Purple Team) when Black/Red findings exist but you need structural gap analysis and cross-team coverage mapping.
• Use blockchain-black-team for known exploit patterns grounded in historical incidents.
• Use blockchain-red-team for novel offensive technique discovery and defense-bypass pressure testing.

Find what Black Team and Red Team cannot see — but do not confuse exposure with exploitability. Structural blind spots are useful internally; external vulnerability reports should be exploitability-backed whenever possible.

Reference Map

• Read references/exploitability-gate.md before deciding whether a finding is a real vulnerability or just an interesting exposure.
• Read references/reporting-thresholds.md when deciding whether a finding stays internal or is strong enough for external disclosure.
• Read references/disclosure-templates.md when preparing a message for a project team, security inbox, bug bounty form, or maintainer.
• Read references/purple-team-pipeline.md when running Purple Team as an end-to-end workflow from intake to validation to disclosure.
• Read references/project-execution-template.md when opening a new testnet project review.
• Read references/triad-investigation-template.md when combining Black, Red, and Purple outputs into one packet.
• Read references/disclosure-tracker-format.md when tracking sent findings, acknowledgements, fixes, and retests.

When to Use

• Post-audit gap analysis ("what did the auditors miss?")
• Cross-team coverage assessment (Black + Red + Blue coverage map)
• Architecture-level security review (not code, but system design)
• Operational security assessment (key management, deployment, monitoring)
• Systemic risk modeling (correlation, cascade, contagion)
• Defense effectiveness validation (do the patches actually work?)

Purple Team Unique Perspective

| Team | Question | Time | Level | |---|---|---|---| | Black | "What attacks happened?" | Past | Code | | Red | "What attacks are possible?" | Future | Code | | Purple | "Why do defenses fail?" | Meta | Architecture + Operations |

Five Pillars of Analysis

Pillar 1: Audit Failure Patterns

Why do professional audits miss critical vulnerabilities?

Read references/audit-failures.md for patterns including:

• Scope blindness (auditor focuses on code, misses economic design)
• Assumption inheritance (auditor trusts external dependencies)
• Temporal blindness (point-in-time audit vs evolving protocol)
• Composition blindness (individual components audited separately)

Pillar 2: Defense Bypass Evolution

How do patched vulnerabilities get re-exploited?

Read references/defense-evolution.md for patterns including:

• Patch regression (fix breaks something else)
• Variant attacks (same root cause, different vector)
• Defense decay (defense valid at deployment, invalid after upgrades)
• Incomplete fix (root cause unaddressed, symptom patched)

Pillar 3: Systemic Composition Risk

When individually safe components create dangerous combinations.

Analysis framework:

1. Map all trust boundaries (on-chain ↔ off-chain ↔ oracle ↔ frontend)
2. For each boundary: "What happens if the other side lies?"
3. Map all state dependencies (A reads from B, B reads from C)
4. For each chain: "What's the longest stale-data path?"
5. Map all authority overlaps (same key controls multiple things)
6. For each overlap: "What's the blast radius of compromise?"

Pillar 4: Operational Security Gaps

Code is secure but operations fail.

Checklist:

• Key management (HSM vs file, rotation, backup, access control)
• Deployment (CI/CD security, binary verification, upgrade process)
• Monitoring (what's watched, what's not, alert fatigue, response time)
• Incident response (playbook exists? tested? who decides? communication)
• Dependency management (lockfiles, audit trail, update cadence)

Pillar 5: Economic Systemic Risk

Cross-protocol and macro-level risks.

Analysis:

• Collateral correlation (what happens when everything drops at once?)
• Liquidity dependency (which external liquidity sources are critical?)
• Oracle dependency (single oracle failure → cascade?)
• Governance capture (what's the cost of 51% control?)
• Contagion paths (protocol failure → which other protocols affected?)

Coverage Gap Detection

Method: Cross-Team Matrix

Build a matrix of [Attack Vectors × Defense Layers]:

                | On-chain | Keeper | Oracle | Frontend | Ops |
Reentrancy      |  B+R     |  -     |  -     |  -       | -   |
Flash Loan      |  B+R     |  -     |  B     |  -       | -   |
Key Compromise  |  -       |  B     |  -     |  -       | B   |
Governance      |  B       |  -     |  -     |  -       | -   |
Cascade/Depeg   |  B       |  -     |  B     |  -       | ?   |  ← GAP
...

Empty cells = coverage gaps. "?" = partially covered. Fill gaps with new analysis.

Method: Assumption Inventory

For every security property the protocol claims:

1. State the assumption explicitly
2. Ask: "Who/what can violate this assumption?"
3. Ask: "What happens when it's violated?"
4. Ask: "Is there detection? Is there recovery?"

Report Format

# Purple Team Report — {Protocol Name}

## Coverage Map
{Cross-team matrix with gap highlights}

## Structural Gaps Found: N
## Audit Failure Patterns Applicable: N

## {ID}: {Gap Description}
- **Pillar**: 1-5
- **Gap Type**: Coverage / Assumption / Composition / Operational / Systemic
- **Missed By**: Black / Red / Both
- **Why Missed**: {explanation}
- **Risk If Exploited**: {impact}
- **Recommendation**: {architecture/process change}

Cycling Protocol

Purple Team runs after Black+Red and reviews Blue fixes:

Black+Red → Blue fix → Purple review → Blue fix → ... → Full coverage

Purple validates that Blue fixes don't create new gaps.