前言

随着企业对网络安全的认知觉醒，对安全的投入逐步加大，日积月累下来发现的安全漏洞数量将是一个可观的数字。那么对漏洞的管理就变得越来越重要，数字化技术应用在漏洞管理上会给给安全工作带来事半功倍的效果。安全工作是围绕着发现漏洞、减少漏洞来进行的，对漏洞的精细化管理可以量化安全产出成果、进一步指导安全工作的新方向。

任何事物都有自己的周期，那么漏洞也有自己的生命周期，保证每个漏洞完整且体面的走完自己的一生是甲方企业安全工程师的责任：漏洞生成 -> 漏洞发现 -> 漏洞修复 -> 漏洞验证 -> 漏洞关闭。

下面我结合自身在应用安全角度的所见所闻，谈谈对企业内部漏洞管理的一些体验。

起步阶段

安全建设的初期，主要是以邮件、Excel、word报告的形式来进行漏洞的传递、跟踪及管理。在这种方式下，漏洞的修复情况、是否闭环因安全人员而差别很大，一个漏洞在较长排期下经常会跟丢了，且还不能及时发现，碰上安全人员的离职变动一些安全问题会被遗忘在角落，在以保证漏洞最终修复的目标上就十分耗精力，且最后展示安全成果的时候分析统计十分麻烦。

解决漏洞管理痛点

站在甲方安全工作者的角度，当我们郑重地重申漏洞生命周期管理时，除了漏洞从产生到修复的整个链路，还包括可视化的对整个链路进行监控、分析、统计，方便地完成对每一个漏洞的闭环，更附加的可以周期性的向研发线、上级领导提供不同维度的漏洞报表。（尽可能给漏洞增加各种标签，比如来源标签，如人工、IAST、SAST、DAST等等，以支持后续特殊维度的分析）

漏洞列表

漏洞规范化

该阶段还有一个特征是，漏洞相关的描述、修复建议、修复周期、分发机制，都有一个固定的模板。确保给到研发线的各种建议有统一的口径，不依赖安全工程师的能力。

漏洞报表

漏洞充分利用 — 重视复盘

在对漏洞可视化的管理一段时间之后，为进一步加强安全能力，从对保证漏洞按期修复为目标慢慢换砖换为提高漏洞的发现能力为目标。此时的关注点在对漏洞的划分上会进行转换：以漏洞发现角色为衡量标准进行划分，分为：自检漏洞和透出漏洞（指漏洞经过自身安全部门但未发现的漏洞，包括SDL流程中下一节点部门所发现、蓝军、外部白帽子提交、甚至攻击者恶意利用的等等）。对人工检测及透出漏洞进行复盘能够充分利用每一个漏洞的价值，进一步增强团队的安全能力。

对漏洞进行复盘，要从多个维度进行，对每个点都进行扩散，以达到复盘的最佳效果。安全团队内部应制定复盘的list或表格，每次复盘时，应通过最少的时间及最小的变量确保复盘的质量。此处我当前使用的范式主要包括横向、纵向及特定时间维度内漏洞特征的统计分析三个维度。

前提：首先对漏洞的技术点进行剖析，以此来确定漏洞在后续复盘中的影响面及自动化解决方向（内部仓库的代码漏洞，一定要对应到具体代码，可通过SAST增加临时扫描）。

横向复盘

横向复盘从漏洞和资产两个方向进行：

漏洞：根据漏洞技术原理是否存在其他相似漏洞、该产品是否还有其他公开漏洞。

资产：是否还有其他业务线也存在受影响情况。

以我司之前遇到的一个漏洞为例：Springboot的actuator配置导致敏感信息泄露。

在复盘该问题的时候，我曾经犯过两个错误。

（1）是在漏洞层面，除了扩展actuator的其他常见敏感文件路径（/env、/info），像Swagger文件、.DS_Store文件、.git文件等也应该一并复查一遍，防止被外部通报该同类漏洞。

（2）是在资产层面，想当然的以为对外的只有公网域名，没想到部分不合规的业务线是通过IP直接暴露出去的。

纵向复盘

纵向复盘指分析当前的安全能力链条中为什么没能检出及阻断该漏洞。针对DevSecOps的每个环发起疑问，此处可提前声明复盘的目的仅仅是查缺补漏，不是以追责为导向，旨在提高自动化检测漏洞的各项指标。

统计分析一个周期上的漏洞规律，指引下一步的应用安全工作

在一个时间周期进行复盘时，统计分析透出漏洞或依靠人工检测出来的漏洞，思考该漏洞是否更适合在哪一个自动化阶段进行解决。企业安全建设的不同阶段，漏洞的统计分析会表现出不同的特征，根据漏洞特征，提取出其中的技术要点，进而在下一个周期进行有针对性的解决。

在安全建设的初期，可以今年做SAST，明年做IAST，通过在自身企业中部署通用的、经过市场验证的安全产品来提高安全能力。

在DevSecOps中，当基本的安全能力（培训、需求评审、SCA、各种AST）都覆盖之后，此时下一阶段的安全工作怎么做，除了例行的安全告警及事件处置以外，进一步增强企业的整体安全能力将是安全团队的下一个征程。这个时候的漏洞特征通常与业务是强相关的，这时候就得因地制宜了，可以优先解决内部相关中台、通用组件、前端专项的安全隐患。

复盘的list或表格应通过在周期性的统计分析上，确认是否缺少某个维度的扩散，优化复盘流程。