SAST 误报和 DAST 漏报同时存在时，安全团队该如何协调？

安全团队最难受的场面，是两套工具同时报警，而且两边给出的信息都不足以让研发信服。SAST 列出一长串代码问题，开发看一眼就说这条路外部触发不了、网关那边已经拦了，改天再说；DAST 从外面真发请求，确实拿到了异常响应，但手里只有一串请求和响应，说不清对应哪个文件、哪一行，研发得顺着路由一层层往回找。前者是“狼来了”喊太多次，后者是狼真来了却报不准位置。

这两件事的根源其实是一个：静态那边看见的是代码结构，不知道自己指出的路径能不能被外部真正走到；动态这边看见的是真实流量，却缺少代码落点。它们各自都缺对方手里那一半信息。

所以协调的方向不是让谁让着谁，而是让两边对上号。办法不复杂：让 DAST 的测试流量带上可追踪的标识，在测试环境里把这些请求走过的路由和对应的具体代码位置记录下来；等静态扫描的结果出来，再看同一条外部请求命中的代码段，是不是正好落在那条被标记为风险的位置上。对上了，这条告警就从“理论上的隐患”变成“外部确实碰到了”，修复优先级自然往前排。

不过这里有个容易被忽略的分寸：对上了号，只能说明外部输入走到了敏感位置，不等于已经证明漏洞可被利用，更替代不了人工渗透验证。同样，没对上号也不能一票否定。DAST 单方面命中，可能是第三方库、闭源组件，或者是越权、配置过宽这类静态分析本来就覆盖不到的逻辑问题；SAST 单方面命中，可能是扫描器没爬到那个入口，缺少特定认证上下文或前置数据。这两种情况都需要人工补一步，而不是直接判死。

流程上更实际的做法是分级。动态真打穿、静态又能精确指到同一处代码的，该硬拦就硬拦，发布前必须修；动态打出了问题但定位不到代码的，先软拦，限期归因，允许负责人审批后临时放行；只有静态报了但多轮动态都没触发的，记成技术债进迭代，别卡住当次交付。

说白了，安全团队要做的是让两边互相作证，不是让两边互相甩锅。对得上的先修，对不上的查清楚，剩下的排进队列。这样告警数量不会一下子变少，但每一条都能说清楚为什么排在这个位置。