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.

Ir para a instalação

Informações da origem

Repositório
BitterSecurity/Decepticon
Última atividade na origem
17 de agosto de 2026 às 22:24
Idioma detectado do SKILL.md
inglês
Estrelas
5.522
Forks
1.048

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Exibindo SKILL.md

SKILL.md
Instruções da origem · Visualização somente leitura
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.
Ver no GitHub