浅谈漏洞修复的方法论

• 序言

• 大人，时代变了

• • 面临的场景不同

  • 技术的不同

• 应该怎么做

• • 战略

  • 组织

  • 技术

  • 策略

• 未来的发展

• 是否是创业的方向

序言

近日在看到安全牛发布的《漏洞管理的八大趋势》，其中提到了“大量数据和案例表明，虽然漏洞评估和管理工具不断丰富，但是漏洞管理重在“管理”，企业的漏洞管理或脆弱性风险相关管理依然存在很大的改进空间，例如，人才资金匮乏、缺乏对漏洞风险和受影响资产的感知能力、企业孤岛和部门战争、漏洞修复效率低下等。”这里仅仅谈谈“漏洞修复”这一个小的环节，就有很多的发散点。

是的！闭环漏洞很辛苦，够了！别再让业务修复各种安全漏洞了。

市面上乙方的各种安全加固方案都谈到windows linux系统基线的操作，redis、mysql的加固，常见web漏洞修复方法，操作手册面面俱到，但鲜有对具体的修复工作开展起来的组织和策略的探讨。经过实战的同行一定知道像fastjson这样的高危漏洞，并不是简单的响应就完事，如果安全部门仅仅给出业务“升级”两个字的修复方案，那真是“半天云里翻筋头 -- 早晚要跌跟头呢”。

看完本文希望读者们认识到，实施漏洞修复时的组织规划和策略管理工作至关重要；还需要意识到以往的修复方案经常缺乏系统性视角；最后，必须正确地认识到，在漏洞修复这个安全小闭环上，大家在各个方面还是“愣头青”，也许是一个巨大的创业空间。

大人，时代变了

面临的场景不同

做安全日常打交道的大量工作是找漏洞和修漏洞。笔者认为随着IT技术的发展，漏洞管理中涉及“漏洞修复”的这个动作可以粗略划分为四个阶段：

一、早期漏洞修复和补丁管理就是同一回事，以往的漏洞都是IT和操作系统层面。以“永恒之蓝”为例，就是IT和安全团队一起为达成安全这一目标实施打补丁。市面上已有的可靠的解决办法是完善资产管理和保障IT建设的成熟度。

二：近年来主要的问题是web类软件的安全漏洞，所以SDL和DevSecOps文化的思路强调关注尽量在软件开发生命周期早期阶段集成漏洞扫描和修复。各种工单系统，黑白盒、高危端口扫描、工单系统，都是合适的解决方案，广义上SRC（应急响应中心）和威胁情报之后安全团队的内部流转也是属于这一类。

三：ImageMagick和fastjson这里的漏洞就是关注第三方软件在应急的时候能否快速准确的修复。近日闹得沸沸扬扬的Ripple20漏洞涉及全球数亿物联网设备受到影响。由于软件供应链复杂或未被跟踪，这类小型库不仅被设备厂商直接使用，而且还被集成到其他软件套件中。这意味着许多公司甚至不知道他们正在使用漏洞代码，而且这个存在漏洞的库名甚至不会出现在它们的代码中。目前看到的有效修复办法是供应商审查和隔离方案。

四：预测未来3-5年会涉及数据安全风险的修复，如何在线上不影响业务到时候，解决一个人脸识别的数据安全漏洞？如何在满足隐私保护的前提下解决数据的加工制造过程中的安全问题？如何对IOT万物互联的亿万台设备进行统一的漏洞升级？

技术的不同

传统的安全政策仅仅为了企业合规和不出事，漏洞修复是公司内部的自闭环。现在必须要做出改变了。甲方正面临着外部要求、内部技术、社会环境、技术发展的多重变化。

• 外部方面：有出海战略的企业适应GDPR要求（字节跳动禁止中国员工访问海外产品代码库，“内外有别”保平安）；产品和用户逐步意识到将安全作为应该具备的默认属性（自主可控战略的本质是打破国外公司在互联网架构上的垄断，防范软硬件设施存在影响我国网络安全的后门和漏洞）；国家监管要求（你懂得）。

• 内部变化也随着而来，技术上的微服务、容器化，一个漏洞涉及千百万的服务器，动辄牵一发而动全身，比以往的打补丁更困难。业务的快速迭代需求的变化不再需要卡点的漏洞扫描发版流程，希望接入的基础设施默认安全，甚至自动缓解安全漏洞。

• 社会环境的变化衍生了金融安全、区块链技术、人脸识别、隐私保护的新需求，对安全和对应的修复技术标准提出了新的挑战。

虽然漏洞修复是日常工作，但是目前缺少新的方法论指导。SDL重视产品研发，DevSecOps重视安全的协同，都并没有谈论漏洞修复这件事。实战中SDL只能解决产品发布前的漏洞发现、解决、管理，DevSecOps在如今极致专业化分工的时代，还想安全做业务的“修复”的事情，难度可太大了。

历史的成功经验不能解决问题，