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

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.

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.