Definition
Security synthesis is the disciplined process of integrating offensive security findings with defensive security capabilities to produce measurable improvements in overall security posture. It transcends the traditional separation between attack simulation and defense by creating a structured feedback loop where adversarial discoveries directly inform defensive improvements, and defensive gaps directly shape future adversarial campaigns. Security synthesis is not merely correlating Red and Blue team outputs -- it is the creation of emergent security knowledge that neither team could produce independently.
In the Prismatic Platform, security synthesis is the primary responsibility of the Purple Team, which operates as the central synthesis hub within the Color Teams framework. The Purple Team coordinates between the Red Team (adversarial simulation), Blue Team (epistemic defense), Gray Team (boundary exploration), White Team (constructive verification), and Black Team (theoretical threat modeling) to ensure that security findings flow through the entire pipeline from discovery to remediation to verification.
The platform's synthesis process is uniquely informed by the NABLA Infinity epistemic framework, which ensures that contradictory findings are preserved rather than resolved prematurely, that evidence from multiple independent sources is weighted appropriately, and that all synthesis conclusions can be traced back to their supporting evidence.
Historical Context
The concept of security synthesis evolved from the recognition that separate Red and Blue teams, while individually valuable, produce suboptimal results when operating in isolation. Traditional penetration testing produces reports that sit unread. Traditional defensive monitoring produces alerts that lack adversarial context. The Purple Team concept emerged in the mid-2010s as an attempt to bridge this gap.
Early Purple Team implementations were often ad hoc -- simply having Red and Blue team members in the same room during exercises. The Prismatic Platform advances this concept by formalizing the synthesis process into a structured, automated pipeline with explicit closure conditions, regression monitoring, and formal verification of defensive improvements.
The academic foundations draw from systems thinking, particularly the concept of feedback loops in complex adaptive systems. Security synthesis applies cybernetic principles -- observation, orientation, decision, action (the OODA loop) -- to the security domain, creating a continuous improvement cycle that adapts to evolving threat landscapes.
Platform Context
Within the Prismatic Platform, security synthesis operates as a first-class concern with dedicated infrastructure, agents, and enforcement mechanisms. The synthesis pipeline processes findings from all Color Teams, maps them to defensive capabilities, evaluates closure conditions, and tracks regression over time.
The platform's 20 Color Team agents across 6 teams generate a continuous stream of security signals. The synthesis layer must integrate these signals into a coherent security posture without losing contradictions, premature closure, or survivorship bias. This is where the NABLA framework's contradiction preservation axiom becomes critical -- conflicting signals from Red and Blue teams are preserved as data points requiring explanation, not errors to be resolved.
defmodule PrismaticDark.SecuritySynthesis do
@moduledoc """
Orchestrates the integration of adversarial findings with
defensive capabilities to produce actionable security improvements.
The synthesis engine processes findings from all Color Teams,
maps attack paths to defense capabilities, evaluates closure
conditions, and maintains a regression monitoring system.
## Architecture
The synthesis pipeline operates in four phases:
1. Finding Ingestion - Collect and normalize findings from all teams
2. Mapping - Bidirectional mapping between attacks and defenses
3. Closure Evaluation - Four-condition closure assessment
4. Regression Monitoring - Continuous verification of closed findings
## NABLA Compliance
All synthesis operations preserve signal plurality, maintain
contradiction records, and track full provenance chains.
"""
@type finding_id :: String.t()
@type team :: :red | :blue | :gray | :white | :black
@type severity :: :critical | :high | :medium | :low | :informational
@type closure_status :: :open | :in_progress | :pending_verification | :closed | :false_closure
@type finding :: %{
id: finding_id(),
team: team(),
severity: severity(),
description: String.t(),
evidence: [map()],
attack_path: [String.t()],
affected_assets: [String.t()],
timestamp: DateTime.t(),
provenance: map()
}
@type synthesis_result :: %{
finding_id: finding_id(),
red_findings: [finding()],
blue_defenses: [map()],
coverage_gaps: [String.t()],
closure_status: closure_status(),
closure_conditions: map(),
confidence: float(),
recommendations: [String.t()]
}
@spec synthesize(finding_id()) :: {:ok, synthesis_result()} | {:error, term()}
def synthesize(finding_id) do
with {:ok, red_findings} <- collect_red_findings(finding_id),
{:ok, blue_defenses} <- collect_blue_defenses(finding_id),
{:ok, mapping} <- create_attack_defense_mapping(red_findings, blue_defenses),
{:ok, gaps} <- identify_coverage_gaps(mapping),
{:ok, closure} <- evaluate_closure(mapping, gaps),
:ok <- record_synthesis(finding_id, mapping, closure) do
{:ok,
%{
finding_id: finding_id,
red_findings: red_findings,
blue_defenses: blue_defenses,
coverage_gaps: gaps,
closure_status: closure.status,
closure_conditions: closure.conditions,
confidence: closure.confidence,
recommendations: generate_recommendations(gaps, closure)
}}
end
end
@spec evaluate_closure(map(), [String.t()]) :: {:ok, map()} | {:error, :incomplete}
defp evaluate_closure(mapping, gaps) do
conditions = %{
attack_reproduced: attack_reproduction_verified?(mapping),
defense_deployed: defense_deployment_confirmed?(mapping),
gaps_addressed: Enum.empty?(gaps),
regression_test_added: regression_tests_present?(mapping)
}
status =
cond do
all_conditions_met?(conditions) -> :closed
false_closure_detected?(conditions) -> :false_closure
any_condition_met?(conditions) -> :in_progress
true -> :open
end
confidence = calculate_closure_confidence(conditions)
{:ok, %{status: status, conditions: conditions, confidence: confidence}}
end
@spec all_conditions_met?(map()) :: boolean()
defp all_conditions_met?(conditions) do
Enum.all?(Map.values(conditions), & &1)
end
@spec false_closure_detected?(map()) :: boolean()
defp false_closure_detected?(conditions) do
conditions.defense_deployed and not conditions.regression_test_added
end
endThe Synthesis Loop
Signal Flow Architecture
The security synthesis loop follows a structured signal flow through the Color Team hierarchy:
- Gray Team surfaces boundary conditions and specification gaps through read-only exploration
- Red Team transforms boundary findings into adversarial scenarios using five attack primitives
- Purple Team receives Red findings and maps them to Blue Team defensive capabilities
- Blue Team evaluates its defensive posture against the mapped attack paths
- Purple Team synthesizes Red-Blue analysis into closure assessments
- White Team formally verifies that deployed defenses actually address the findings
- Black Team provides abstract threat models that inform future Gray exploration
This creates a continuous cycle where each iteration deepens the platform's security understanding. The cycle is not linear -- multiple findings can be in different stages simultaneously, and new findings can trigger re-evaluation of previously closed items.
Bidirectional Mapping
The core of security synthesis is the bidirectional mapping between attack paths and defense capabilities. Each Red Team finding is mapped to the specific Blue Team defenses that should detect or prevent it, and each Blue Team defense is mapped to the attack paths it covers. This mapping reveals coverage gaps (attacks without matching defenses) and blind spots (defenses without tested attack paths).
defmodule PrismaticDark.SecuritySynthesis.Mapper do
@moduledoc """
Creates bidirectional mappings between Red Team attack paths
and Blue Team defensive capabilities. Identifies coverage gaps
and blind spots in the security posture.
"""
@type attack_path :: %{
id: String.t(),
techniques: [String.t()],
targets: [String.t()],
prerequisites: [String.t()]
}
@type defense :: %{
id: String.t(),
capability: String.t(),
coverage: [String.t()],
detection_confidence: float()
}
@type mapping :: %{
attack_to_defense: %{String.t() => [String.t()]},
defense_to_attack: %{String.t() => [String.t()]},
uncovered_attacks: [String.t()],
untested_defenses: [String.t()]
}
@spec create_mapping([attack_path()], [defense()]) :: {:ok, mapping()}
def create_mapping(attacks, defenses) do
attack_to_defense =
attacks
|> Enum.map(fn attack ->
matching_defenses =
defenses
|> Enum.filter(fn defense ->
Enum.any?(attack.techniques, &(&1 in defense.coverage))
end)
|> Enum.map(& &1.id)
{attack.id, matching_defenses}
end)
|> Map.new()
defense_to_attack =
defenses
|> Enum.map(fn defense ->
matching_attacks =
attacks
|> Enum.filter(fn attack ->
Enum.any?(attack.techniques, &(&1 in defense.coverage))
end)
|> Enum.map(& &1.id)
{defense.id, matching_attacks}
end)
|> Map.new()
uncovered =
attack_to_defense
|> Enum.filter(fn {_id, defenses} -> Enum.empty?(defenses) end)
|> Enum.map(fn {id, _} -> id end)
untested =
defense_to_attack
|> Enum.filter(fn {_id, attacks} -> Enum.empty?(attacks) end)
|> Enum.map(fn {id, _} -> id end)
{:ok,
%{
attack_to_defense: attack_to_defense,
defense_to_attack: defense_to_attack,
uncovered_attacks: uncovered,
untested_defenses: untested
}}
end
endFour-Condition Closure Model
The Prismatic Platform uses a rigorous four-condition model for determining when a security finding can be considered closed. All four conditions must be satisfied for genuine closure; partial satisfaction indicates work in progress, and specific violation patterns indicate false closure.
Condition 1: Attack Reproduction Verified
The original attack path must be independently reproducible within the sandbox environment. This verifies that the finding is real and that the defense is addressing the actual vulnerability rather than a symptom. Reproduction uses synthetic data and isolated execution to prevent any risk to production systems.
Condition 2: Defense Deployed and Validated
A concrete defensive measure must be implemented and deployed. The defense must be validated by the White Team through formal verification or property-based testing to confirm that it actually addresses the attack path, not merely the specific test case.
Condition 3: Coverage Gaps Addressed
All identified coverage gaps related to the finding must be addressed. This includes not only the specific attack path but also related variants that share common attack prerequisites. The synthesis mapping identifies these related paths automatically.
Condition 4: Regression Tests Added
Automated regression tests must be added that verify the defense remains effective over time. These tests run as part of the platform's continuous integration pipeline, ensuring that future changes do not inadvertently reintroduce the vulnerability. This condition directly supports the platform's mandatory regression test protocol.
False Closure Detection
One of the most critical functions of security synthesis is detecting false closure -- situations where a finding appears to be resolved but the underlying vulnerability persists. False closure is more dangerous than an open finding because it creates a false sense of security.
The Purple Team's purple-closure-analyst agent actively monitors for false closure indicators:
- Defense without regression tests: A defense was deployed but no automated verification was added, meaning future changes could silently break the defense
- Narrow defense: The defense addresses the specific attack variant but not the underlying vulnerability class
- Untested defense: The defense was deployed but never validated against the actual attack path
- Regression trap: A previously closed finding has reopened, indicating that the original closure was incomplete
defmodule PrismaticDark.SecuritySynthesis.FalseClosureDetector do
@moduledoc """
Detects false closure conditions where security findings
appear resolved but underlying vulnerabilities persist.
"""
@type indicator :: :defense_without_tests | :narrow_defense | :untested_defense | :regression_trap
@type detection_result :: {:genuine_closure, float()} | {:false_closure, [indicator()]}
@spec evaluate(map()) :: detection_result()
def evaluate(closure_state) do
indicators =
[]
|> check_test_coverage(closure_state)
|> check_defense_breadth(closure_state)
|> check_defense_validation(closure_state)
|> check_regression_history(closure_state)
case indicators do
[] -> {:genuine_closure, calculate_confidence(closure_state)}
indicators -> {:false_closure, indicators}
end
end
@spec check_test_coverage([indicator()], map()) :: [indicator()]
defp check_test_coverage(indicators, %{regression_tests: tests}) do
if Enum.empty?(tests), do: [:defense_without_tests | indicators], else: indicators
end
@spec check_defense_breadth([indicator()], map()) :: [indicator()]
defp check_defense_breadth(indicators, %{covered_variants: covered, total_variants: total}) do
if covered / total < 0.8, do: [:narrow_defense | indicators], else: indicators
end
@spec check_defense_validation([indicator()], map()) :: [indicator()]
defp check_defense_validation(indicators, %{defense_validated: validated}) do
if not validated, do: [:untested_defense | indicators], else: indicators
end
@spec check_regression_history([indicator()], map()) :: [indicator()]
defp check_regression_history(indicators, %{previous_closures: closures}) do
if length(closures) > 1, do: [:regression_trap | indicators], else: indicators
end
endEpistemic Security Integration
Security synthesis in the Prismatic Platform is deeply integrated with the NABLA Infinity epistemic framework. This integration ensures that synthesis conclusions meet the same evidence standards as all other platform decisions.
The signal plurality axiom requires that security findings be confirmed by at least two independent signals before driving synthesis actions. A Red Team finding alone is insufficient; it must be corroborated by Blue Team telemetry, Gray Team boundary analysis, or White Team verification.
The contradiction preservation axiom is particularly important in security synthesis. When Red Team findings contradict Blue Team assessments (for example, when an attack path succeeds despite an ostensibly effective defense), both signals are preserved as data requiring investigation rather than either being discarded. These contradictions often reveal the most critical security insights.
The provenance tracking axiom ensures that every synthesis conclusion can be traced back through the full evidence chain: from the original Gray Team boundary exploration, through Red Team attack simulation, Blue Team defensive analysis, and Purple Team synthesis, to the final White Team verification. This audit trail is essential for both compliance requirements and post-incident analysis.
Regression Monitoring
Synthesis does not end at closure. The purple-regression-guard agent continuously monitors closed findings for regression indicators. This includes automated re-execution of regression tests, monitoring for code changes that affect closed findings, and periodic Red Team re-validation of previously addressed attack paths.
The regression monitoring system maintains a "regression trap" database that tracks which findings have historically been prone to regression. Findings that reopen after closure receive elevated monitoring and additional closure conditions on subsequent attempts.
Integration with Platform Security
Security synthesis feeds directly into the platform's security operations framework. Synthesis results inform the Prismatic Perimeter EASM system's security ratings, providing evidence-based scores rather than heuristic estimates. Synthesis findings also drive updates to the platform's threat model, compliance assessments (NIS2, ZKB), and security training content.
The synthesis pipeline integrates with the platform's quality gates to ensure that security findings are treated with the same rigor as quality metrics. Security regressions block deployments just as quality regressions do, and security synthesis confidence levels must meet the same thresholds as quality confidence levels.
Metrics and Measurement
The effectiveness of security synthesis is measured through several quantitative indicators:
- Mean Time to Closure (MTTC): Average time from finding discovery to verified closure
- False Closure Rate: Percentage of closures that are subsequently identified as false
- Coverage Delta: Change in defense coverage after each synthesis cycle
- Regression Rate: Frequency of closed findings reopening
- Blind Spot Discovery Rate: Rate at which untested defenses are identified and validated
These metrics are tracked longitudinally and compared across synthesis cycles to measure improvement in the overall security process, not just individual findings.
Industry Context
The Prismatic Platform's approach to security synthesis is distinguished by its formal structure and automated enforcement. While many organizations practice some form of Purple Team exercises, few have codified the synthesis process into automated pipelines with explicit closure conditions, false closure detection, and regression monitoring. The integration with the NABLA epistemic framework adds a dimension of evidence rigor that is absent from typical Purple Team operations.
The platform's approach aligns with and extends frameworks such as MITRE ATT&CK (for attack taxonomy), the NIST Cybersecurity Framework (for defense categorization), and the Diamond Model of Intrusion Analysis (for adversarial relationship modeling). However, it goes beyond these frameworks by providing automated synthesis machinery rather than manual assessment templates.
Related Concepts
- Purple Team -- Primary synthesis team responsible for Red-Blue loop closure
- Red Team -- Adversarial simulation producing findings for synthesis
- Blue Team -- Epistemic defense providing defensive capabilities for mapping
- Black Team -- Theoretical threat modeling informing synthesis scope
- Color Teams -- Full Color Team framework driving the synthesis pipeline
- Sandbox -- Isolated execution environment for attack reproduction
- Trinity Gate -- Validation gate for synthesis conclusions
- NABLA Infinity -- Epistemic framework ensuring evidence rigor in synthesis
- Adversarial Simulation -- Attack simulation within sandbox boundaries
- Evidence -- Evidence handling and provenance for synthesis findings
- Security Operations -- Operational security informed by synthesis results
Connect & Contribute: Created by Tomas Korcak (korczis) | GitHub | GitLab | LinkedIn | Contact