22

避免开源代码漏洞的4个优秀实践

 4 years ago
source link: http://netsecurity.51cto.com/art/202009/625768.htm
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

今年对确保开源生态系统的完整性和安全性提出了更大的挑战。开源对开发者来说有非常大的好处,因为几乎任何人都可以免费地使用和定制它,并为社区做出贡献。这种能够确保更大透明度、安全性和促进开发人员跨项目协作的方式,也为对手从中获利铺平了道路。

uaYJzyQ.jpg!mobile

作为一名安全研究人员,我在今年遇到并分析了700多个被植入了的RubyGems软件包,除了挖掘比特币之外没有任何其他用途。还有一个很受欢迎的例子是章鱼扫描仪,这是一种恶意软件,它已经悄悄地把它的触角注入到了至少26个GitHub项目当中。这些事件强调了这样一个事实,即任何对公众开放的系统也会对对手开放,并且容易被滥用。

上面的例子集中在恶意组件上面。那些没有被注意到的拥有安全漏洞的合法开源包呢?

一个易受攻击或恶意的软件包进入流行的存储库,并最终进入你的软件供应链,可能会对你的客户造成严重破坏。在npm、PyPI、NuGet和Fedora等流行的开源存储库中,已经检测到了脆弱的和恶意的组件。

“在过去的几年里,我们已经看到了在整个生态系统的开源包中所发现的所有漏洞,传统上,Node.js和Java每年都显示出了最大数量的新漏洞,”Snyk开源安全报告2020的作者说。

该报告还表明,在软件开发过程早期实施的安全措施是2019年报告的新漏洞比2018年少的原因。“如果这一趋势持续下去,这可能是一个积极迹象,表明提高开源软件安全性的努力正在开始取得成效,”报告继续说道。

下面是一些提高开源代码安全性的最佳实践。

1. 了解你的软件

Sonatype进行的2020年DevSecOps社区调查显示,大多数公司--即使是那些在其工作流程中内置了某种程度的DevSps实践的公司,也缺乏对其软件应用程序所使用的所有开源组件以及应用于它们的漏洞的全面了解。

“当一个开放源代码的项目中发现一个漏洞时,你应该立即问两个问题:我们是否曾经使用过该开源组件,以及(如果是的话)它在哪里?”报告作者说。

Sonatype对5000多名开发人员的调查显示,只有45%拥有成熟DevOps实践的组织为其应用程序保留了完整的软件物料清单(SBOM)。“调查结果显示,在有‘不成熟实践’的组织中,多达74%的组织无法知道一个新披露的开源组件中的漏洞是否适用于他们的软件,”该报告说。这意味着那些拥有完整SBOM的不成熟实践的组织将无法知道他们是否使用了易受攻击的开源代码,也不知道在他们的环境中哪里可以找到新发布的漏洞。

考虑到每天在NVD、GitHub和其他托管网站上发布的大量漏洞,如果没有一些自动化的解决方案,开发者和安全专家将很难跟上这些数据。历史表明,大多数组织都是等到安全事件发生后才会加强他们的安全措施。然而,俗话说,一分预防胜于一分治疗。

通过在软件开发生命周期中采用“左移”的方法,在早期实现的安全性可以获得十倍的回报,并提高开发人员的整体意识。

2. 解决依赖性问题

Veracode的2020年软件安全状态报告强调了一个常见的软件安全问题。与开发人员本身不同,“相互关联的依赖关系”会间接地在应用程序中引入潜在的风险,这些风险可能会被大多数开发人员所忽略。“我们的数据显示,大多数有缺陷的库都间接地变成了代码。应用程序中有47%的缺陷库是可传递的--换句话说,它们不是由开发人员直接引入的,而是由某个库所引入的(42%是直接引入的,12%是两者兼而有之)。这意味着开发人员引入的代码会比他们预期的要多,而且往往是有缺陷的代码。”

然而,根据Veracode的说法,纠正这个问题似乎并不是一项重大的任务:“解决这些库中的安全缺陷通常不是一项重要的工作。应用程序中大多数库所引入的缺陷(将近75%)都可以通过较小的版本更新来解决。通常不需要主要库的升级!这一数据表明,问题的关键在于发现和跟踪,而不是大规模的代码重构。”

3. 自动进行代码扫描以查找未知项

章鱼扫描事件和其他形式的开源生态系统的滥用,如typosquatting,已经促使像GitHub这样的库维护者必须强制对他们所托管的开源项目进行自动扫描。正如今年所报道的那样,GitHub现在已经集成了基于CodeQL的开源存储库的自动扫描。

GitHub高级产品经理Justin Hutchings告诉Register网站,“事实证明,这种能力在安全方面是非常有用的。大多数安全问题都只是错误的数据流或错误的数据使用。”

除了识别出隐藏的漏洞和bug之外,还可以定期扫描开放源码的项目,以寻找出数据泄漏的迹象,比如贡献者无意中公开的私钥和凭证。从去年开始,一些供应商就已经在他们的产品中集成了自动扫描功能,以识别发布到合法开源存储库中的恶意软件。这些技术会将行为分析与机器学习相结合,以主动搜寻“假冒部件”。

独立开发人员在较小规模上发布的实验性开源扫描器(npm-scan)也出现了,可以使用启发式方法检测易受攻击的组件。

在组件进入供应链之前,使用自动化工具实现这种广泛的安全审计可以帮助增加开源生态系统中的信任度和完整性问题。

4. 小心许可风险

使用开源软件的关键好处是它的许可证所提供的自由。如果你在开源包中发现了一个尚未修复的bug,你可以选择自己修复它,而不是等待供应商。你可以在你的项目中定制一个你认为合适的开源应用程序,并将定制的版本交付给你的客户。

但是,要了解使用开源组件可能产生的任何潜在的许可冲突,就可能需要更多的技巧了。Synopsys发布的2020年开源安全与风险分析报告指出:

当一个代码库包含开源组件,而其许可证可能与代码库的总体许可证发生冲突时,声明的许可证冲突就会出现。例如,GNU通用公共许可证v2.0(GPLv2)下的代码在编译成一个正常分布的商业软件时通常就会引起冲突问题。但对于被认为是软件即服务(SaaS)的软件来说,相同的代码就不是问题。”

对于在不同上下文中使用相同的开源应用程序的开发人员来说,这些相互冲突的术语可能会造成混淆。除了漏洞和恶意组件之外,一些自动化解决方案还可以识别出大量的许可证和由它们所引起的潜在冲突。

Black Duck的一份报告发现,2019年审计的代码库中有67%包含有许可证冲突的组件。对于某些行业,如互联网和移动应用程序,这一比例还要高得多(93%)。“GPL是比较流行的开源许可之一,它的各种版本也可能会与代码库中的其他代码产生许可冲突。事实上,前10个有冲突的许可证中有5个就是GPL及其变体,”该报告称。

【责任编辑:赵宁宁 TEL:(010)68476606】


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK