名词释义：

应用：是一个可以独立部署的具有特定完整功能的最小代码单，在一些公司内部也被理解成是可以拆分成的最小的一个系统。

子系统：多个应用的合集。

但我们也面临了一些困难：组件漏洞暂时无法解决二次依赖问题，会存在漏报、误报情况。例如部分开发通过修改仓库的pom文件内容修改组件版本，但并未真正发版，导致存在误报；再有就是线上代码实际使用的仓库及代码分支不一致问题（如部分使用release分支，部分使用master分支），导致检测出来的组件版本和线上并不一致，从而产生误报。另外，外购系统因无源码问题会导致漏报，部分开发测试未规范管理代码或未放入仓库也会导致漏报。

针对以上问题的优化思路：

当组件信息存在二次依赖的情况下，需要具备组件依赖信息的查询工具，需要线上环境的组件版本支撑，需要发布过程中的数据，确保组件数据是真实的而不是失效的。

通过部署HIDS厂商的产品，实现了服务器端组件采集功能。我们每天采集组件数据，每天更新验证线上还有哪些资产及哪些组件受影响。

通过获取CI过程中的成品包，进行成品包的扫描，可以获取即将发布应用的成品包依赖信息，包括二次依赖（这个工具是外购jf的xray产品，依赖分析还是很不错的，比较完整），然后通过CD工具获取该成品包部署到了哪些服务器上（公司的应用往往集群部署，并且进行灰度发布），可实现组件漏洞修复的全过程监控。

对于应用的部署都是单机单应用/单容器单应用的部署情况，通过此方案可实现组件漏洞-服务器/容器-应用-开发的关联链路，将漏洞推给责任干系人，并要求按照规定风险等级进行修复。同时我们也会将相关修复数据情况按照告警同步策略发送相关干系人及领导督促修复，并制作了各部门修复率及修复时效报表。

在此过程中我们建立了安全元数据的模型，新增了组件漏洞库数据，以及各应用在用的组件库信息，包括组件/版本/应用/服务器/组件路径或成品包路径信息。

基于以上，我们实现了如下几点：

1. 应用组件生命周期的监控，打包发布部署过程中的组件升级（低版本组件删除，高版本组件增加）；

2. 实现了二次依赖的关联分析；

3. 建立了安全元数据开源组件模型，元数据后端的组件数据T+1自动更新，开发可在修改代码后T+1天确认是否修复完成；

4. 形成报表统计给相关领导汇报，列出各个部门的修复排名（这个很重要），督促修复。

当然，上述实践过程同样也存在一些问题：

1. 部分备份的成品包会被检测到，导致误报；

2. 基于版本判断，对于一些漏洞版本有影响，但是漏洞利用条件较为苛刻，需要特定编码才会触发的漏洞，将扩大受影响资产。

对此我们的优化方案是：

1. 组件版本较低视为风险，并不一定可以利用，同时需要其他工具辅助测试验证，如各种扫描器；

2. 跟架构部门联合规范发布部署行为，禁止开发/运维将备份放到服务器上，删除备份包。

通过前2轮的技术论证可以检测出绝大多数的组件漏洞并可以进行自动验证。

实际修复情况可能和预期还有一些差距，真正落地解决问题还是有一些阻力。主要问题如下：

1. 外购系统是整体修复时效上的重灾区，真正修复花费的时间可能需两三个月甚至更多；

2. 部分二次依赖的组件问题，官方的组件包即使升级到最高版本，其依赖的组件包可能还是有漏洞的，需开发自测升级后是否有兼容性问题；

3. 部分开发团队安全意识较薄弱，认为组件安全问题影响不大，修复缓慢；

4. 少量新增的应用仍然出现了漏洞版本组件。

修复率统计：

1. 通过版本安全管控及组件黑名单的阻断机制，确保新增应用无历史组件安全问题。

2. 通过在组件仓库设置组件黑名单，如果使用低版本的组件将无法打包成功，强制要求开发升级版本。

3. 通过版本管控，如果应用版本发布过程中，仍然存在组件安全问题，将禁止发版强行阻断。

当然特定发布情况下允许放开限制，需要制定一些安全例外流程允许例外，这个时候就取决于业务优先还是安全优先了，结合实际情况进行分析。

安全检测报告中组件安全漏洞检测纬度：

另外很多公司会对一些开源的组件进行改造，以符合公司内部的场景，这种情况下，我们还需要将组件漏洞和企业二次改造的组件包进行分析验证，确认下是否受影响，使用同样的方式进行推进修复。