CI/CD 门禁中误报处理的最佳实践

第一次被 DAST 门禁堵住时，我盯着那条失败记录看了半天：扫描器说某个接口存在信息泄露，点进去一看，它把一次正常的参数校验返回当成了证据。那一刻我很想直接把门禁关掉。后来没关，因为我知道，真正让我难受的不是门禁本身，而是那些“看着像漏洞、其实是误报”的条目从来没有被认真梳理过。

我现在的第一条经验是：误报要分类，不要统一处理。原文里提到两类典型来源——扫描器不理解业务逻辑，把正常的参数校验行为误判为漏洞；以及测试环境和生产环境不一致，导致结果失真。这两类问题的解法完全不同。前者需要一条条确认为噪声，后者则应该去修环境，而不是往白名单里塞。我吃过亏：把环境差异导致的失败也加进白名单，结果真漏洞来了，也被同一批过滤规则一起挡掉。

第二条是把白名单当成代码来管。每条记录关联工单号或确认记录，文件放在仓库里，走代码评审。这样做的妙处在于，下次有人想加一条“这个不算”，得先说服另一个人。而且每个迭代末我会回头看一眼，确认业务代码改了之后，那些“误报”是不是还成立。有些条目过一阵就悄悄变成真的了，这种回顾比重新全量扫描便宜得多。

第三条是阈值要分层，不要一刀切。原文提到可以按严重度设置通过标准，比如高危和严重级别卡死，中低级别允许人工确认后放行；StackHawk 的配置里有 failureThreshold 这类参数来控制允许的最大漏洞数量。我的偏向是：严重问题绝不放行，中等问题走人工确认，但确认记录要能被追溯。门禁的目的不是让流水线永远绿，而是让每一次绿都站得住。

还有一点容易被忽略：误报率跟契约质量强相关。OpenAPI 文件里参数约束写得模糊，扫描器生成的测试用例精度就下降，误报和漏报一起上来。所以我现在会把维护契约文件当成门禁的前置工作，而不是扫描器的事。

最后是回退策略。扫描器自己挂了——比如鉴权配置错了，全部请求变 401——流水线不该陪葬。我倾向于在脚本里区分“工具自身异常”和“发现漏洞”，前者以警告状态继续并通知人工介入，后者才阻断。这个区分写起来不难，但能省掉很多凌晨被叫起来的火气。

门禁真正的价值，是你还愿意相信它。误报处理，说到底就是在维护这份信任。