OWASP ZAP 生产落地案例

五、生产落地案例

说明：以下案例均为在自有系统或已获书面授权的目标上开展的工作，仅作方法参考。

案例一：团队把安全基线检查接入持续集成。背景是一个自研 Web 平台，发布频率高，人工安全测试跟不上节奏，历史上曾出现上线后才发现配置类问题的情况。做法是把 ZAP 的基线扫描作为流水线中的一个阶段，每次合并请求都执行一次，扫描目标是该请求部署出来的临时预览环境，扫描完生成 JSON 与 HTML 报告作为构建产物附在流水线上。关键配置上，用上下文严格锁定预览环境域名、排除第三方资源；用规则配置表把初期的噪声规则先忽略，避免大量误报淹没真实问题；初期设置 -I 只出报告不阻断，运行一段时间、把规则调优后再对特定高风险规则开启阻断。效果是配置类问题在合并前就能被发现，上线后的问题数量下降。踩到的坑有三个：一是初期直接对生产域名跑扫描，虽然授权包含了生产，但并发没有限制导致业务监控出现告警，后来改成只在预览环境跑并限制并发；二是前后端分离的接口无法被爬虫发现，扫描覆盖率很低，改用 api-scan 并接入 OpenAPI 定义文件后覆盖度明显提升；三是误报太多导致开发团队逐渐不看重报告，通过建立"每条规则都要有人负责确认并决定是修复还是标注忽略"的流程解决。

案例二：上线前的授权渗透测试中的自动扫描环节。背景是一个自有系统在重大版本上线前安排的授权测试，授权文件明确了范围、时间窗口与允许的扫描强度，并要求扫描在业务低峰期执行。做法是先用 ZAP 做自动化扫描获得覆盖面，再由人工针对业务逻辑做深入验证，两部分的发现合并进同一份报告。关键配置上，主动扫描使用自定义策略、并发设为保守值、时间安排在凌晨；上下文配置了完整的认证，保证扫描覆盖登录后的功能；报告导出为 HTML 与 SARIF 两种格式，前者给业务方阅读，后者接入代码扫描平台做问题跟踪。效果是自动扫描覆盖了大量常规技术问题，人工测试则集中在权限与业务流程上，整体效率比纯人工高。踩到的坑有两个：一是初期认证配置的验证策略写得过于宽松，扫描中途掉线后仍继续发请求，产生大量登录页误报，后来把验证规则收紧并加入掉线检测；二是扫描过程中触发了目标系统的入侵检测告警，虽然测试本身在授权范围内，但由于没有提前把测试出口 IP 报备给运维团队，导致对方启动了应急流程，此后把"提前报备出口 IP 与测试时间窗口"写进了标准流程。

这两个案例的核心经验是：ZAP 的价值不在于"能扫出漏洞"，而在于把安全测试变成可重复、可版本管理、可纳入流水线的常规动作。要让它真正发挥作用，配套的是三件事——清晰的授权与范围管理、经过调优的规则配置、以及人工复核与跟踪的闭环。缺了任何一件，扫描报告都只会变成没人看的噪声。