上线了请求过滤、访问控制或流量限制，不代表代码已经通过安全验证。Web应用防护与代码安全测试的协同流程，关键是让运行时防护、代码检查和修复回归各自发挥作用，再用可复现的结果确认风险是否真正关闭。
以下五个误区容易让团队出现“防护已做、问题仍在”的落差。判断时应关注代码行为、部署配置和测试证据，而不是只看某项措施是否上线。
误区一：把防护规则当成代码已安全
网关或应用层规则可以拦截部分异常请求，但未必能修复程序本身的缺陷。例如，文件导入功能若只依赖请求特征过滤，代码仍应校验文件类型、大小和保存位置，避免把用户输入直接拼进文件路径。前者是运行时缓解，后者才是代码层修复。
处理步骤：先记录防护规则覆盖的入口和限制，再检查对应代码是否有明确校验；使用正常、边界和异常输入分别验证；若规则只能挡住部分请求，就把代码修复列为待办，而不是关闭问题。
误区二：测试范围和真实功能对不上
开发团队可能按代码模块安排检查，运维团队则按域名、路由和部署单元配置防护。如果新接口没有进入测试清单，或者测试使用的版本与上线版本不同，结果就不完整。OWASP ASVS 可作为应用安全要求的参考框架，但仍需结合具体功能确定验证项。
建立一份共同清单，至少包含功能入口、调用身份、输入来源、敏感操作、代码版本和防护位置。需求变更或新增接口时，由负责人同步更新清单，并标明尚未验证的部分。
误区三：各自报问题，没有共同分级
扫描结果、代码审查意见和运行日志可能描述同一风险，也可能严重程度不同。只按工具的等级排序，容易让团队把精力放在高分但低影响的问题上，漏掉实际可触达的关键路径。
建议按可利用条件、影响范围、现有缓解措施和修复成本共同分级。威胁建模可帮助梳理重要数据、信任边界和滥用路径；对于影响较大的疑点，再安排有授权、限定范围的渗透测试。分级结论应写明责任人、期限和临时措施。
误区四：漏洞修复后没有安全回归
修复代码不等于验证结束。改动可能影响相邻功能，原有缺陷也可能因其他入口重新出现。安全回归应同时检查修复点和关键业务路径：确认旧的异常输入被正确处理，再确认正常用户仍能完成预期操作。
可执行步骤如下：
- 把缺陷的触发条件和预期安全行为写成测试用例。
- 在与目标版本一致的测试环境中复现问题，并保留请求、响应或日志等证据。
- 合并修复后重复原用例，同时检查相关入口和正常流程。
- 记录结果、代码版本及未覆盖条件；未验证部分不要标记为已关闭。
误区五：上线后缺少变更复核
规则、路由和权限配置会随版本发布而变化。测试通过的代码若部署时启用了不同配置，保护效果可能不一致。反过来，过严的规则也可能影响正常请求，因此上线前后都要核对实际生效的配置与预期。
为每次变更保留配置差异、验证结果和回退条件；上线后观察与变更相关的错误和拦截记录。发现误拦截时，先确认受影响的入口和请求特征，再做有限范围调整，并补充测试，避免只靠放宽规则解决问题。
把协作流程落到证据上
一套可执行的Web应用防护与代码安全测试的协同流程，可以按“列清单—定责任—验证—修复—回归—复核配置”推进。每个风险都应有明确的代码或配置责任人、验证方法和关闭证据。防护负责降低可利用机会，测试负责发现和证明缺陷，二者协同才有助于持续降低风险。
常见问题
防护规则已经拦截问题，还需要修代码吗？
若根因在代码中，通常仍应评估并修复。规则可以作为临时缓解，但应记录覆盖范围和残余风险。
代码安全测试多久做一次？
没有适用于所有团队的固定频率。至少应在重要代码变更、关键功能新增和高风险修复后验证；具体安排取决于发布节奏与风险。
怎样证明问题已关闭？
保留缺陷条件、修复版本、复测步骤和结果；若依赖配置缓解，还要记录生效范围及复核方式。
