介绍
开源软件 - 其代码可供公众查阅，通常可免费使用 - 非常棒。作为消费者，它使我们无需重新发明轮子，让我们专注于我们的核心功能并大幅提高我们的生产力。作为作者，它让我们分享我们的工作，获得社区的爱，建立声誉，并且有时对软件的工作方式产生实际影响。
因为它太神奇了，开源使用率飙升。实际上，从妈妈和流行商店到银行和政府的每个组织都依靠开源来运营他们的技术堆栈 - 以及他们的业务。工具和最佳实践已经发展到使这种消费变得越来越容易，通过单个代码或终端线来降低大量功能。
不幸的是，使用开源也存在很大的风险。我们依靠这些由陌生人编写的众包代码来运行任务关键型系统。通常情况下，我们很少或根本没有仔细检查，几乎没有意识到我们正在使用什么，完全不知道它的血统。
您使用的每个库都存在多个潜在的陷阱。该库是否存在攻击者可以利用的软件漏洞？它是否使用病毒许可证使我们的知识产权面临风险？恶意贡献者是否在良好的代码中隐藏了恶意软件？
与商业软件不同，免费开源软件（FOSS）很少提供任何担保或保证。作为开源软件的消费者，您有责任了解并减轻这些风险。
2017年9月宣布的Equifax数据泄露事件使这一风险完全成为现实。由于开源Apache Struts库存在严重漏洞，该漏洞暴露了1.43亿人的极端个人信息。 2017年3月披露了此漏洞，只有在发现漏洞后，有问题的Equifax系统才会在7月底之前修补。 Equifax完全有能力更早识别和解决这个问题，防止大规模泄漏，许多人声称不这样做是公司的疏忽。 Equifax漏洞肯定会成为保护数据和负责任地使用开源的重要性的典型代表。
书籍目的和目标受众
本书将帮助您解决易受攻击的开源库的风险，这是绊倒Equifax的原因。正如我将在本书中讨论的那样，这些易受攻击的依赖项最有可能被攻击者利用，并且您需要良好的实践和工具来大规模保护您的应用程序。
由于在开发（包括DevOps）和应用程序安全性之间共享应用程序及其库的安全责任，因此本书面向这两个部门的架构师和从业者。
考虑到这一点，接下来的几节将进一步解释本书的内容和范围。其余主题有望在未来更广泛的书中介绍。
工具与库
开源项目有多种形式和形式。对它们进行分类的一种有些过于简单的方法是将它们分成工具和库。
工具是独立的实体，无需编写自己的应用程序即可使用或运行。工具可以大小，从小型Linux实用程序（如cat和cURL）到完整和复杂的平台（如CloudFoundry或Hadoop）。
库具有旨在在应用程序内部使用的功能。示例包括Node.js的Express Web服务器，Java的OkHttp HTTP客户端或本机OpenSSL TLS库。与项目一样，库的大小，复杂性和广度也有很大差异。
本书专注于库。虽然一些开源项目可以作为工具和库使用，但本书仅考虑库方面。
应用程序与操作系统依赖关系
开源软件（OSS）项目可以直接从他们的网站或GitHub存储库下载，但主要通过注册表来使用，注册表包含打包和版本化的项目快照。
一类注册表包含操作系统依赖性。例如，Debian和Ubuntu系统使用apt注册表来下载实用程序，Fedora和RedHat用户利用yum，许多Mac用户使用HomeBrew在他们的机器上安装工具。这些通常被称为服务器依赖项，更新它们通常称为“修补服务器”。
另一种类型的注册表包含主要用于应用程序的软件库。这些注册表主要是语言特定的 - 例如，pip包含Python库，npm包含Node.js和前端JavaScript代码，Maven服务于Java和相邻社区。
保护服务器依赖性主要归结为通过经常运行诸如apt-get upgrade之类的命令来更新依赖关系。虽然现实问题从未如此简单，但保护服务器依赖性比保护应用程序依赖性要好得多。因此，虽然它的大部分逻辑适用于所有类型的库，但本书仅专注于应用程序依赖性。
要了解有关保护服务器（包括其依赖关系）的更多信息，请查看Lee Brotherston和Amanda Berlin的防御安全手册（O'Reilly，2017）。
已知的漏洞与其他风险
消费开源库存在多种类型的风险，包括对库许可的法律问题，陈旧或管理不善的项目中的可靠性问题，以及具有恶意或妥协贡献者的库。
但是，在我看来，最直接的安全风险在于开源库中的已知漏洞。正如我将在下一章解释的那样，这些已知的漏洞是攻击者利用的最简单的途径，并且大多数组织都很难理解和处理。
本书侧重于不断发现，修复和预防开源库中的已知漏洞。其目的是帮助您了解这种风险以及您需要采取的措施。
比较工具
有助于解决易受攻击库的工具通常称为软件组合分析（SCA）工具。这个首字母缩略词并不代表整个风险范围（特别是，它没有捕获分析后的补救措施），但由于这是分析师使用的术语，我将在本书中使用它。
由于工具环境正在迅速发展，我将主要避免引用特定工具的功能，除非工具与相关功能紧密相关。在命名工具时，我将专注于免费或免费增值工具，允许您在使用前对其进行审核。第6章从更高层次的角度对评估工具进行了评估，从而在选择解决方案时提供了更加明确的视角，了解哪些方面最重要。
书大纲
既然您已经理解了本书的主题，那么让我们快速回顾一下这个流程：
- 开源软件包中的已知漏洞定义并讨论了已知的漏洞以及为什么跟上它们的重要性。
- 第2章到第5章解释了解决开源库中已知漏洞的四个逻辑步骤：查找漏洞，修复漏洞，防止添加新的易受攻击的库，以及响应新披露的漏洞。
- 如前所述，第6章从解释SCA工具之间的差异，突出我认为最重要的属性重点。
- 最后，第7章总结了我们所学到的内容，并简要介绍了未详细介绍的主题。
本书假定您已熟悉使用开源注册表（如npm，Maven或RubyGems）的基础知识。如果你不是，那么在开始阅读本书之前，有必要阅读一两个这样的生态系统，以充分利用它。
开源软件包中的已知漏洞
“已知漏洞”听起来像是一个非常不言自明的术语。顾名思义，这是一个公开报道的安全漏洞。然而，由于这些缺陷的数量和重要性，围绕这种风险形成了一个完整的生态系统，包括广泛使用的标准以及商业和政府参与者。
本章试图更好地定义已知漏洞的含义，并解释在建立解决方法时需要理解的关键行业术语。
可重用产品中的漏洞
已知漏洞仅适用于具有多个部署的可重用产品，也称为第三方组件。这些产品可以是软件或硬件，免费或商业，但它们总是部署多个实例。如果一个漏洞仅存在于一个系统中，则对其进行清点并让其他人了解它（除了攻击者之外）是没有价值的。
因此，当我们谈到已知的漏洞时，我们只提到可重用的产品。由于大多数已知漏洞处理商业产品（开源已知漏洞的世界有点新生），负责产品的实体通常被称为供应商。在本书中，因为它涉及开源软件包而不是商业软件，所以我将该实体称为软件包的所有者或作者。
漏洞数据库
在最基本的层面上，一旦漏洞被公开发布在一个相当容易找到的位置，就会被认为是漏洞。一旦漏洞被广泛披露，维护者就可以了解它并保护他们的应用程序，但攻击者 - 包括自动化或不太复杂的攻击者 - 也有机会轻松找到并利用它。
也就是说，互联网是一个很大的地方，并拥有大量的软件。新的漏洞会定期披露，有时甚至会在一天内泄漏数十个漏洞。为了使防御者能够跟上，这些漏洞需要存储在一个易于查找的中心位置。为此目的，已经创建了许多结构化数据库，包括商业和开放数据库，以编译这些漏洞和有关它们的信息，允许个人和工具查询测试他们的系统以防止他们持有的漏洞。
此外，有几个数据库专注于开源软件包中的漏洞，例如Snyk的DB，Node Security Project，Rubysec和Victims DB。但是，在深入研究之前，让我们回顾一下已知漏洞数据库世界的更广泛和更标准化的基础：CVE，CWE，CPE和CVSS。
技巧
已知的漏洞与零日
漏洞也可以为某些方所知，但不能公开发布。例如，糟糕的演员经常在流行的库中发现漏洞并在黑市上出售（通常称为“黑暗网络”）。这些漏洞通常被称为零日漏洞，这意味着自披露以来零日已过去。
Common Vulnerabilities and Exposures
常见漏洞与暴露（CVE）
最常见的漏洞信息是常见漏洞和披露（CVE）。 CVE是一个免费的漏洞词典，由美国政府创建和赞助，由MITRE非营利组织维护。在美国政府的支持下，CVE在全球范围内被用作分类系统。
当披露新的漏洞时，可以向MITRE（或其他CVE编号机构之一）报告，该漏洞可以确认问题是真实的并为其分配CVE编号。从那时起，CVE编号可以用作此缺陷的跨系统标识符，从而可以轻松地在安全工具之间进行关联。实际上，即使在为给定漏洞维护自己的ID时，大多数漏洞数据库也会保留并共享CVE。
值得注意的是，CVE本身不是一个数据库，而是一个ID字典。为了帮助自动化系统访问所有CVE，美国政府还支持国家漏洞数据库（NVD）。 NVD是一个数据库，通过标准化的安全内容自动化协议（SCAP）公开漏洞信息。
CVE是一个非常混乱的漏洞列表，因为它适用于各种各样的系统。为了使其与消费者保持一致和可用，MITRE围绕内容和分类制定了各种指导方针和政策。至少对于OSS库世界而言，三个最值得注意的是CPE，CWE和CVSS。
Common Platform Enumeration
通用平台枚举（CPE）
除了它们所代表的大量漏洞之外，CVE还表明了极其不同的产品存在缺陷。为了使您更容易发现给定的CVE是否适用于您的产品，NVD可以使用一个或多个Common Product Enumeration（CPE）字段修改每个CVE。 CPE是一种相对宽松的数据结构，它描述了此CVE适用的产品名称和版本范围（以及可能还有其他数据）。请注意，CPE不是CVE的一部分，而是NVD的一部分。这意味着一个已知的漏洞不会有产品信息，除非它进入NVD，这并不总是会发生（稍后会详细介绍）。
CPE是一个强大的想法，可以实现漏洞的自动发现。但是，以通用方式定义产品非常困难，并且缺乏许多CVE的内容质量。因此，在实践中，CPE通常是不准确的，部分的，或者根本不是自动化友好的，足以实用。严重依赖CPE的产品，如OWASP依赖检查器，需要使用模糊逻辑来理解CPE，并在缺少内容时失败，从而导致大量误报和漏报。
为了解决这一差距，OSS库空间中的大多数商业漏洞扫描程序和数据库仅使用CPE作为起点，但是将CVE的映射保持为相关产品。
Common Weakness Enumeration
常见弱点枚举（CWE）
虽然每个漏洞都是它自己独特的雪花，但在一天结束时，大多数漏洞都属于更有限的漏洞类型列表。 MITER将这些类型分类为Common Weakness Enumeration（CWE）列表，并提供有关每种弱点类型的信息。虽然CWE项目可以非常具体（例如，CWE-608表示在Struts的ActionForm类中使用非私有字段），但其更广泛的类别被更广泛地使用。例如，CWE-285描述了不正当授权，而CWE-20代表了不正确输入验证的许多变体。 CWE也是分层的，允许更广泛的范围CWE包含多个更窄范围的CWE。
较少数量的CWE使得为每个项目提供丰富的详细信息和补救建议更为可行，或者根据漏洞类型定义策略。每个CVE都使用一个或多个CWE进行分类，帮助其消费者专注于他们最感兴趣的CWE，并且无需为每个相关的CVE重复CWE级信息。
常见漏洞评分系统（CVSS）
漏洞定期披露，并以相当惊人的速度披露，但并非所有漏洞都需要放弃所有内容并采取行动。例如，向攻击者泄露信息并不像允许他们远程执行服务器上的命令那么糟糕。此外，如果可以通过简单的HTTP请求利用漏洞，则修复比要求攻击者修改后端文件的漏洞更紧急。
也就是说，对漏洞进行分类并不容易，因为有很多参数，很难判断每个参数的重量。访问DB的程度是否比远程命令执行更严重？如果此执行是作为低权限用户完成的，那么与以root身份执行的漏洞利用相比，应该降低其严重性分数的程度是多少？如何判断需要长序列请求的漏洞，但是可以使用从Web下载的工具来完成？
除此之外，问题的严重性还取决于它所在的系统。例如，银行网站上的信息泄露漏洞比静态新闻网站上的漏洞更严重，需要物理机访问的漏洞对设备而言比对云服务更重要。
为了帮助解决所有这些问题，MITRE创建了一个通用漏洞评分系统（CVSS）。该系统目前处于第三次迭代，因此您可能会看到对CVSSv3的引用，这是此处讨论的版本。 CVSSv3将得分分为三个不同的分数，每个分数分成几个较小的分数：
基础（Base）
有关漏洞的不可变细节，包括攻击媒介，利用复杂性以及它可能产生的影响。
暂时的 （Temporal）
时间敏感信息，例如漏洞利用工具的成熟度或易于修复。
环境的 （Environmental）
易受攻击的系统的上下文信息，例如它的敏感程度或可访问性。
图1-1显示了样本漏洞的CVSSv3评分的变量和计算（计算是使用FIRST.org的在线工具生成的）。
虽然所有三个分数都很重要，但公共数据库通常仅显示基于Base组件的CVSS分数。时间分数的不断变化使维护成本高昂，根据定义，环境分数是每个漏洞实例特有的。尽管如此，这些数据库的用户仍然可以填写这两个分数，根据需要调整权重，并获得最终分数。
CVE和NVD之外的已知漏洞
拥有CVE很有帮助，但这也很麻烦。收到CVE号码要求作者或记者首先了解它，然后进行一定量的文书工作和备案工作。最后，CVE需要得到特定CVE编号机构（CNA）的批准，这需要时间。因此，尽管CVE是某些类型系统（例如，网络设备）中的漏洞的标准，但它们在其他世界中并不常见。
当涉及OSS包中的已知漏洞时，CVE的形状尤其糟糕。截至2017年10月，基于Snyk的数据库，只有67％的Ruby gem漏洞分配了CVE，而11％的npm软件包漏洞只有这样的ID。
造成这种差距的一个原因是，开发人员（而非安全研究人员）报告了许多库漏洞，并将其作为漏洞进行通信。这些问题通常很快得到解决，但一旦修复，作者和记者很少会通过CVE流程。即使他们这样做，CVE的任务也远远落后，而攻击者可能正在利用现在已知的漏洞。
在CVE的分配和将其发布到NVD之间又发生了另一个滞后，提供了更多的细节，也许还有CPE。当新漏洞在经过负责任的披露过程中保留一定数量时，预计会出现此类延迟，但这种延迟通常在漏洞已知后发生。
在查看易受攻击的Maven软件包时，这种滞后非常明显：37％的具有CVE的Maven软件包漏洞在被添加到NVD之前是公开的，其中20％在被添加之前已经公开了40周或更长时间。
NVD上没有的已知漏洞仍然存在，但难以检测。库漏洞可能要么没有CVE，要么没有在NVD上列出（因此没有咨询或CPE），或者质量差的CPE。其中每一项都会阻止它们通过专门依赖这些公共数据源的工具进行检测，尤其是OWASP依赖检查器。
技巧
在没有CVE的情况下使用CWE和CVSS
虽然CVE，CWE和CVSS都是MITRE标准，但它们可以彼此独立使用。 CWE和CVSS通常用于没有CVE的漏洞，即使没有行业范围的ID，也提供标准化的分类和严重性。
未知与已知漏洞
每个已知的漏洞在某些时候都是未知的。这似乎是显而易见的，但这是一个重要的理解点 - 一个新的已知漏洞不是一个新的漏洞，而是一个新披露的漏洞。在发现和报告之前，漏洞本身已存在。然而，虽然披露漏洞并不能创建它，但它确实改变了它应该如何处理，以及它应该如何紧急修复。
对于攻击者来说，查找和利用未知漏洞很难。存在无穷无尽的潜在攻击变体，需要在避免检测的同时快速调用。确定攻击是否成功并不总是容易的，这意味着提交的有效载荷可能已经成功通过，而攻击者仍然不是更聪明。
一旦泄露漏洞，利用它就变得容易多了。攻击者可以详细了解漏洞及其调用方式，只需要识别正在运行的软件（称为指纹识别的过程）并获取恶意负载。通过自动漏洞利用工具可以更轻松地完成此过程，该工具可以列举已知的漏洞及其漏洞。这种自动化还降低了进入障碍，允许不太复杂的攻击者尝试渗透。
已知的漏洞在很大程度上被认为是野外成功攻击的主要原因。引用两个样本来源，Verizon表示“大多数攻击都利用已知的漏洞，这些漏洞从未修补过，尽管有几个月，甚至几年可用的补丁”，赛门铁克预测“到2020年，99％的漏洞利用将继续是已知的漏洞由安全和IT专业人员至少一年“。在应用方面，Gartner和RedMonk等分析公司一再声明处理开源库中已知漏洞的重要性。
因此，应该紧急处理已知的漏洞。即使它是相同的漏洞，它的披露使攻击者更有可能使用它来访问您的系统。漏洞的披露引发了一场竞赛，看看一名防守者是否可以在攻击者通过它之前封堵洞。图1-2显示了攻击者对前面提到的严重Struts2漏洞披露的反应，在几天内从零攻击逐渐增加到每天观察到的超过一千次攻击。
好消息是已知漏洞比未知漏洞更容易防御。通常，已知的漏洞也具有已知的解决方案，通常以软件升级或补丁的形式。即使不存在软件解决方案，您至少应该更好地了解如何检测攻击并防止它们通过安全控制。正如我将在第5章中讨论的那样，重要的是投资系统，让您快速了解此类披露，并比不良行为者更快地采取行动。
负责任的披露
到目前为止，我谈到了披露作为一个单一的时间点，实际上它不应该是二元的。披露漏洞的正确方式，被称为负责任的披露，涉及几个步骤，旨在让维权者在上述竞选中领先一步。
理解负责任的披露对于开源消费者来说并不重要，但对于开源作者来说这一点非常重要。要了解有关负责任披露的更多信息，您可以阅读Tim Kadlec的优秀博客文章，或者查看Snyk负责任的披露模板。
摘要
已知的漏洞并不像最初出现的那么简单。已知的内容的定义和漏洞元数据的管理很难做得很好。
CVE和NVD适用于策划商业产品中的漏洞，但不能扩展到开源项目的卷和所有权模型。随着时间的推移，这些标准可能会发展以满足这种需求，但是现在它们的覆盖范围和细节水平还不足以保护您的库。
原文：https://www.oreilly.com/ideas/what-defines-a-known-open-source-vulnerability
本文:http://pub.intelligentx.net/node/422
讨论： 加入知识星球【首席架构师圈】