漏洞证据链的最小记录集

漏洞证据链不是把验证日志全部保存下来，而是留下足以让另一位复核者判断“验证了什么、在什么条件下验证、观察到了什么”的最小记录集。记录过少，结论无法复核；记录过多，则可能把仓库中的凭据和敏感数据一并带入报告。

一条可复核记录首先要固定验证对象与前提：已获授权的目标代码、被质疑的文件或函数、相关依赖版本与必要配置，以及本次要检验的漏洞描述。随后记录实际执行的复现步骤，包括使用了哪个入口、提交了什么类型的输入、预期出现什么异常。这里的关键是区分“计划执行”与“确实执行”：如果目标服务没有正常启动，后续的未复现不能用来判断漏洞是否存在。

结果部分应保留能支撑判断的原始观察，例如验证流日志中的关键片段、实际请求与目标响应，以及是否触达所述代码路径。结论必须与证据强度相称：服务可达不能证明漏洞成立，代码可达也不等于产生实际危害；未复现只能说明本次条件下没有观察到预期行为，不能直接写成误报。若只完成了部分验证，应明确缺失的是触发前提，还是实际影响的证据。

记录还需要交代验证环境及其限制，尤其是隔离靶场的网络访问范围、可能影响结果的配置差异。报告中只保留复核所必需的材料，对凭据和敏感内容做遮蔽，并在验证结束后清理临时文件与不应长期留存的日志。最小记录集的标准不是篇幅，而是复核者无需依赖结论标签，就能看清证据如何支持、又如何限制这项判断。