序言
近日在看到安全牛发布的《漏洞管理的八大趋势》，其中提到了“大量数据和案例表明，虽然漏洞评估和管理工具不断丰富，但是漏洞管理重在“管理”，企业的漏洞管理或脆弱性风险相关管理依然存在很大的改进空间，例如，人才资金匮乏、缺乏对漏洞风险和受影响资产的感知能力、企业孤岛和部门战争、漏洞修复效率低下等。”这里仅仅谈谈“漏洞修复”这一个小的环节，就有很多的发散点。 是的！闭环漏洞很辛苦，够了！别再让业务修复各种安全漏洞了。 市面上乙方的各种安全加固方案都谈到 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 在如今极致专业化分工的时代，还想安全做业务的“修复”的事情，难度可太大了。 历史的成功经验不能解决问题，不能用过去来准备未来，要从未来的形态反推安全建设的要求。
应该怎么做
以上面的安全治理框架为例，需要优先建立组织，搭建流程，匹配管理信息，以具体的战略为例： 战略 漏洞安全治理在战略上只能是模糊的方向，动态的安全战略。不可能一步到位，需要认知迭代，不断的试错失败。以季度年为维度归零安全团队的目标，将公司内的有限资源不断转移到核心价值上。 当然战略也取决于安全责任人进入的赛道，伴随企业业务的发展，符合 CTO 的市场规划。跑在好的赛道会很快从“一个人的安全部”到搭建草台班子。有人才才能执行战略，单独的有技术并不能。好的人才，瓶颈是中层。团队不能负担战略，也是很难持续成功的。不要吐槽人手不够，每一件事总是人手不够的，人手够了，还有战略和组织能力的缺失问题，需要懂权衡的团队领导带路，安全的方法论影响力也要跟上。对外安全的修复工作也讲究“矫枉过正”，“法于上,仅得为中,取法于中,故为其下”，同业务告知安全风险，反复树立安全意识，时时讲，日日讲。 好的工程化能力就是对修复方案有审美能力，知道什么问题重要，什么方向有价值，怎么做安全是优雅的。抉择漏洞修复、缓解、转移的几个安全方案没有好坏高低之分，只要组织满意就好。但是实现的路径和方法却有好坏之分，有的方法步骤效率高，一步一个台阶，很快逼近安全建设的目标；有的团队一直在原地打转，天天在救火，天生一个补锅匠，还自叹人手不足。双方的唯一差别不在大牛的配置，而在对目标和现状的理解水平有差距。例如全公司的 IT 编程技术的现在的状态是刚起步创业公司，全部是基于开源的一个人的安全部的方案，梦想目标状态是微软，你必须构造或描述一条从开源到自研的可行线路，并且是时间最短的，成本最低的，风险最小的，这将考验制定战略的耐心。否则很多漏洞修复的具体工作的执行者会急躁、搞僵和业务的关系，问题在于主要在对自己现状不清，不知现状是什么，同时对未来的对标对象往往只有一个模糊的概念，并没有理解其内涵。 面对需要修复的漏洞太多了，制定战略的勇气在于选择不做什么。不要盲目追随新技术，不要妥协短期的利益。其中的决策读者们只可意会不可言传。 组织 做事情的组织搭配从专业上分成四大块，战略；组织和计划；运营；监控。CISO 比较偏重战略；安全总监比较偏重组织和计划；而修复数据、面向的业务催修比较偏重运营；漏洞复查时比较偏重监控。人不可能是十项全能，只能有所偏重，略懂其他的内容。一般安全团队的构成也是有巨大的问题，懂安全人多，懂业务人少，当然一般公司的要求能找到人上手干活就行，安全团队的调整难度非常大，导致的后果是现在 CISO 最累，不仅仅是要技术专家，业务专家，还得是管理专家。保证组织能力运转顺畅除了技术能力之外，更要有有持续改进的思维，辅助不断组织的治理优化。 
纵观近年安全团队的发展，尚未发现单纯因为安全入侵而垮台的公司，但是因管理混乱、向上管理不足和事多人少导致安全团队人心涣散坊间却有活生生例子。谈具体修复哪个漏洞，实际上是会有和应急响应有混淆的时候，各位读者们所处的单位各有各的业务形态，事情需要人做，组织形态千差万别，干活的总是攻防对抗出身的安全工程师。执行漏洞修复和日常安全应急的能力要求的不同在于前者要求以下五点：
- 工程系统能力
- 产品安全
- 威胁建模
- 安全编码
- 安全风险管理
对完美候选人的背景要求同时具备漏洞研究、开发能力，有产品线经历的会比较吃香。技术上千万不要为了技术创新而创新，工作是为了解决问题，只是解决问题的路上，顺带的有创新成果出现。 技术 某些涉及长期规划的漏洞修复工作必须吃透技术的红利。以往安全团队可以给出基于 waf、防火墙技术的漏洞缓解方案，在数据安全，业务安全的崛起时，没有红利了。需要注意到企业零信任的场景仍然有巨大的发挥空间。笔者注意到金融行业从业人员已经认识到继续堆安全盒子已经不可行，提前布局云上安全，k8s 等基础安全建设的团队，会享受到未来的技术红利。 威胁情报体现了另外一个技术极端，掌握超前的技术和信息太多，不但不能提高我们判断能力，反而面对一大堆互相矛盾的信息时，如果我们没有足够的专业能力和辨别技术，绝对会不知所措，迷失方向，不能判断正确与否，犹如走入大雾弥漫的迷魂阵中，彻底全靠朋友圈。也许一个高超的漏洞情报，完全不用你去修复，随着时间的推移，会被认为仅仅是 PR 而已。 缺乏思考的能力 笔者个人认为专业能力之外，有好奇心、关注创新、勇于接受新的挑战、愿意帮忙的就可以专职做 SDL。但我们技术人员普遍缺乏的就是思考，更别提什么反思了，在不经思考的前提下就采取行动、当行动出现阻碍的时候又匆忙用另一个行动去替换或掩盖，舍本逐末。经常出现的问题就是，给业务提供的修复方案不专业，说不清方案的价值。以 ghostscript 这个漏洞为例，需要思考为什么一个脚本语言的逃逸反而要在 imagemagick 侧来修复缓解，理解思考清楚为什么，才能给出稳定的解决路径，不断复盘，思考让节奏慢下来，不打扰业务。 策略 漏洞修复策略粗略可以划分为三种： 别人家产品对内的漏洞修复 这个流程一般很清晰了，一般是接受情报源，确定漏洞级别，排查涉及的资产，拉人修复发工单即可。这里不再赘述。 自己家产品对内的漏洞修复 假设我是 google，我内部的 GCP 平台出现了安全风险可以影响全部用户，需要按照以下的流程，逐步发布，且注意，并不是仅仅写个 POC，照抄网上的修复方案就能解决，安全团队必须要同业务站在一起，懂得影响上下游范围，懂得跟进发布计划，懂得闭环此类型问题。很多时候并没有合适的安全修复方案， 只能选择无奈给出临时缓解技术。 
自己家产品对外的漏洞修复 对外有客户发布的漏洞修复流程，需要处理的就更复杂了，业界对这类问题谈论的少。假设我是 google，我对外发布的 Chrome 出现了反馈的安全风险，必须有复杂的评估流程和发版方案，下面是一个评估标准，读者们自行领会。 
诚然，读者们会有一个问题，如果有切实的安全漏洞，是不是客户必须得滞后受影响，没有知情权，答案是肯定的。很无奈，虽然 fastjson 总出安全问题 fastj，按照行业标准，在没有外部公布的可利用 POC 上，fastjson 先内部全集团修复，再开源发版的做法是无可指责的。下面给出了一个评估的算法工具，有对外产品出售的公司，可以对号入座合理排期。
未来的发展
著名密码学家、图灵奖获得者 Adi Shamir 总结过三条定律：第一，绝对安全的系统不存在；第二，要想风险减半，开支就得翻倍；第三，密码往往是被绕过而不是被攻破的。而由于经历和能力限制，我们不可能对所有信息和知识都有辨别能力，这就要求我们限定自己的专业方向和特长，不能漫无目标贪大求全，要稳稳走路。漏洞是修不完的，攻击者的速度，变化越来越快。目标只能是–在合理的性价比下，完成相对安全的建设。这又回到战略上了–将公司内的有限资源不断转移到核心价值上。
是否是创业的方向
笔者个人觉得一款漏洞管理和修复工具会是好的产品。《Gartner 2020 九大安全与风险趋势》提出安全过程自动化的出现消除了重复的任务，漏洞管理属于 SOAR 的一部分，确实解决了企业大量不在面对漏洞新闻无所适从的局面，有希望解放生产力。 从具体内容上，这是提供实际的客户价值。给业务进行一次黑客渗透测试只能引发对方好奇心，客户更希望更多了解具体产品来验证产品是否有这样的能力。甲方越来越多安全专家，希望乙方不仅仅知道漏洞，并不是驻场服务，而是客观解决企业产生的风险。一款可以修复安全漏洞的产品，是安全服务真正亮肌肉的时刻。 安全的细分领域早期的进入者较容易通过引领/教育市场建立领导品牌。目前的此类的产品为空。现在的大公司虽然可以包装资产管理+漏洞威胁评分，但是没有接地气的告知漏洞对于不同的企业真正的风险是什么；漏洞修复方案都是一套模板文字，不能自动化的解决；没有联动内部的工单系统；关注安全的攻击视角，防守者的加固视角欠缺。 而且这个行业赛道足够宽，可以取代业务自己的 SDL 团队很大一部分工作。技术壁垒会是大量漏洞的自动化缓解修复。门槛是积累的运营数据。
本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。
