> ## Documentation Index
> Fetch the complete documentation index at: https://docs.decepticon.red/llms.txt
> Use this file to discover all available pages before exploring further.
# Offensive Vaccine Pipeline
> The five-stage vulnerability research pipeline (Scanner → Detector → Verifier → Patcher → Exploiter) plus the planned defense closing loop.
The **five-stage Vulnresearch pipeline** described below ships today, driven by the `Vulnresearch` orchestrator and its five sub-agents. The **defense-closing half** of the loop (the "Defender" agent, automated mitigation backends, re-attack verification) is a **planned product direction** — not an active implementation in the current codebase. The previous Defender graph and Docker defense backend have been removed and a future implementation will be rebuilt around OPPLAN middleware. See [`docs/offensive-vaccine.md`](https://github.com/PurpleAILAB/Decepticon/blob/main/docs/offensive-vaccine.md) in the repo.
The **Offensive Vaccine** is the loop that gives Decepticon its name and its purpose: every offensive action becomes a defensive artifact. This page documents the five-stage Vulnresearch pipeline that ships today, and the planned defense-side components that will eventually close the loop.
## The Loop
```
attack → detection rule → verification → exploit PoC → patch
↑ │
└───────────────────────────────────────────────────────┘
regression coverage
```
Each stage is owned by a specialist agent. Together they implement what the security industry calls "purple teaming," fully automated.
## The Five Stages
Automated vulnerability scanning across the target. Output: candidate findings (CVE matches, configuration issues, exposed surfaces).
Generate a detection signal for the candidate vulnerability — Sigma rule, YARA rule, IDS signature, or telemetry-derived heuristic. Defenders need to know *what* to look for before they can detect it.
Two-method gate: confirm the vulnerability through at least two independent verification techniques. Eliminates false positives before exploit work begins.
Generate a minimal patch — code change, configuration change, compensating control — that closes the vulnerability without breaking the application, then prove the fix holds via `patch_verify`. Patching *before* PoC is the offensive-vaccine inversion: the defender's diff is the artifact under test.
Author a reproducible proof-of-concept that targets the patched candidate. If the PoC succeeds against the patched code, the patch is incomplete and the loop iterates; if the PoC fails, the patch is hardened evidence the fix held.
## The Vulnresearch Orchestrator
The five agents do not run as a fixed pipeline — they are orchestrated by a sixth agent, **Vulnresearch**, that decides the order based on findings. If the Scanner produces a high-confidence candidate, Vulnresearch may skip directly to Verifier. If the Verifier rejects a candidate, the loop terminates without burning Patcher or Exploiter resources.
| Agent | Inputs | Outputs |
| ------------- | -------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| **Scanner** | Target scope | Candidate findings list |
| **Detector** | Candidate finding | Detection rule (Sigma / YARA / heuristic) |
| **Verifier** | Candidate + detection rule | Verified-yes or verified-no, with two methods of evidence |
| **Patcher** | Verified candidate | Patch (code or config) + `patch_verify` proof the fix closes the bug |
| **Exploiter** | Patched candidate | Reproducible PoC against the patch — *fails* if the patch held, *succeeds* if the patch is incomplete (loop iterates) |
## The Planned Defense Component
This component is not implemented in the current codebase — the previous Defender graph and Docker defense backend were removed, and a future replacement will be rebuilt around OPPLAN middleware and a dedicated vaccine concept. Today the Vulnresearch pipeline's artifacts (detection rules, PoCs, patches) are persisted to the workspace and knowledge graph, and a human operator hands them to the blue team.
The planned defense-closing component is *not* part of the five-stage pipeline — it is intended to be a parallel agent that consumes the artifacts and produces the **Defense Brief**: the document handed to the blue team at engagement out-brief.
The Defense Brief is planned to contain:
* The technique used (MITRE ATT\&CK ID)
* The detection rule produced by the Detector
* The PoC produced by the Exploiter
* The recommended patch from the Patcher
* The verification status (did the patch break the PoC?)
* The mapping to the blue team's existing detection coverage (gaps)
This is the artifact that will eventually transform an offensive engagement into a defensive uplift. Until that component lands, operators assemble the brief manually from the workspace outputs.
## Why Two-Method Verification Matters
A single verification method can be fooled — a network scan might match a banner without the vulnerable code being reachable; a PoC might succeed against a honeypot. The Verifier requires **two independent methods**, e.g.:
* Static evidence (version banner) + dynamic evidence (PoC payload response)
* Network-side detection (IDS firing) + host-side detection (process artifact)
* Source-code analysis + runtime instrumentation
Decepticon refuses to escalate a finding to the Patcher / Exploiter stages without the two-method gate. This dramatically reduces wasted compute and false alarms in the engagement record.
## Knowledge Graph Integration
Every artifact produced by the pipeline lands in the **Neo4j attack graph**:
* Findings become `Vulnerability` nodes
* Detection rules become `DefenseAction` nodes with `DETECTS` edges
* Patches become `DefenseAction` nodes with `MITIGATES` edges
* Verifications become provenance edges
The graph is queryable mid-engagement and exportable as the engagement deliverable.
How findings, detections, and patches land in the Neo4j attack graph.
Each pipeline stage has a dedicated skill set under `skills/scanner/`, `skills/detector/`, etc.