根据以上的思路，每种工具的插件，其切换，扫描出的漏洞等级，去重规则，是否自动推入

漏洞审核，是否自动推入开发等，都可以在前端页面进行配置管理，这样操作时，可以根据实

际数据情况进行相应的操作(比如，某个检测插件的准确率达到一定高度，就启动自动推入，

某次准确率又突然下降，就暂时关闭自动推入)，这样在处理扫描结果时就比较灵活。

 

 

组件安全性，在某些web漏洞之外，通用组件已经成为外界轻易突破安全防线的一道屏障，而

目前大多数公司都将面对通用组件的安全问题。对部件漏洞，适用范围广，造成危害大，受到

影响的资产数以千计，修复起来可不容易。在传统的casebycase中，通过离线整理数据跟踪

修复效果不大。第三个问题是在组件安全这一方向上，如何做好问题修复和控制。

 

 

通过讨论和技术验证，证实该方案是可行的，之后，我们按照文章“通用组件安全治理三步实

践”中提出的思路，对开放源码组件模块进行了研究开发。与应用漏洞不同的组件漏洞处理方

法是，我们将常见的组件漏洞单独放在这个模块中进行后续处理，而不需要开发人员在系统

中操作任何按钮，只需按照修复程序完成修复，然后进入平台查看受影响的资产是否仍然存在。

 

 

除了存在解决存量问题的过程和方案之外，我们还需要考虑如何在研发过程中检查组件安全问

题，以控制增量组件安全问题。

 

1.通过版本发布期间的控制，如果应用程序版本发布期间组件安全问题依然存在，则禁止发版

强制阻塞，以确保新的应用程序不会出现历史组件安全问题.

 

通过在组件仓库中设置组件黑名单，如果使用低版本的组件将不能成功打包，则必须开发升级

版本。通过对接需求和研发管理平台，Sop安全操作平台在需求分解到开发任务后的评审环节

中，将安全需求作为评审内容的一部分，指导开发人员根据自身的安全需求进行评审/执行安

全设计。以安全性审核和安全性设计数据为基础，再结合各维度安全性审核(包括人工安全性

审核、应用层安全性审核、组件安全性审核、源码安全性审核)的检验结果，便可汇集研发流

程中的安全性审核数据，形成全面统一的结论，并在系统层面实现“控制增量问题”。通过对各

业务系统的版本发布流程和内部研发流程的调查研究，制定了版本安全管控方案。对安全检

测进行了多维划分(如应用层安全风险、源代码安全风险、组件安全风险)，最后得出了多维综

合结论。在试验完成环节，根据既定规则，给出安全试验结论和报告。如果结论通过并且报

告已经正常归档，那么就可以进行版本转换，进行代码冻结，从而完成版本的发布，否则就

会阻塞。