mcpField
R
regression-sweep

regression-sweep

github.com/transilienceai安全598137 次安装13 周前更新
代码仓库

关于 regression-sweep

regression-sweep 是用于定期复查已验证安全发现的技能,面向需要跟踪漏洞修复状态和严重度变化的安全团队。它重跑每项发现的 PoC、规范化比较输出并检查 CVE 评分,不会创建新发现。

主要功能

  1. 01遍历已验证发现
  2. 02限时重跑 PoC
  3. 03规范化比较运行结果
  4. 04重新查询 CVE 严重度
  5. 05输出 JSON 与 Markdown 报告

适用场景

  1. 01每周检查漏洞修复是否生效
  2. 02主要补丁部署后复查发现
  3. 03标记严重度变化或重新出现的问题
  4. 04区分已修复与暂时无法验证的发现

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/transilienceai/communitytools --skill regression-sweep

安装后在 Claude Code 中输入/regression-sweep确认已加载。

附带文件reference/diff-normalization.md

详细介绍

回归扫描

遍历整个 validated/*.json 树,重新运行每个发现项的 poc.py,将输出与记录的 poc_output.txt 进行比较,并生成每周偏差报告。已挂载到云端 Agent 任务 #4。

触发方式

每周通过 Cron 触发(默认每周一 02:00 UTC)。重大补丁部署后也可临时触发。

工作流

  1. 索引已验证的发现项。 使用 Glob 匹配 validated/*.json,并解析每个条目对应的 FINDING_DIR(位于 findings/finding-NNN/ 下)。
  2. 对每个发现项:
    • 在 60 秒超时限制内重新运行 python3 poc.py。
    • 将 stdout/stderr 捕获到 findings/finding-NNN/evidence/validation/regression-{week}-rerun.txt。
    • 使用规范化的行集比较(去除时间戳、请求 ID、临时令牌),与 findings/finding-NNN/evidence/validation/poc-rerun-output.txt(验证器最初的重新运行输出)进行差异比较。
    • 通过 tools/nvd-lookup.py 重新检查该发现项的 CVE——严重程度是否发生变化?
  3. 将每个发现项分类为以下一种状态:
    • still_valid — 重新运行结果在容差范围内与基线匹配,CVSS 未变化。
    • drift_severity — 重新运行结果匹配,但 CVSS 变化 ≥1.0(NVD 重新评分)。
    • newly_invalid — 重新运行输出不一致,漏洞利用不再触发。可能已修补。
    • newly_revalidated — 该发现项后来被标记为 REJECTED,但现在再次触发。属于回归。
    • inconclusive — 重新运行出错(网络问题、目标不可达)。下次扫描时重试。
  4. 将报告写入 artifacts/regression-{YYYYWww}.json 和便于阅读的 regression-{YYYYWww}.md。状态变更(newly_revalidated、drift_severity、newly_invalid)会在报告中以明确的标题单独列出,供分析人员审查。

输出

{OUTPUT_DIR}/
  artifacts/
    regression-{YYYYWww}.json         # machine-readable result
    regression-{YYYYWww}.md           # human summary
  findings/finding-NNN/evidence/validation/
    regression-{YYYYWww}-rerun.txt    # captured re-run output

regression-{week}.json 模式:

{
  "week": "2026W19",
  "swept_at": "2026-05-13T02:00:00Z",
  "counts": {"still_valid": 47, "drift_severity": 2, "newly_invalid": 5, "newly_revalidated": 1, "inconclusive": 3},
  "findings": [
    {"finding_id": "finding-012", "asset": "asset42", "cve": "CVE-2024-12345",
     "verdict": "newly_invalid", "reason": "PoC output diverged: response now 404",
     "baseline_cvss": 9.8, "current_cvss": 9.8}
  ]
}

规则

  1. 只做演示,不造成干扰。 重新运行 PoC 是观察,不是修改。在验证时,每个 poc.py 均已满足仅演示的约束(任务 03 的 Safety 部分);扫描只会重新执行同一脚本——按约定,该脚本会读取证明信号并退出。如果某个 PoC 在重新运行时尝试执行原本不应包含的修改操作,扫描应将该发现项中止并标记为 inconclusive,同时输出 stderr WARN——该 PoC 需要重新验证,而不是进行回归评分。
  2. 限制每个 PoC 的运行时间。 每个 poc.py 的超时时间为 60 秒。超时应标记为 inconclusive,而非 newly_invalid。这样可以避免因网络波动而错误地声称问题“已修补”。
  3. 规范化差异。 比较前去除时间戳(\d{4}-\d{2}-\d{2}T\d{2}:\d{2})、请求 ID([a-f0-9]{32,})和临时会话令牌。真实漏洞利用的输出在结构上是稳定的。
  4. 不新增发现项。 回归扫描可以更改现有发现项的状态,但不能创建新发现项。新发现的漏洞应归入验证运行任务,而非此技能。
  5. 保持幂等。 同一周的扫描重复运行时,会覆盖同一个 regression-{YYYYWww}.json。每个发现项的 regression-{week}-rerun.txt 会带有时间戳,以保留历史记录。
  6. 限制并发重新运行数量。 每次扫描最多并行重新运行 5 个 PoC,以避免对生产资产造成过多请求。

参考资料

  • reference/diff-normalization.md — 完整的规范化规则和每个发现项的输出稳定性启发式方法。

评论

支持 Markdown