您是否知道高达90％的应用程序通常包含第三方组件，主要是开源软件？您是否知道全球500强中超过50％使用易受攻击的开源组件？
在当今的软件开发环境中，大量的工作被大量供应给开源开发人员和社区的大型社区，他们对这些创建的安全问题知之甚少，更不用说管理这种风险的方法了。我们都知道我们不能停止使用开源，我们知道没有人想停止使用它。在BlackDuck软件的一项调查中，43％的受访者表示他们认为开源软件优于其商业同类软件。
开源是强大的，世界上最好的开发人员使用它，但现在是时候停止忽略安全问题并开始跟踪软件中的依赖项。首先，我将快速分析开源软件依赖关系中与安全风险相关的持续安全问题，然后我将用一系列工具来包装，您现在可以开始使用这些工具来领先于关于这个问题的曲线。
软件依赖性通常是最大的攻击面
组织通常假设大多数风险来自面向公众的Web应用程序。那已经改变了。每个应用程序中都有许多小组件，风险可以来自代码库中的任何位置。
虽然像Heartbleed，ShellShock和DROWN攻击这样的漏洞使得标题太大而无法忽略，但依赖关系中发现的大多数错误常常被忽视。
这个问题有几个原因。对于初学者来说，大多数组织没有准确的不同应用程序使用的软件依赖性清单。此外，除了来自支持项目的社区的微薄通知之外，大多数组织没有可靠的方法在发现零天或提供补丁时得到通知。
开源漏洞信息是碎片化的
大多数组织在CVE和NIST漏洞数据库中搜索漏洞信息，但这些来源提供的开源漏洞信息非常少。有关开源漏洞的信息分布在众多不同的来源中，因此很难跟踪它。
更糟糕的是，OSVDB是最大的漏洞数据库之一，它主要用于跟踪开源特定的漏洞，只是关闭了商店，跟随SecurityFocus之类的其他漏洞。虽然这导致了其他安全存储库的出现，例如针对JavaScript / Node.js特定漏洞的Node Security Project和针对Ruby特定漏洞的RubySec，但仍有许多项目和生态系统尚未得到很好的覆盖。
组织仍然认为开源代码更安全
关于开源更加安全的误解始于Linus'Law以Linus Torvalds的名字命名，并由Eric S. Raymond在他的论文和书“The Cathedral and the Bazaar-and Linus”的名言中提出：
“如果有足够的眼球，所有的虫子都很浅。” - Linus Torvalds
这本书在1999年首次出版时可能是相关的。然而，考虑到OpenSSL库中存在诸如ShellShock之类的错误超过22年，它现在远非相关。最大的问题是组织仍然认为开源代码比商业代码更安全;只需阅读此Reddit主题即可了解人们如何查看此主题。
别误会我的意思。我并不是说开源不如商业安全。我所说的是，如果没有刻意保护一段代码（开源或不开源），那么代码就不安全了。有意识的努力意味着诸如通过训练有素的“眼球”进行代码检查，动态安全扫描和渗透测试等活动。
开源生态系统比我们想象的更脆弱，这是可怕的
整个依赖生态系统都很脆弱。最近的事件给整个NodeJS社区带来了残酷的现实检查，因为一名程序员通过删除11行代码几乎打破了互联网。攻击者可以很容易地获取这些软件包的命名空间，破坏版本，并添加恶意代码替换实际的预期代码。
幸运的是，一个非恶意的开发者能够抓住超过240个所述包，然后才落入坏人之手。
试图解决问题
OWASP认识到了这个问题，并在2013年向OWASP Top 10添加了“使用已知漏洞的组件”。根据OWASP，这是问题的定义：
“组件，例如库，框架和其他软件模块，几乎总是以完全权限运行。如果利用易受攻击的组件，这种攻击可能会导致严重的数据丢失或服务器接管。使用具有已知漏洞的组件的应用程序可能会破坏应用程序防御并实现一系列可能的攻击和影响。“
多年来出现了不同的开源和商业工具来解决这个问题。每个工具/服务解决问题的方式都有所不同，因此我的咨询公司已经联系了项目负责人和公司的CEO，以获得他们如何相信他们的工具对解决方案有贡献以及他们看到工具未来的位置的反馈。
节点安全项目（NSP）
NSP以其在Node.js模块和NPM依赖项上的工作而闻名。它还提供了使用公共漏洞数据库扫描依赖关系并查找漏洞的工具，例如NIST国家漏洞数据库（NVD）以及它自己的数据库，它是根据它在NPM模块上进行的扫描构建的。
来自NSP的Adam Baldwin认为，依赖安全是SDLC的一部分：“很快您将看到我们的许多产品，包括持续的安全监控以及与GitHub（和其他产品）的集成，以便您可以插入安全监控，检测，警报和修复与您相关的开发生命周期区域。“
RetireJS
RetireJS是一个开源的，特定于JavaScript的依赖检查器。该项目主要侧重于易用性。这就是为什么它有多个组件，包括Grunt，Gulp，Chrome，Firefox，ZAP和Burp的命令行扫描程序和插件。 RetireJS还为希望了解他们是否使用具有已知漏洞的JavaScript库的JS开发人员提供了站点检查服务。
RetireJS从NIST NVD以及众多其他来源检索其漏洞信息，包括邮件列表，错误跟踪系统和流行JavaScript项目的博客。来自RetireJS的Erlend Oftedal认为安全是每个人的问题，需要更多的协作：“我希望看到流行的开源框架的作者自己开始向Retire.js等工具报告安全修复，以便保护他们软件的用户更安全“。
OSSIndex
OSSIndex支持多种技术。它从NPM，Nuget，Maven Central Repository，Bower，Chocolatey和MSI中提取依赖性信息（这意味着它涵盖了JavaScript，.NET / C＃和Java生态系统）。 OSSIndex还免费提供漏洞API。
OSSIndex当前从NIST NVD检索其漏洞信息。 OSSIndex的Ken Duck计划在不久的将来包括从一些关键邮件列表，数据库和错误跟踪系统中自动导入漏洞。
依赖检查
依赖检查是OWASP的一个开源命令行工具，维护得很好。它既可以在独立模式下使用，也可以在构建工具中使用。依赖性检查支持Java，.NET，JavaScript和Ruby。该工具严格从NIST NVD检索其漏洞信息。
捆绑审计
Bundler-audit是一个开源的命令行依赖检查器，专注于Ruby Bundler。该项目从NIST NVD和RubySec检索其漏洞信息，RubySec是一个Ruby漏洞数据库。
Hakiri
Hakiri是一个商业工具，它使用静态代码分析为基于Ruby和Rails的GitHub项目提供依赖性检查。它为公共开源项目提供免费计划，并为私人项目提供付费计划。它使用NVD和Ruby Advisory Database。
来自Hakiri的Vasily Vasinov表示，该软件的未来计划包括增加与Slack，JIRA和Pivotal Tracker的集成，以及支持Node.js和PHP等其他平台。
Snyk
Snyk是一个专注于JavaScript npm依赖项的商业服务。 Snyk是现场的新成员。它不仅提供了检测JavaScript项目中已知漏洞的工具，还帮助用户使用Snyk创建的引导式升级和开源补丁来解决这些问题。
Snyk有自己的漏洞数据库，它从NIST NVD和NSP获取数据。 Snyk的重点是通过更好的协作工具和更严格的GitHub集成，扩展整个组织及其团队的已知漏洞处理。 Snyk的首席执行官Guy Podjarny表示，Snyk未来的计划包括构建运行时工具，这些工具可以让开发人员在生产系统上运行开源软件包时获得更好的可视性和控制力。
Gemnasium
Gemnasium是一个商业工具，具有免费的启动计划。 Gemnasium拥有自己的数据库，可以从多个来源获取。但是，虽然每天都会手动审查漏洞，但不会自动发布建议。
Gemnasium提供了一种独特的自动更新功能，该功能使用特殊算法来测试依赖集的智能组合，而不是测试所有组合，从而节省了大量时间。 Gemnasium支持Ruby，NPM（JavaScript），PHP，Python和Bower（JavaScript）。 Gemnasium的另一个独特产品是Slack集成 - 一旦检测到建议，用户就会通过Slack实时通知。
来自Gemnasium的PhilippeLafoucrière表示，未来的计划包括Gemnasium的企业版，在客户所在地运行，支持更多语言，从Java开始。
SRC：CLR
Source Clear是一个具有几个有趣属性的商业工具。它有自己的数据库，利用NIST NVD，但它也从邮件列表和其他几个来源检索漏洞信息。
它为多个IDE，部署系统和源存储库以及命令行界面提供了大量插件。最后，Source Clear使用“易受攻击的方法识别”，这是一种确定应用程序中是否实际使用了依赖项中发现的漏洞的方法。它是一项功能，可以显着减少误报，并为开发人员提供有关漏洞的详细目标报告。 Source Clear刚宣布计划提供其软件的免费版本。
荣誉奖
BlackDuck软件，Sonatype的Nexus和Protecode是企业产品，为第三方组件和供应链管理提供更多的端到端解决方案，包括许可，安全，库存，策略执行等.SecurifyGraphs是一个软件工具我的咨询公司安全，它根据CVSS风险评分帮助比较开源项目。
- 登录 发表评论
- 137 次浏览