GGI Activity: 管理软件漏洞

Table of contents

管理软件漏洞

活动编号：GGI-A-22。

描述

一段代码的安全性取决于其最不安全的那部分。最近的案例（如heartbleed2、equifax3等）已经证明了检查组织机构非直接开发的那部分代码的漏洞的重要性。其暴露的后果包括数据泄露 （会带来巨大的声誉受损的负面影响）、勒索软件攻击和业务停服威胁。

众所周知，开源软件比专有软件具有更好的漏洞管理，主要是因为：

• 更多双眼睛时刻盯着发现并解决开放代码及其流程中的问题。
• 开源项目可以更快地修复漏洞并发布补丁和新版本。

例如，一份来自白宫的关于专有软件研究报告指出，在开源组件中发现的95%的漏洞在其进行分析的同时就已经发布了修复程序。因此，真正的问题是要如何更好地从代码库和依赖性上管理漏洞，而不是讨论它们是开源的还是闭源的。

为了降低这些风险，必须制定一个软件资产评估计划并定期执行漏洞检查流程。实施工具应向受影响的团队发出警报、管理已知漏洞并防止来自相关依赖软件的威胁。

可行性评估

任何使用软件的公司都必须重视以下方面的漏洞：

• 基础设施类（例如云基础设施、网络基础设施、数据存储等），
• 业务应用类（HR、CRM 工具、组织机构内部与客户相关的数据管理）、
• 内部代码类：如公司网站、内部开发项目等、
• 以及所有直接和间接的软件和服务依赖的组件。

在问题出现之前，漏洞管理的投资回报率（ROI）鲜为人知。人们必须考虑到重大数据泄露或服务停摆的后果，并以此来预估漏洞管理的真实成本。

同样，必须不惜一切代价避免公司内部出现隐瞒安全相关问题和保密的文化。相反，有关漏洞状态的信息必须被共享和讨论，直到从开发人员到高级管理者中找到最合适的人并得到最佳应对方案。

通过谨慎管理软件漏洞来预防网络攻击的好处是多方面的：

• 避免声誉受损风险；
• 避免漏洞攻击带来损失（DDoS公司、勒索软件、被攻击后重建信息系统所需的时间）；
• 遵守数据保护法规。

开源软件的漏洞管理只是广义网络安全流程中的一部分，该流程旨在解决组织机构内部的系统和服务的安全问题。

进度评估

应该有专职人员或专职团队来进行漏洞监测和开发人员可依赖的易用流程。漏洞评估是持续集成开发过程的标准环节，人们可以在专用面板中监测当前的风险状态。

以下验证点将呈现此项工作的进展：

• 此项工作应覆盖所有内部软件和服务的已知漏洞都被评估和监控。
• 此项工作应覆盖软件开发流程中的专用工具使用和专业流程的实施，以防止在日常开发过程中的引入问题。
• 由专人或团队负责评估CVE漏洞的爆发风险。
• 由专人或团队负责将CVE漏洞信息发送给相关人员（系统运营、开发运营、开发人员等）。

工具

• GitHub 工具
  • GitHub 提供了指南和工具来保护平台上托管的代码。有关更多信息，请参阅 GitHub 文档。
  • GitHub 提供了 Dependabot 来自动识别依赖项中的漏洞。
• Eclipse Steady 是一款免费的开源工具，它能够分析Java和Python项目中的漏洞并帮助开发人员降低漏洞风险。
• OWASP dependency-check：是一款开源的漏洞扫描工具。
• OSS Review Toolkit：是一款开源编排器，能够从配置好的漏洞数据服务中收集所使用的依赖组件的安全建议。

资源

• CVE 的 MITRE 漏洞数据库。另请参阅 NVD 的 NIST 安全数据库 以及 CVE 详细信息 等卫星资源。
• 另请检查 Google 的这项新举措：开源漏洞。
• OWASP 工作组在其网站上发布了来自商业和开源领域的漏洞扫描程序列表。
• J. Williams and A. Dabirsiaghi. 《不安全图书馆的不幸现实》，2012 年。
• 检测、评估和缓解开源依赖项中的漏洞，Serena Elisa Ponta、Henrik Plate 和 Antonino Sabetta，经验主义的软件工程第 25 卷，第 3175–3215 页（2020 年）。
• 一个手搓的开源软件漏洞修复数据集，Serena E. Ponta、Henrik Plate、Antonino Sabetta、Michele Bezzi、Cédric Dangremont。还有一个实现上述数据集的正在开发的工具包。

下一步工作建议

• GGI-A-24 - 管理关键指标 让已发现的漏洞可见。这将有助于人们清楚他们的软件有多么安全或多不安全，并证实选择适当依赖组件的重要性。

[^heartbleed]：https://www.wikipedia.org/wiki/Heartbleed