Raven — 0-Day Fixing
This skill is Raven's remediation layer. It turns a confirmed root cause into an applied patch or a verified rollback. It does NOT investigate (use raven-zero-day-investigator) and it does NOT decide policy (use raven-zero-day-auto-prevent). Every patch passes through the approval gate and at least one verifier oracle before it is applied.
When to use
Trigger when the user asks any of:
- "Fix / patch CVE-YYYY-NNNNN in
<repo>"
- "Generate a fix for this confirmed finding"
- "Virtual-patch this at the WAF / sidecar layer"
- "Rollback this unsafe deployment"
- "Apply remediation for
<finding>"
Do not trigger for: pre-confirmation speculation (use raven-zero-day-investigator first), routine dependency bumps (handle outside Raven), or any patch without a confirmed root cause record.
Inputs
Required:
- Confirmed finding — root-cause record from
raven-zero-day-investigator OR a validated finding from raven-zero-day-hunter. The record MUST include cwe, location, d3fend_techniques, and validator evidence.
- Fix mode — one of:
source-patch, virtual-patch, config-harden, rollback
- Verification depth —
unit-tests, unit-plus-static, unit-plus-static-plus-fuzz, formal (last is Solana / EVM only)
Optional:
- Approval mode —
manual by default for source-patch and rollback, smart allowed for virtual-patch and config-harden
- Time budget — wall-clock cap
Pipeline — six mandatory stages
Stage 1 — Finding intake (𝒯-grounded)
- Validate the finding record's schema; reject if missing CWE, location, or D3FEND ids.
- Confirm the validator evidence path still exists and re-run the validator one more time. If the issue no longer reproduces, the skill aborts with
already_fixed_or_drift — patching a non-issue is forbidden.
- Resolve every D3FEND technique id in the finding via
raven.d3fend.api.lookup_technique. Reject unresolved ids.
Stage 2 — Fix-mode routing
| Fix mode |
Primary module |
Verifier oracles |
source-patch |
raven/mitigation/remediation_engine.py |
unit tests + raven/tools/ares.py re-run + raven/ml/code_flow_scanner.py |
virtual-patch |
raven/tools/nuclei_scanner.py template + WAF/sidecar config emitter |
Nuclei replay against the vulnerable surface |
config-harden |
raven/mitigation/response_orchestrator.py |
configuration verifier (own-asset only) |
rollback |
restore/ subsystem (restore-subsystem-spec.md) |
restore primitive's own verifier (D3-RS / D3-RC return success) |
The skill MUST pick exactly one mode. Multi-mode fixes are decomposed into separate runs.
Stage 3 — Patch generation (𝓛-scored, 𝒯-bound)
For source-patch:
raven/mitigation/remediation_engine.py emits one or more candidate patches as unified diffs. The engine consults the finding's CWE, the local code style, and any pinned dependencies.
- Each candidate MUST be regex-validated and shlex-quoted (the engine's existing safety property) — the skill does not write shell-strings.
- The LLM may rank candidates but MUST NOT author them outside the engine. If the engine cannot produce a candidate, the skill emits
no_engine_candidate and falls back to virtual-patch if eligible, otherwise stops.
For virtual-patch:
- Generate a Nuclei template / WAF rule from the finding's evidence features.
- The template MUST be reviewable as plain text and MUST be defensive only (block / log, never exploit).
For config-harden:
- Emit a diff against the affected config file (e.g. AppArmor profile, nginx config, sysctl entry).
For rollback:
- Look up the most recent good checkpoint via the
restore/ subsystem.
- Confirm the checkpoint's hash matches its recorded value.
Stage 4 — Pre-application verification (𝒯-grounded, mandatory)
For source-patch:
- Apply the patch to a sandboxed branch / worktree.
- Run the project's test suite. Fail if any test regresses.
- Re-run
ares.py or code_flow_scanner.py and confirm the finding no longer reproduces.
- If verification depth includes
fuzz, run a short fuzz session and require no new crashes.
- If verification depth is
formal and the target is Solana / EVM, run the formal-verification stub in raven/ml/vulnerability_validator.py against the patched program.
For virtual-patch:
- Stage the rule in a shadow mode against replayed traffic.
- Confirm zero false positives on a known-good replay batch and ≥ 1 true positive on the exploit payload.
For config-harden:
- Parse-check the new config (syntax).
- Apply in a staging environment if available; confirm the affected service still starts and serves health checks.
For rollback:
- Verify the checkpoint integrity hash before any state mutation.
- Dry-run the rollback against an isolated copy if the
restore/ subsystem supports it.
If any verifier fails, the patch is NOT promoted. The skill emits verification_failed and exits.
Stage 5 — Approval gate
Route the verified candidate through raven/approval/gate.py. The skill MUST supply:
- The finding record
- The unified diff (or rule / config / checkpoint reference)
- The verifier results (test counts, oracle outputs, fuzz session summary)
- The D3FEND id this fix claims to implement
raven/approval/smart.py may auto-approve virtual-patch and config-harden actions that pass all verifiers. source-patch and rollback always require manual approval unless the user explicitly configured otherwise in policy via raven-zero-day-auto-prevent.
UNRECOVERABLE_BLOCKLIST patterns are hard-rejected.
Stage 6 — Apply and post-verify (𝒯-grounded)
After approval, apply the change through the appropriate module:
source-patch → remediation_engine.apply(...) — note this is the same module that owns the existing patch-apply path
virtual-patch → install WAF/sidecar rule via the configured provider's API
config-harden → response_orchestrator.execute_config_change(...)
rollback → invoke the restore/ subsystem's primitive matching the D3FEND id (D3-RS, D3-RC, etc.)
After application, run a final verifier pass on the live target. If post-verify fails:
- For
source-patch / config-harden / rollback — initiate the restore/ subsystem's automatic recovery (return to pre-change state) and escalate.
- For
virtual-patch — disable the rule and escalate.
CDP contract — quick check before applying
assert finding.confirmed is True
assert finding.cwe is not None
assert all d3fend_id in fix.d3fend_techniques resolve through ontology
assert pre_application_verifier_results.all_passed is True
assert approval_gate_decision == "approve"
assert at least one 𝒯 verifier oracle was invoked
Any failed assertion blocks the apply step.
Output contract
# Raven 0-Day Fix — <finding_id>
## Finding reference
- CWE: <id>
- Location: <file:lines or symbol or address>
- Validator evidence: <path>
- D3FEND tags on fix: <id list>
## Fix mode
- Mode: <source-patch|virtual-patch|config-harden|rollback>
- Generator module: <module>
- Candidate count: <n>
- Selected candidate: <id>
## Pre-application verification
| Verifier | Result | Detail |
|----------|--------|--------|
| Unit tests | pass / fail (<n>) | <summary> |
| ares.py re-run | not-reproduced / reproduced | <path> |
| code_flow_scanner | clean / hit | <path> |
| fuzz session | no-crash / crash (<n>) | <wall-clock> |
| formal | proved / counterexample | <path> |
## Approval
- Mode: <smart|manual>
- Decision: <approve|deny|escalate>
- Reason: <reason>
## Apply
- Wall-clock: <s>
- Side-effect handle: <pid / rule_id / commit_sha / checkpoint_id>
## Post-verification
| Check | Result |
|-------|--------|
| Live re-run | not-reproduced |
| Service health | green |
## Reproducibility kit
- Patch diff: <path>
- Verifier traces: <path>
- Commit: <sha>
- Audit record: <id>
Refusal rules
- Refuse to apply any patch without re-running the validator and confirming the issue still reproduces in Stage 1.
- Refuse to apply any patch that regresses the test suite.
- Refuse to apply a
source-patch or rollback in smart mode unless an active raven-zero-day-auto-prevent policy explicitly allows it.
- Refuse to bypass the approval gate.
- Refuse to apply without a D3FEND id tag — every fix MUST cite the Harden or Restore technique it implements.
- Refuse to ship a virtual patch that has zero true positives in shadow mode.
- Refuse rollback without checkpoint integrity verification.
Related skills
raven-zero-day-investigator — upstream producer of confirmed findings.
raven-zero-day-defend — sibling skill that stages the same actions before they execute.
raven-zero-day-auto-prevent — invokes this skill when policy authorizes automatic fixes.
restore/ subsystem — owns the rollback mode primitives (restore-subsystem-spec).
- D3FEND OWL integration (
raven/d3fend/) — source of every Harden / Restore id on every fix (D3FEND home).
1---2name: raven-zero-day-fixing3description: Generate, verify, and apply patches for a confirmed 0-day finding. Use when the user says "fix this 0-day", "patch this CVE", "generate the fix", "virtual-patch this", "rollback unsafe change", "apply remediation", or hands over a confirmed root cause from `raven-zero-day-investigator`. Every patch terminates at a tool oracle (𝒯) — static verifier, test suite, formal check, or restore primitive — never raw LLM speculation, and every fix is tagged with a D3FEND Harden / Restore technique id.4---56# Raven — 0-Day Fixing78This skill is Raven's remediation layer. It turns a confirmed root cause into an applied patch or a verified rollback. It does NOT investigate (use `raven-zero-day-investigator`) and it does NOT decide policy (use `raven-zero-day-auto-prevent`). Every patch passes through the approval gate and at least one verifier oracle before it is applied.910## When to use1112Trigger when the user asks any of:1314- "Fix / patch CVE-YYYY-NNNNN in `<repo>`"15- "Generate a fix for this confirmed finding"16- "Virtual-patch this at the WAF / sidecar layer"17- "Rollback this unsafe deployment"18- "Apply remediation for `<finding>`"1920Do not trigger for: pre-confirmation speculation (use `raven-zero-day-investigator` first), routine dependency bumps (handle outside Raven), or any patch without a confirmed root cause record.2122## Inputs2324Required:25261. Confirmed finding — root-cause record from `raven-zero-day-investigator` OR a validated finding from `raven-zero-day-hunter`. The record MUST include `cwe`, `location`, `d3fend_techniques`, and validator evidence.272. Fix mode — one of: `source-patch`, `virtual-patch`, `config-harden`, `rollback`283. Verification depth — `unit-tests`, `unit-plus-static`, `unit-plus-static-plus-fuzz`, `formal` (last is Solana / EVM only)2930Optional:3132- Approval mode — `manual` by default for `source-patch` and `rollback`, `smart` allowed for `virtual-patch` and `config-harden`33- Time budget — wall-clock cap3435## Pipeline — six mandatory stages3637### Stage 1 — Finding intake (𝒯-grounded)38391. Validate the finding record's schema; reject if missing CWE, location, or D3FEND ids.402. Confirm the validator evidence path still exists and re-run the validator one more time. If the issue no longer reproduces, the skill aborts with `already_fixed_or_drift` — patching a non-issue is forbidden.413. Resolve every D3FEND technique id in the finding via `raven.d3fend.api.lookup_technique`. Reject unresolved ids.4243### Stage 2 — Fix-mode routing4445| Fix mode | Primary module | Verifier oracles |46|----------|----------------|------------------|47| `source-patch` | `raven/mitigation/remediation_engine.py` | unit tests + `raven/tools/ares.py` re-run + `raven/ml/code_flow_scanner.py` |48| `virtual-patch` | `raven/tools/nuclei_scanner.py` template + WAF/sidecar config emitter | Nuclei replay against the vulnerable surface |49| `config-harden` | `raven/mitigation/response_orchestrator.py` | configuration verifier (own-asset only) |50| `rollback` | `restore/` subsystem (`restore-subsystem-spec.md`) | restore primitive's own verifier (D3-RS / D3-RC return success) |5152The skill MUST pick exactly one mode. Multi-mode fixes are decomposed into separate runs.5354### Stage 3 — Patch generation (𝓛-scored, 𝒯-bound)5556For `source-patch`:57581. `raven/mitigation/remediation_engine.py` emits one or more candidate patches as unified diffs. The engine consults the finding's CWE, the local code style, and any pinned dependencies.592. Each candidate MUST be regex-validated and shlex-quoted (the engine's existing safety property) — the skill does not write shell-strings.603. The LLM may rank candidates but MUST NOT author them outside the engine. If the engine cannot produce a candidate, the skill emits `no_engine_candidate` and falls back to `virtual-patch` if eligible, otherwise stops.6162For `virtual-patch`:63641. Generate a Nuclei template / WAF rule from the finding's evidence features.652. The template MUST be reviewable as plain text and MUST be defensive only (block / log, never exploit).6667For `config-harden`:68691. Emit a diff against the affected config file (e.g. AppArmor profile, nginx config, sysctl entry).7071For `rollback`:72731. Look up the most recent good checkpoint via the `restore/` subsystem.742. Confirm the checkpoint's hash matches its recorded value.7576### Stage 4 — Pre-application verification (𝒯-grounded, mandatory)7778For `source-patch`:79801. Apply the patch to a sandboxed branch / worktree.812. Run the project's test suite. Fail if any test regresses.823. Re-run `ares.py` or `code_flow_scanner.py` and confirm the finding no longer reproduces.834. If verification depth includes `fuzz`, run a short fuzz session and require no new crashes.845. If verification depth is `formal` and the target is Solana / EVM, run the formal-verification stub in `raven/ml/vulnerability_validator.py` against the patched program.8586For `virtual-patch`:87881. Stage the rule in a shadow mode against replayed traffic.892. Confirm zero false positives on a known-good replay batch and ≥ 1 true positive on the exploit payload.9091For `config-harden`:92931. Parse-check the new config (syntax).942. Apply in a staging environment if available; confirm the affected service still starts and serves health checks.9596For `rollback`:97981. Verify the checkpoint integrity hash before any state mutation.992. Dry-run the rollback against an isolated copy if the `restore/` subsystem supports it.100101If any verifier fails, the patch is NOT promoted. The skill emits `verification_failed` and exits.102103### Stage 5 — Approval gate104105Route the verified candidate through `raven/approval/gate.py`. The skill MUST supply:106107- The finding record108- The unified diff (or rule / config / checkpoint reference)109- The verifier results (test counts, oracle outputs, fuzz session summary)110- The D3FEND id this fix claims to implement111112`raven/approval/smart.py` may auto-approve `virtual-patch` and `config-harden` actions that pass all verifiers. `source-patch` and `rollback` always require `manual` approval unless the user explicitly configured otherwise in policy via `raven-zero-day-auto-prevent`.113114`UNRECOVERABLE_BLOCKLIST` patterns are hard-rejected.115116### Stage 6 — Apply and post-verify (𝒯-grounded)117118After approval, apply the change through the appropriate module:119120- `source-patch` → `remediation_engine.apply(...)` — note this is the same module that owns the existing patch-apply path121- `virtual-patch` → install WAF/sidecar rule via the configured provider's API122- `config-harden` → `response_orchestrator.execute_config_change(...)`123- `rollback` → invoke the `restore/` subsystem's primitive matching the D3FEND id (D3-RS, D3-RC, etc.)124125After application, run a final verifier pass on the live target. If post-verify fails:126127- For `source-patch` / `config-harden` / `rollback` — initiate the `restore/` subsystem's automatic recovery (return to pre-change state) and escalate.128- For `virtual-patch` — disable the rule and escalate.129130## CDP contract — quick check before applying131132```133assert finding.confirmed is True134assert finding.cwe is not None135assert all d3fend_id in fix.d3fend_techniques resolve through ontology136assert pre_application_verifier_results.all_passed is True137assert approval_gate_decision == "approve"138assert at least one 𝒯 verifier oracle was invoked139```140141Any failed assertion blocks the apply step.142143## Output contract144145```markdown146# Raven 0-Day Fix — <finding_id>147148## Finding reference149- CWE: <id>150- Location: <file:lines or symbol or address>151- Validator evidence: <path>152- D3FEND tags on fix: <id list>153154## Fix mode155- Mode: <source-patch|virtual-patch|config-harden|rollback>156- Generator module: <module>157- Candidate count: <n>158- Selected candidate: <id>159160## Pre-application verification161| Verifier | Result | Detail |162|----------|--------|--------|163| Unit tests | pass / fail (<n>) | <summary> |164| ares.py re-run | not-reproduced / reproduced | <path> |165| code_flow_scanner | clean / hit | <path> |166| fuzz session | no-crash / crash (<n>) | <wall-clock> |167| formal | proved / counterexample | <path> |168169## Approval170- Mode: <smart|manual>171- Decision: <approve|deny|escalate>172- Reason: <reason>173174## Apply175- Wall-clock: <s>176- Side-effect handle: <pid / rule_id / commit_sha / checkpoint_id>177178## Post-verification179| Check | Result |180|-------|--------|181| Live re-run | not-reproduced |182| Service health | green |183184## Reproducibility kit185- Patch diff: <path>186- Verifier traces: <path>187- Commit: <sha>188- Audit record: <id>189```190191## Refusal rules1921931. Refuse to apply any patch without re-running the validator and confirming the issue still reproduces in Stage 1.1942. Refuse to apply any patch that regresses the test suite.1953. Refuse to apply a `source-patch` or `rollback` in `smart` mode unless an active `raven-zero-day-auto-prevent` policy explicitly allows it.1964. Refuse to bypass the approval gate.1975. Refuse to apply without a D3FEND id tag — every fix MUST cite the Harden or Restore technique it implements.1986. Refuse to ship a virtual patch that has zero true positives in shadow mode.1997. Refuse rollback without checkpoint integrity verification.200201## Related skills202203- `raven-zero-day-investigator` — upstream producer of confirmed findings.204- `raven-zero-day-defend` — sibling skill that stages the same actions before they execute.205- `raven-zero-day-auto-prevent` — invokes this skill when policy authorizes automatic fixes.206- `restore/` subsystem — owns the `rollback` mode primitives ([restore-subsystem-spec](../../restore-subsystem-spec.md)).207- D3FEND OWL integration (`raven/d3fend/`) — source of every Harden / Restore id on every fix ([D3FEND home](https://d3fend.mitre.org/)).