7.2 安全验证与漏洞响应：从发现到根因关闭

扫描器一夜之间报出数百条结果，但漏洞没有因此自动关闭；情报官把发现、确认、修复和复盘排成一条响应链。

安全工具产生的是候选信号，不是已修复风险。成熟 SDL 要把发现去重、确认可达性、确定所有者、修复、回归和根因改进连成一个有时限的工作流。

测试方法覆盖不同盲区

工具应由威胁模型选择。对图片解析器投入 fuzzing，通常比再加一个通用 Web scanner 更有效；对多租户 SaaS，资源级授权矩阵和手工业务测试不可替代。

CVSS 等分数描述通用技术严重度，真实优先级还应包含：

text

是否位于已部署制品？
漏洞代码是否可达、功能是否启用？
是否面向公网，攻击前置条件是什么？
是否存在在野利用或可靠 exploit？
可访问哪些数据与下游身份？
当前补偿控制和修复副作用是什么？

“依赖存在于 lockfile”不等于漏洞可利用，“扫描器没报”也不等于安全。结论要记录证据和有效期，版本或配置变化后重新评估。

一开始对所有历史问题 hard fail，团队通常只会关闭扫描。更可行的策略：

Gate 自身要快速、稳定、可解释。耗时 fuzz/DAST 可以在合并后持续运行，但高风险发布仍需等待相应结果或进入受限 rollout。

收到新漏洞或内部报告后：

text

接收与保密沟通
→ 确认受影响组件和版本
→ 查询 SBOM/资产，定位已部署实例
→ 评估可达性、利用证据和数据影响
→ 缓解/修复/轮换凭据
→ 构建并签发新制品
→ 分批部署与验证
→ 通知、披露与根因复盘

修代码却不轮换已泄露密钥，或发布补丁却不知道哪些客户仍运行旧版，都不算关闭风险。需要记录 fix version、affected ranges、部署完成率和残留例外。

对重复漏洞问：哪个设计、框架默认值、代码生成器、测试缺口或组织激励让它反复出现？

text

单点修复：给一个查询加参数化
系统修复：移除 raw-query API，提供安全数据访问层和 lint rule

复盘可以产出安全库、模板、编码约束、测试用例和培训。指标应关注 median time to remediate、逾期暴露时间、重复根因、已部署覆盖和例外债务，而不是“本月发现 300 个问题”。

下一章讨论一种不能被普通安全风险替代的损害：即使数据从未泄露，过度收集和不当使用本身也会伤害个人。