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.

Zur Installation springen

Quellinformationen

Repository
BitterSecurity/Decepticon
Letzte Quellaktivität
17. August 2026 um 22:24
Erkannte Sprache von SKILL.md
Englisch
Sterne
5.565
Forks
1.053

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

SKILL.md wird angezeigt

SKILL.md
Quellanweisungen · Schreibgeschützte Vorschau
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.
Auf GitHub ansehen