*本文中涉及到的相关漏洞已报送厂商并得到修复，本文仅限技术研究与讨论，严禁用于非法用途，否则产生的一切后果自行承担。

一、前言

在大企业中，安全漏洞的全生命周期管理是难以落地实施的一项工作。然而，这项工作的重要性毋庸置疑。

我们在漏洞管理上尝试过使用一些优秀的开源的漏洞管理平台，如[洞察](https://github.com/creditease-sec/insight)、[SeMF](https://gitee.com/gy071089/SecurityManageFramwork)等。当漏洞碰上企业文化，开源平台就显得有些各种水土不服。就个人看法，用开源平台管理漏洞必须二次开发，要么安全从0开始，自己开发。我们选择了后者。以下内容主要是介绍漏洞管理平台的设计思路及实现，希望能帮助到漏洞管理平台研发或者二次开发的朋友，少走弯路。

二、漏洞生命周期

漏洞的生命周期概括为3个环节，每个环节完成一定的动作后，转换到下一个环节或者结束：

漏洞发现

漏洞跟踪

漏洞暂缓

漏洞发现

漏洞发现这个环节，主要的内容是自动化导入漏洞扫描工具的结果。

导入结果时要主要几个点：

1.  选择扫描工具时，必须确定扫描工具接口是否满足漏洞扫描、漏洞结果导入的需求。

2. 自定义漏洞的5元组，如漏洞名称、漏洞目标、漏洞类型（划重点）、漏洞状态、漏洞来源等。

3. 漏洞类型的维度要根据企业内部情况而定，这个字段很可能影响后续通知谁去修复。

4. 对扫描目标要做区分，如扫描的IP是属于生产还是测试，或者是终端（可以添加相应的字段去记录，这将影响漏洞的修复及时率和重要程度）。

当完成漏洞工具扫描结果导入后，我们要制定规则，什么样的漏洞是需要我们跟进处理的，什么样的漏洞是可以忽略的。将需要跟进处理的漏洞丢入下一个环节：漏洞跟踪。

漏洞跟踪

漏洞跟踪这个环节包括：漏洞跟进、漏洞回归测试、漏洞修复。

这个环节往往是企业落地漏洞管理最难之处。影响的因素有很多，比如我们遇到的：

领导赋能不足，导致研发人员不积极影响；

企业资产信息不全，很多漏洞并不知道是谁负责。

我觉得既然要建漏洞管理平台，一定要提前思考如何推行，如何让参与人员更方便的使用，减小可预见的阻力。

最终我们借助了企业项目三剑客之Jira以及企业的CMDB，完成了漏洞跟踪这个环节的任务。

当漏洞修复，该漏洞的生命周期就结束了，当然这个美好的愿景往往不会出现。

漏洞生命周期中出现最多的是无法彻底修复，这个情况的原因会有很多很多，如供应商不见了、该系统准备下线了、该系统很重要框架不敢动、该系统过xx月会升级等等。出现这种情况该怎么办？不管了吗？于是我们设计多了一个环节漏洞暂缓，这个环节专门处理这种无法根治的情况。

漏洞暂缓

漏洞暂缓这个环节，将各种情况的漏洞及漏洞处理措施记录在案，后续若有相应漏洞的勒索或者挖矿等病毒，可“借力”推动修复。

目前对于暂缓漏洞的处理措施主要是通过安全设备做策略限制，将风险降低。对于计划升级或计划下线的漏洞除了策略限制外，添加通知提醒，若在计划时间未升级或下线，漏洞需要跟进处理最终到修复阶段。

三、过程坑点

整个漏洞管理平台搭建的过程中，有不少坑（来自于需求跟不上变化，需求不满足企业实际情况），往往牵一发而动全身，重写平台好几次。

讲讲坑点：

1. 确定应用系统或主机的安全负责人的责任范围。如负责人是负责应用系统的所有组件，还是仅仅是某个模块，是否包括中间件、数据库、操作系统等；

2. 选择适合的企业内部的工单系统，如OA、Jira或者其他。只有保证参与人员都拥有账号才能最大的减小阻力。（如果你的设计是参与人员登录你研发的漏洞平台处理漏洞，开账号是个难题，要考虑的情况会复杂非常多，如供应商、外包人员怎么处理。）

3. 建议使用ELK存储吧，可以少做很多报表的工作。

四、结束语

安全不是让业务更高效的事情，而是让业务更复杂的一个事情。

最后想说全篇没code，上个Kibana测试环境效果图。

*本文作者：bigface，本文属 FreeBuf原创奖励计划，未经许可禁止转载。