Web应用遭遇攻击时，Web应用防护与代码安全测试的协同流程，决定了团队能否从“挡住一次请求”进一步走到“修复缺陷根因”。Web应用防火墙（WAF）在运行时检查流量，代码测试则检查实现或应用行为；两者覆盖的阶段不同，单独使用都存在盲区。
防护和测试分别解决什么问题
WAF根据请求特征和规则拦截或记录可疑流量，适合应对已知攻击模式、缓解尚未修复的风险。但它看不到所有业务逻辑错误，也不能保证每种输入都被正确处理。规则配置不当，还可能误拦截正常请求。
静态应用安全测试（SAST）分析源代码或字节码，可在开发阶段发现不安全的数据流、危险函数使用等问题；动态应用安全测试（DAST）从外部向运行中的应用发送请求，更关注实际可观察的响应。软件成分分析（SCA）则用于识别依赖组件及其已知风险。它们不能相互替代：SAST通常不需要应用运行，DAST需要可访问的测试环境，而SCA重点在第三方依赖。
把告警变成可验证的修复闭环
有效的Web应用防护与代码安全测试的协同流程，不是把两类告警简单汇总，而是让线上信号帮助确定测试重点，再用修复和复测确认风险下降。
- 建立对应关系。为外部路由、参数和负责模块保留可追踪信息。WAF日志应记录时间、请求路径、规则标识和处置动作；日志中避免保存密码、会话令牌等敏感值。
- 先分类再定位。把告警按路径、参数、规则类型和业务影响整理，区分扫描噪声、误报和可能的真实攻击。结合应用访问日志与代码仓库，找到对应处理逻辑；不要仅凭单条拦截记录断定存在漏洞。
- 在测试环境复现。使用不含真实用户数据的测试账户和样例输入，检查应用是否存在相同问题。对输入验证、权限检查、输出编码等边界分别验证，避免在生产环境进行可能改变数据的攻击测试。
- 修复并运行测试。开发人员修正根因后，运行相关单元测试及SAST；若问题涉及外部可见行为，再用DAST或人工验证确认。涉及依赖风险时检查SCA结果，并确认升级不会引入兼容问题。
- 调整防护并复核。先在测试或低风险阶段核对规则效果，再按实际部署能力逐步发布。确认修复后仍保留必要的通用防护；若告警来自误报，针对具体请求条件校准，而不是整体关闭相关保护。
用同一场景看协同价值
以文件上传功能为例，测试人员可以检查服务端是否限制文件类型、验证文件内容，并确认上传文件不会被当作可执行页面直接访问。SAST可提示不安全的文件处理代码，DAST可观察应用对不同请求的响应，WAF则可能拦截部分异常请求。若只依靠WAF，应用自身的访问控制或文件存储问题仍可能存在；若只做代码扫描，也可能漏掉部署配置和实际请求路径上的问题。
因此，团队应把WAF命中趋势、代码扫描结果、修复工单和复测记录关联起来。优先处理可被外部触达、影响敏感数据或权限边界的问题；对无法立即修复的缺陷，可采用限制访问、收紧请求条件等临时措施，并设置复核期限。临时规则是风险缓解，不等于代码问题已经消失。
常见问题
WAF能否替代代码安全测试？
不能。WAF能处理部分运行时请求风险，但难以修复缺陷根因，也不能覆盖所有业务逻辑和权限问题。
SAST和DAST应该先做哪一个？
开发早期可先运行SAST，便于较早发现代码问题；应用可在测试环境访问后再做DAST。两者结合更容易覆盖不同类型的缺陷。
怎样判断误报是否可以调整规则？
先结合请求上下文、应用日志和测试复现确认。仅对已确认的误报做有限调整，并在变更后验证正常请求和攻击样例的处理结果。
归根结底，Web应用防护与代码安全测试的协同流程要贯穿发现、定位、修复、复测和规则复核。让运行时防护提供线索、让代码测试验证根因，才能避免把“请求被拦截”误当成“漏洞已解决”。
