安全审计Skill指南confirmed、needs_validation与rejected三判定体系为什么待验证项不许给严重级别【免费下载链接】security-audit-skillA coding-agent skill for multi-phase security audits with independently verified, machine-readable findings项目地址: https://gitcode.com/GitHub_Trending/se/security-audit-skillsecurity-audit-skill是一个让编码代理coding agent变成安全审计员的多阶段审计技能侦察、狩猎、验证、结构化输出、独立复核、中立报告六阶段一气呵成。它的精华不在找漏洞而在如何诚实地记录漏洞——每个候选问题最终只能落入confirmed、needs_validation、rejected三个判定之一而待验证项被严格禁止标注严重级别。这篇文章带你搞懂这套三判定体系的设计逻辑。一张表看懂三判定先记住结论findings.json中每条记录都有稳定fingerprint指纹同一根因在三个状态间流转时指纹不变。三个判定的必填项完全不同判定含义必带字段明确禁用字段confirmed已独立证实、有源码依据的漏洞root_cause、execution含observed_result、remediation、severity、confidenceclaimed_root_cause、blockers、validation_planneeds_validation源码有据、但被一个明确阻塞事实卡住的候选claimed_root_cause、blockers、validation_plan至少一个非空severity、execution、remediation、reasonrejected验证阶段被证伪的候选留档防止重复劳动claimed_root_cause、evidence、reasonseverity、execution、remediation、blockers契约定义在 report-schema.json 中三个分支均使用additionalProperties: false——多写一个字段都会被打回。为什么待验证项不许给严重级别这是 SKILL.md 的核心原则之一只有confirmed记录才获得严重级别。背后有三层原因。1️⃣ 严重级别是已证实后果的度量不是猜测的等级严重级别由可演示的影响demonstrated impact决定且有一条硬规则总体严重级别不能超过已证实的影响。一个尚未复现的候选它的影响只是假设——给假设打分等于给想象定价。 项目原话如果你说不出具体的损害那个严重级别就一定比你的直觉低。2️⃣needs_validation不是低置信度的确认漏洞这是最容易踩的坑。体系里反复强调needs_validation表示一个具体的、有源码依据的边界假设被某个明确事实阻塞而不是我们有点怀疑但没把握的漏洞。SKILL.md 还把它定义为绝不允许停放投机想法的停车场——没有具体边界假设的泛泛担忧连needs_validation都进不去。既然它不是打折扣的确认项自然不能继承严重级别这个字段。3️⃣ 防止误导性交付VALIDATION-AND-REPORTING.md 有一句很直白的话一个误导性的needs_validation移交会浪费所有者的时间还可能保住一个虚假前提。带严重级别的待验证项会诱导修复团队按确认漏洞排期而不带级别的needs_validation则必须附精确的阻塞事实和可执行的验证计划本地 fixture 或部署侧观测逼着读者先核实、再定级。规则不是写在文档里是写在校验器里漂亮的原则靠人自觉没用这套体系把规则硬编码进了零依赖校验器 validate-findings.cjsneeds_validation记录若出现severity字段 → 直接报错needs_validation finding must not contain severityrejected记录若出现severity/execution/remediation→ 同样拦截confirmed记录若overall_severity超过impact.score→ 报错cannot exceed demonstrated impact也就是说Phase 4 写出findings.json后必须通过 validate-findings.cjs 的结构与语义双重校验才能进入下一阶段违规的定级在机器层面过不了关。给needs_validation定严重级别甚至被列进了 SKILL.md 的十大反模式清单第 9 条。三判定在六阶段工作流中的位置侦察 → 覆盖狩猎 → 候选验证 → 结构化输出 → 独立复核 → 中立报告 ↑ 每个候选被没参与狩猎的全新验证者 以三选一判定收尾Phase 3 候选验证验证者拿到候选后的唯一产出就是{decision: confirmed|needs_validation|rejected, ...}见 VALIDATION-AND-REPORTING.md。升降级规则needs_validation只有在独立补全完整路径和有界观测结果后才能升为confirmed反之确认项若发现部署/运行事实仍未知会被降级为needs_validation。rejected的价值记录被证伪的声明及指纹未来审计运行时只有证据发生变化才会重新审视同一单元——避免每次重复报告同一个假问题。报告侧的隔离Phase 6 生成的REPORT.md会把待验证项放进独立的NEEDS VALIDATION表格不给级别、不称其为确认漏洞NEEDS-VALIDATION.md则完整保留追溯链、阻塞事实和验证计划。新手实践清单读报告先看判定再读严重级别——表格里的级别只属于confirmed其他项出现级别就是无效记录。看待验证项时问三个问题阻塞事实是什么它在源码外吗验证计划是本地可跑还是要 owner 观测部署配置别把 rejected 当噪音删掉——它是防止狼来了式重复报告的记忆库。多跑几轮README.md 提到该技能对同一仓库的多次运行是增量式的实测单轮大约只能找到重复运行总量的半数漏洞needs_validation记录在后续轮次中会被重新认领、继续推进。相关文件速查总入口与核心原则SKILL.mdPhase 3–6 验证与报告规则VALIDATION-AND-REPORTING.md三判定 JSON Schemareport-schema.json发现校验器含定级拦截逻辑validate-findings.cjs覆盖率台账校验器validate-coverage-ledger.cjs项目说明README.md总结三判定体系的安全审计设计哲学可以浓缩成一句话确定性分三档严重级别只属于第一档。confirmed用可复现的观测结果换取级别needs_validation用精确的阻塞事实换取被认真对待但不被误修rejected用留档换取团队的长期效率。当待验证项不许给严重级别这条规则被 schema 和校验器双重锁死后审计报告的每一行严重级别都变成了可以下注的承诺——这正是新手读这份findings.json时最该建立的信任基础。【免费下载链接】security-audit-skillA coding-agent skill for multi-phase security audits with independently verified, machine-readable findings项目地址: https://gitcode.com/GitHub_Trending/se/security-audit-skill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考