Skip to main content

patch-diff-research

Authorized patch-diff workflow for deriving and validating vulnerability variants from a known vulnerable-to-fixed source change.

Source facts

Repository
BitterSecurity/Decepticon
Last source activity
August 17, 2026 at 22:24
Detected SKILL.md language
English
Stars
6,511
Forks
1,247

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
patch-diff-research
description
Authorized patch-diff workflow for deriving and validating vulnerability variants from a known vulnerable-to-fixed source change.
allowed-tools
Read Write Bash
metadata
{"subdomain":"analyst","when_to_use":"patch diff n-day variant analysis vulnerable fixed commit regression source change known advisory","upstream_ref":"Decepticon analyst lane: authorized patch-diff research"}
# Patch-Diff Research Use this workflow only on source, commits, and test targets the engagement is authorized to inspect. A patch is evidence of a changed security boundary, not proof that every neighboring line is exploitable. ## Inputs - Pinned vulnerable and fixed revisions from the same repository. - Build instructions and a local or intentionally vulnerable test target. - The advisory, failing test, or exact behavior corrected by the patch. ## Loop 1. **Pin both sides.** Record repository URL, vulnerable commit, fixed commit, clean working-tree state, dependency lockfile hashes, and build commands. 2. **Explain the security delta.** Identify the source, guard, sink, trust boundary, and behavior changed by the patch. Ignore formatting-only hunks. 3. **Build a differential test.** The positive case must reproduce on the vulnerable revision; the negative control is the exact same case on the fixed revision. Record both raw outputs. 4. **Search for siblings.** Search only for the abstract cause—not the exact line text. For every hit, confirm framework, data flow, authorization state, and reachability before treating it as a candidate. 5. **Validate candidates independently.** Each candidate gets its own minimal positive and baseline command through ``validate_workspace_finding``. Do not inherit validation from the original CVE. 6. **Report the boundary.** Record rejected siblings and why they differ. Group only independently confirmed findings under the common root cause. ## Required artifacts ``` research/patch-diff/<advisory>/ revisions.json # commits and dependency hashes security-delta.md # source / guard / sink explanation original-positive.txt # vulnerable revision output original-fixed-control.txt # fixed revision output variants/<candidate>/positive.txt variants/<candidate>/baseline.txt variants/<candidate>/verification.json ``` A variant is promotable only when its own verification artifact validates and the original fixed-side control demonstrates the intended remediation boundary.
View on GitHub