Skip to main content
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 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

1

Scanner — find the surface

Automated vulnerability scanning across the target. Output: candidate findings (CVE matches, configuration issues, exposed surfaces).
2

Detector — write the rule

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.
3

Verifier — prove it's real

Two-method gate: confirm the vulnerability through at least two independent verification techniques. Eliminates false positives before exploit work begins.
4

Patcher — propose and verify the fix

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.
5

Exploiter — try to break the patch

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.
AgentInputsOutputs
ScannerTarget scopeCandidate findings list
DetectorCandidate findingDetection rule (Sigma / YARA / heuristic)
VerifierCandidate + detection ruleVerified-yes or verified-no, with two methods of evidence
PatcherVerified candidatePatch (code or config) + patch_verify proof the fix closes the bug
ExploiterPatched candidateReproducible 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.

Knowledge Graph

How findings, detections, and patches land in the Neo4j attack graph.

Skill System

Each pipeline stage has a dedicated skill set under skills/scanner/, skills/detector/, etc.