Purple Team

Overview

The Purple Team serves as the central synthesis hub of the Prismatic Platform's six-team color-team security architecture. As the sole authority for closure state transitions, Purple Team receives adversarial findings from Red Team, defensive assessments from Blue Team, boundary discoveries from Gray Team, formal verifications from White Team, and theoretical threat models from Black Team — synthesizing these into actionable improvements and verified closure decisions. Purple Team is where the platform stops lying to itself.

"Purple is the property of the system when it stops lying to itself."

The theoretical foundation of Purple Team operations draws from feedback loop theory, closure verification in formal methods, and the adversarial-defensive synthesis model pioneered in military red team/blue team doctrine. The Prismatic Platform extends these foundations with a rigorous four-condition closure framework, anti-metric enforcement that prevents gaming of security metrics, and regression trap management that ensures resolved vulnerabilities never resurface. Purple's authority is unique: it has deployment veto power and can block any release that contains unresolved critical findings or active regressions.

Within the color-team architecture, Purple occupies the convergence point — every team's output flows through Purple for synthesis, and Purple's closure decisions determine the platform's security posture. This centralized synthesis model ensures that adversarial findings are matched with defensive responses, that defensive claims are verified against adversarial evidence, and that no finding falls through the cracks between Red attack and Blue defense.

Mission and Doctrine

The Purple Team mission is to close the adversarial-defensive feedback loop by synthesizing Red findings with Blue defenses into verified, documented improvements. Purple ensures that every identified vulnerability has a corresponding defense, that every defense is verified against the original attack, and that no regression reintroduces previously resolved vulnerabilities.

Mission Principles

The NO MERCY, NO DOUBTS doctrine governs Purple operations with dual emphasis: NO MERCY demands that closure is never premature — findings remain open until all four conditions are verified, regardless of timeline pressure. NO DOUBTS demands that every closure decision is evidence-based and documented, with complete provenance from initial finding through defense implementation and verification.

Team Composition

The Purple Team comprises four agents organized around the synthesis lifecycle: coordination, mapping, closure analysis, and regression prevention.

purple-coordinator

The Purple Coordinator serves as the synthesis hub, receiving inputs from all other color teams and orchestrating the closure process. The coordinator maintains the master finding registry, tracks closure state transitions, enforces anti-metric policies, and exercises deployment veto authority when necessary. The coordinator's synthesis role requires understanding both Red's adversarial perspective and Blue's defensive constraints, enabling balanced closure decisions.

purple-mapper

The Mapper maintains bidirectional linkage between Red findings and Blue defenses. For every Red attack vector, the mapper identifies the corresponding Blue countermeasure; for every Blue defense, the mapper identifies which Red attacks it addresses. This mapping reveals gaps — Red findings without Blue defenses, and Blue defenses without Red validation — which drive prioritization of subsequent Red and Blue activities.

purple-closure-analyst

The Closure Analyst evaluates findings against the four-condition closure framework, producing structured closure recommendations for the coordinator's decision. The analyst also detects false closure patterns — situations where findings appear closed but one or more conditions are not genuinely satisfied, such as paper defenses that pass tests but don't actually protect, or test suites that verify the wrong properties.

purple-regression-guard

The Regression Guard maintains a comprehensive catalog of all previously resolved vulnerabilities and their fixes, checking every code change against this catalog for potential regressions. The guard enforces deployment gates, blocking releases that introduce changes to code paths associated with previous vulnerabilities without corresponding verification.

The Closure Framework

Four Conditions for Closure

A finding is CLOSED only when ALL four conditions are independently verified:

Closure State Machine

stateDiagram-v2
    [*] --> OPEN
    OPEN --> INVESTIGATING
    INVESTIGATING --> MITIGATING
    INVESTIGATING --> ESCALATED: needs senior review
    MITIGATING --> VERIFYING
    MITIGATING --> BLOCKED: dependency missing
    VERIFYING --> CLOSED
    VERIFYING --> REGRESSED: re-attack succeeds
    ESCALATED --> OPEN
    BLOCKED --> OPEN
    REGRESSED --> OPEN
    CLOSED --> [*]

Closure Implementation

defmodule PrismaticDark.PurpleTeam.ClosureAnalyzer do
  @moduledoc """
  Four-condition closure evaluation for Purple Team findings.
  A finding is closed only when all four conditions are independently verified.
  """

  @type finding :: %{
    id: String.t(),
    state: :open | :investigating | :mitigating | :verifying | :closed,
    conditions: %{
      defense_implemented: boolean(),
      attack_blocked: boolean(),
      no_regression: boolean(),
      documented: boolean()
    },
    history: [state_transition()]
  }

  @spec evaluate_closure(finding()) :: {:ready, finding()} | {:not_ready, [atom()]}
  def evaluate_closure(%{conditions: conditions} = finding) do
    missing =
      conditions
      |> Enum.filter(fn {_condition, met} -> not met end)
      |> Enum.map(fn {condition, _} -> condition end)

    case missing do
      [] ->
        closed = %{finding | state: :closed}
        :telemetry.execute(
          [:prismatic, :purple_team, :closure, :complete],
          %{duration: closure_duration(finding)},
          %{finding_id: finding.id}
        )
        {:ready, closed}

      unmet ->
        {:not_ready, unmet}
    end
  end

  @spec detect_false_closure(finding()) :: {:genuine, finding()} | {:false_closure, map()}
  def detect_false_closure(finding) do
    checks = [
      {:paper_defense, check_paper_defense(finding)},
      {:test_mismatch, check_test_mismatch(finding)},
      {:regression_blind, check_regression_blind_spot(finding)},
      {:doc_stale, check_documentation_staleness(finding)}
    ]

    false_patterns = Enum.filter(checks, fn {_type, result} -> result != :ok end)

    case false_patterns do
      [] -> {:genuine, finding}
      patterns -> {:false_closure, %{finding: finding, violations: patterns}}
    end
  end
end

Red-Blue Synthesis

Bidirectional Mapping

The core synthesis activity maps every Red finding to its Blue defense counterpart and vice versa, revealing coverage gaps and verification needs.

Anti-Metric Enforcement

Purple actively detects and resists patterns that inflate security metrics without improving actual security posture. This anti-metric enforcement is a core Purple responsibility.

Technical Architecture

System Architecture

flowchart TD
    Coord["Purple Coordinator (L3)"]
    Coord --> Synth["Synthesis Engine"]
    Coord --> Map["Mapper Pipeline"]
    Coord --> Close["Closure Pipeline"]
    Coord --> Guard["Regression Guard"]
    Coord --> Out["Output Pipeline"]

    Synth --> S1["Finding Registry<br/>(master state)"]
    Synth --> S2["State Machine Manager"]
    Synth --> S3["Anti-Metric Monitor"]

    Map --> M1["Red-to-Blue Mapper"]
    Map --> M2["Blue-to-Red Mapper"]
    Map --> M3["Gap Detector"]
    Map --> M4["Coverage Calculator"]

    Close --> C1["Condition Evaluator"]
    Close --> C2["False Closure Detector"]
    Close --> C3["Closure Recommender"]
    Close --> C4["State Transition Mgr"]

    Guard --> G1["Trap Catalog Mgr"]
    Guard --> G2["Code Change Analyzer"]
    Guard --> G3["Regression Detector"]
    Guard --> G4["Deployment Gate Ctl"]

    Out --> O1["Closure Decision Emitter"]
    Out --> O2["Synthesis Report Gen"]
    Out --> O3["Deployment Gate Status"]

    classDef tier fill:#1e293b,stroke:#a855f7,color:#fff
    classDef leaf fill:#0f172a,stroke:#64748b,color:#e2e8f0
    class Coord,Synth,Map,Close,Guard,Out tier
    class S1,S2,S3,M1,M2,M3,M4,C1,C2,C3,C4,G1,G2,G3,G4,O1,O2,O3 leaf

Regression Guard Implementation

defmodule PrismaticDark.PurpleTeam.RegressionGuard do
  @moduledoc """
  Regression trap management and deployment gate enforcement.
  Maintains catalog of resolved vulnerabilities, checks changes for regressions.
  """
  use GenServer

  @spec regression_check(map()) :: {:ok, :clear} | {:error, :regression, map()}
  def regression_check(%{change_set: files} = params) do
    trap_catalog = load_trap_catalog(params[:trap_catalog] || :current)

    regressions =
      files
      |> Enum.flat_map(&check_file_against_traps(&1, trap_catalog))
      |> Enum.reject(&is_nil/1)

    case regressions do
      [] ->
        {:ok, :clear}

      found ->
        :telemetry.execute(
          [:prismatic, :purple_team, :regression, :detected],
          %{regression_count: length(found)},
          %{files: files}
        )
        {:error, :regression, %{regressions: found, change_set: files}}
    end
  end

  @spec deployment_gate(String.t()) :: :pass | {:block, String.t()}
  def deployment_gate(release_id) do
    open_findings = count_open_findings(:critical)
    active_regressions = count_active_regressions()
    incomplete_closures = count_incomplete_closures([:p0, :p1])

    cond do
      open_findings > 0 -> {:block, "#{open_findings} critical finding(s) open"}
      active_regressions > 0 -> {:block, "#{active_regressions} active regression(s)"}
      incomplete_closures > 0 -> {:block, "#{incomplete_closures} incomplete P0/P1 closure(s)"}
      true -> :pass
    end
  end
end

Telemetry Events

NABLA Compliance

Purple Team operations enforce NABLA axioms at the synthesis level, where multiple team outputs converge and must be reconciled.

Performance Metrics

Deployment Gate

Purple Team has binding veto authority over all deployments. The deployment gate checks are mandatory and non-bypassable.

Integration Points

Signal Flow

flowchart TD
    Red["Red Findings"]
    Blue["Blue Posture"]
    White["White Verification"]
    Gray["Gray Boundaries"]
    Black["Black Models<br/>(filtered)"]

    Red --> Synth["Purple Synthesis"]
    Blue --> Synth
    White --> Synth

    Synth --> Closure["Closure Engine"]
    Gray --> Closure
    Black --> Closure

    Closure --> Deploy["Deployment Gate"]
    Closure --> Quality["Quality Gates"]
    Closure --> Platform["Platform Improvements"]

    classDef input fill:#0f172a,stroke:#3b82f6,color:#fff
    classDef synth fill:#1e293b,stroke:#a855f7,color:#fff
    classDef output fill:#0f172a,stroke:#10b981,color:#fff
    class Red,Blue,White,Gray,Black input
    class Synth,Closure synth
    class Deploy,Quality,Platform output

Outputs

Related Resources

• Red Team — Adversarial findings that drive the synthesis process
• Blue Team — Defensive implementations that Purple verifies
• Gray Team — Boundary findings providing synthesis context
• White Team — Formal verification evidence for closure decisions
• Black Team — Theoretical threat models informing strategic synthesis
• Quality Gates — Quality enforcement incorporating Purple security posture
• Regression Testing — Testing infrastructure supporting regression detection

Connect & Contribute

Created by Tomáš Korcak (korczis) | Open Source under GHL

• GitHub | GitLab | LinkedIn | Contact
• Developer Portal | Architecture | Meet the Creator