DevSecOps 平台怎么选？先看漏洞发现后谁来修

扫描报告一出来，安全团队把高危漏洞清单发到群里，开发问“这条在哪个文件、哪个版本”，运维问“这次发版要不要拦”，三天后清单还在，漏洞编号已经换了一版。很多团队并不缺扫描器，缺的是一条能落到具体人、具体提交和具体流水线的修复路径。

所以选 DevSecOps 平台，先别数它接了多少扫描器，先看漏洞被发现后，平台能不能回答三件事：谁负责修、在哪儿修、修完谁来验证。GitFox 把代码托管、评审、CI/CD、代码安全扫描、制品库和发布放在同一底座上，下面就用这条链路作参照，拆解一条可验证的修复闭环。

漏洞发现后，DevSecOps 平台的差距如何看？

扫描器负责“发现问题”，平台负责“把问题送到能解决它的人手里，并留下解决证据”。发现能力可以采购，修复闭环必须由平台承接。

一条完整的修复链至少包含五步：发现、分派、修复、复扫、关闭。任何一步落在平台外，都会变成人工接力：安全导表格、开发查仓库、运维翻流水线，最后靠会议确认有没有改完。

常见断点有三类：

• 责任断点：漏洞、工单、代码分属三套系统，各有人管，却没人对“关闭”负责。

• 上下文断点：开发只看到规则编号，看不到文件、行号和提交，复现成本高。

• 验证断点：代码合并、工单关闭，却没有复扫记录；下次发版同样问题再出现。

中国信通院《研发运营（DevOps）平台和工具能力分级要求》把项目管理、应用开发、测试、运维/运营放进同一评估框架，并兼顾平台安全能力。这个口径说明：安全不是平台外面加一个扫描器，而是贯穿交付链路的能力。

DevSecOps 平台功能有哪些？

很多选型从功能清单开始：支持多少种语言、接多少扫描器、有多少条规则。这些要看，但更该先问清楚：漏洞被发现后，谁来修？

分工定下来，平台的价值就很具体：把漏洞按代码归属分给人，把工单和需求、缺陷、提交关联起来。没有 owner 的漏洞，不应进入“已确认”；没有复扫证据的工单，不应关闭。

如果团队用禅道管需求和缺陷，还要看平台能不能把缺陷、提交和发布串起来。平台的代码追溯能力围绕这条链路设计；具体字段以所选版本和官网说明为准。

选 DevSecOps 平台，盯住四条修复闭环证据

演示环境里，几乎每个平台都能扫出漏洞。真正拉开差距的，是扫描后能不能留下四类证据。

第一，定位到代码和提交。 漏洞要落到文件、行号、提交或依赖路径，最好直接关联合并请求。只告诉开发“某个服务有高危漏洞”，修复仍要靠人找。平台不必替代所有专用扫描器，关键是接得住结果；代码安全扫描与独立工具如何配合，可以单独验证。

第二，自动建单并分派责任人。 工单要有负责人、风险等级、修复期限和复现信息，还要能关联需求或缺陷。靠人工把结果粘进表格，规模一大就失控。

第三，分级质量门禁。 不是所有漏洞都值得阻断发布：新增高危阻断合并，存量按期限排期，例外必须审批并设置到期时间。质量门禁要能区分“新问题”和“老问题”，否则开发很快会绕过。

第四，复扫与审计证据。 修复提交后自动复扫，记录通过或失败；关闭工单时能看到谁修的、改了什么、何时复扫通过。DORA 用失败部署恢复时间衡量从失败到恢复的速度；修复闭环同样需要可度量的恢复证据。

选型不要只看“能扫什么”，要看“扫完能留下什么证据”。只能生成报告、不能变成带负责人和复扫记录的工作项，它更像一个扫描结果展示页。

DevSecOps 平台怎么选？

不要用厂商演示判断修复闭环。选一个真实服务、一个真实代码库，跑两到四周 PoC，才能看到平台在真实协作里的表现。

1. 选样本：挑一个 5～15 人小组和一个正在迭代的服务，记录漏洞积压、平均修复时长和超期数量。

2. 验分派：投入代码漏洞、依赖漏洞、测试用泄露凭据三类问题，看平台能否在十分钟内找到代码负责人并生成工单。

3. 验修复：让开发在合并请求里修复，观察流水线是否只扫描变更范围、是否触发复扫、门禁是否按风险等级阻断。扫描速度与门禁平衡是这一步的重点。

4. 验关闭：复扫通过才能关闭工单；失败要回到同一个负责人，而不是重新开一张没人认领的工单。

5. 验数据：记录确认耗时、修复耗时、复扫通过率、误报处理耗时和超期未修数，与 PoC 前基线对比。

PoC 通过标准必须提前写死，不能看完演示再讨论。比如：高危漏洞从发现到分派不超过十分钟，修复后自动复扫率不低于九成，关闭工单必须带复扫记录。达不到，就说明修复链还有人工断点。

一体化平台的成本与适用边界

选型最后会落到成本和边界。只比软件授权费，容易得出错误结论；至少要把实施、迁移、日常运维、培训和退出成本一起算进去。

一体化平台的优势是减少系统交接：代码、扫描、工单、流水线、制品和发布在同一套权限与审计体系里，修复记录更容易串起来。代价是团队要接受统一工作方式，已有深度定制流程需要适配。保留多套专用工具也能满足特定场景，但接口开发、数据对账和故障定位成本要计入 TCO。

GitFox 是禅道软件完全自主研发的一体化 DevOps 底层引擎，也是禅道 DevOps 解决方案内置的核心组件，底层不依赖海外开源内核；代码托管、评审、CI/CD、代码安全扫描、制品库和发布在同一底座上，并与禅道项目管理形成分工——禅道承接需求、任务和缺陷，GitFox 承接代码到发布的执行链路。对 50～300 人的研发中心、需要私有化或信创部署、希望减少多套工具拼接的团队，这种结构更容易把修复责任落到具体提交和流水线上；如果团队已有多套深度定制的专用安全工具，则应先验证接口、数据回传和退出成本，再决定是否替换。

一体化不是天然更便宜，只有把交接、审计和运维成本算进去，TCO 才有可比性。

关于 DevSecOps 平台选型的常见问题

DevSecOps 平台和代码安全扫描工具是什么关系？

扫描工具负责发现，平台负责把发现变成可跟踪、可修复、可验证的工作项。两者可以同属一套产品，也可以分开部署；选型要看结果能不能回传、责任能不能落地，而不是谁替代谁。

漏洞该由安全团队修，还是开发团队修？

代码缺陷通常由写代码的开发修，依赖和运行时问题由服务负责人联合运维处理；安全团队负责规则、优先级和例外审批。平台要把分工写进流程，而不是默认所有漏洞都堆给安全团队。

扫描误报太多，换平台能解决吗？

平台可以通过去重、上下文补全、风险排序和例外流程降低误报消耗，但规则调优和基线维护仍然要做。平台很难靠一次配置消除全部误报，选型要看误报处理和规则运营是否可持续。

怎么判断修复闭环真的生效？

看五个信号：漏洞有没有明确 owner、修复后有没有自动复扫、关闭工单有没有证据、超期数量是否下降、同类问题是否重复出现。指标连续两三个迭代改善，比一次演示更有说服力。

选型的顺序可以反过来：先画出漏洞从发现到关闭的路径，再定每个环节的责任人，最后看平台功能能不能把这条路固化下来。

一个 DevSecOps 平台如果能让你在十分钟内回答“这个漏洞谁在修、改到哪、复扫过没有”，它才真正参与了交付，而不只是又生成了一份报告。正在选型的团队，不妨用一个真实服务跑两周 PoC，把确认、修复、复扫、关闭四个时间点记录下来。需要评估的团队，可以先在官网了解部署方式和版本差异，再约一次针对真实代码库的 PoC。