技术 · 深入
审计报告里，没验过的别写成定论
覆盖先枚举，结论分两栏
这是把安全审计做成侦察→覆盖检查→独立验证→结构化报告四段的工作流，解决「查了一遍，说不清哪里没查、也说不清哪条真验过」的问题。关键在第二步和第四步：先枚举应该查什么，逐项标已查与未查；报告里把结论分成「已确认」和「待验证」两栏，验证条件不足的绝不写成定论。
方法 · 一图看懂
1
侦察 — 先摸清资产与入口（仓库、依赖、配置、暴露面、凭证），产出本次的待查清单。
2
覆盖检查 — 对照一份固定的类目表逐项打状态：已查、未查、不适用；未查的写清原因。
3
独立验证 — 每条发现单独复现一次，不靠阅读推断；条件不足的标为待验证。
4
结构化报告 — 两栏落纸：已确认（附复现步骤与影响面）、待验证（附缺什么条件）。
5
修复后复跑 — 按同一张覆盖表复跑，只有复现失败才把条目从「已确认」移出。
档位差异：结论可读 vs 结论可追
初档只做「查出问题、写成报告」，报告里所有条目看上去一样可信。深档多两层：一层是覆盖检查——先声明本次应该查哪些类目，再逐项标状态，让「没查」变成可见项，而不是默认安全；另一层是结论分栏——验证条件不足的发现必须留在待验证栏，并写清缺什么条件才能确认。这两层不做，报告越漂亮越危险：读者会把「没提」当成「没问题」。
覆盖表的三种状态怎么写
每个类目只有三种状态，而且必须显式写下：已查（附证据或复现步骤）、未查（附原因：无权限、无环境、超范围）、不适用（附理由）。四段流程的产出物因此不是一份报告，而是「一张覆盖表 + 一份分栏报告」——覆盖表说明边界，报告说明结论。Cloudflare 的 security-audit-skill 把这套写进了技能本身：7 天新增 15,072 星、累计 47,178 星，说明团队真正缺的不是扫描器，是说得清边界的覆盖表。
原理 · 为什么有效
为什么有效：审计真正的风险不在「漏了一个漏洞」，而在「漏了却不知道漏了」。报告只写发现时，读者无法区分「查过没问题」和「根本没查」——这两者在文本上长得一模一样。把应查类目先枚举成清单，等于给这次审计画了一条可被核对的边界线；把结论拆成已确认与待验证两栏，等于给每条发现标注了证据强度。两者叠加，报告就从「一份结论」变成了「一份能被外部复核的过程记录」，复跑时也能按同一张表对齐。
适用场景
适用：需要向别人交代「查过什么、结论有多硬」的场合——上线前安全检查、第三方交付验收、合规自查、事故复盘。不适用：探索性的一次性排查（还没有类目表可依），或者时间紧到连覆盖表都列不完的应急处理——那种情况先处理问题，事后再补表。同样不适用于把「待验证」当挡箭牌：一直留在待验证栏、又不给补齐条件，等于把风险一直放着不处理。
自测 · 5 问
这份报告里，能不能一眼看出哪些类目根本没查？
每条结论后面，有没有复现步骤或证据？
标成「待验证」的条目，写清缺什么条件才能确认了吗？
修复之后，我是不是按同一张覆盖表复跑的？
如果别人拿这份报告去对外交代，会不会把「没提」误读成「没问题」？
怎么上手 · 验证步骤
先写一张覆盖表：左边列本次应查的类目（依赖、配置、凭证、暴露面、日志等），右边三列打状态。然后按类目逐项查，查完的写证据，没查的写原因。每条发现单独复现一次：能复现的进「已确认」，复现不了但看着可疑的进「待验证」并写清缺什么条件。最后两份东西一起交：覆盖表 + 分栏报告。修复后按原表复跑一轮，只有复现失败的才从已确认移出。
把报告交给没参与的人看：如果他能指出「这几类你没查」而你却没在表里写，说明覆盖表没做；如果他以为所有条目同等可信，说明分栏没做到。