今年对确保开源生态系统的完整性和安全性提出了更大的挑战。开源为开发人员带来了巨大的好处，因为几乎任何人都可以免费使用、定制和为社区做贡献。这种方法可确保更高的透明度、安全性并促进开发人员跨项目协作，也为对手从中获利铺平了道路。作为一名安全研究员，今年我遇到并分析了700多个RubyGems包，这些包被植入并仅用于挖掘比特币。另一个流行的例子是OctopusScanner，这是一种恶意软件，它已经悄悄地将触角伸入了至少26个GitHub项目。这些事件强调了一个事实，即任何向公众开放的系统也对对手开放并且容易被滥用。上述示例主要针对恶意组件。带有未被注意的安全漏洞的合法开源软件包又如何呢？易受攻击的或恶意的包进入流行的存储库并最终进入您的软件供应链可能会对您的客户造成严重破坏。已在流行的开源存储库（例如npm、PyPI、NuGet和Fedora）中检测到易受攻击的恶意组件。“在过去的几年里，我们看到了整个生态系统中开源包中发现的所有漏洞，传统上，Node.js和Java每年都会显示出最多的新漏洞，”Snyk开源安全报告2020作者说。该报告还表明，在软件开发过程的早期实施的安全措施是2019年报告的新漏洞数量少于2018年的原因。软件开始得到回报，”报告继续说道。以下是提高开源代码安全性的一些最佳实践。1.了解你的软件Sonatype进行的2020年DevSecOps社区调查显示，大多数公司——即使是那些在工作流程中内置了某种程度的DevSps实践的公司——都缺乏用于软件应用程序的知识。全面了解所有开源组件及其应用的漏洞。“当在开源项目中发现漏洞时，您应该立即提出两个问题：我们是否使用过该开源组件，以及（如果使用过）它在哪里？”该报告的作者说。根据Sonatype对5,000多名开发人员的调查，只有45%的组织拥有成熟的DevOps实践，为其应用程序维护完整的软件物料清单(SBOM)。“调查结果表明，多达74%的‘不成熟做法’组织无法知道开源组件中新披露的漏洞是否适用于他们的软件，”报告称。这意味着完整SBOM实践不成熟的组织将无法知道他们是否正在使用易受攻击的开源代码，或者在他们的环境中哪里可以找到新发布的漏洞。鉴于每天在NVD、GitHub和其他托管网站上发布的大量漏洞，如果没有一些自动化解决方案，开发人员和安全专家将很难跟上数据。历史表明，大多数组织会等到安全事件发生后才加强其安全措施。然而，俗话说，一分预防胜于一分治疗。通过在软件开发生命周期中采用“左移”方法，早期实施的安全性可以获得十倍的回报并提高开发人员的整体意识。2.解决依赖问题Veracode的2020年软件安全状况报告强调了一个常见的软件安全问题。与开发人员本身不同，“相互关联的依赖关系”间接地给应用程序带来了大多数开发人员可能没有注意到的潜在风险。“我们的数据显示，大多数有缺陷的库会间接变成代码。应用程序中47%的有缺陷的库是可传递的——换句话说，它们不是由开发人员直接引入的，而是由库引入的（42%直接引入，12%两者兼有）。这意味着开发人员正在引入比他们预期更多的代码，通常是有缺陷的代码。然而，根据Veracode的说法，纠正这个问题似乎并不是一项重大任务：“解决这些库中的安全漏洞通常不是一项重大工作。库在应用程序中引入的大部分缺陷（将近75%）可以通过次要版本更新来解决。通常不需要主要的库升级！这些数据表明问题更多的是发现和跟踪问题，而不是大规模代码重构。”3.自动代码扫描以查找未知项目章鱼扫描事件和其他形式的开源生态系统滥用（例如域名仿冒）促使GitHub等库维护者强制要求对他们托管的开源项目进行自动扫描。正如今年报道的那样，GitHub现在已经集成了基于CodeQL的开源存储库的自动扫描。GitHub高级产品经理JustinHutchings告诉TheRegister网站，“事实证明，这种能力在安全方面非常有用。大多数安全问题只是错误的数据流或错误的数据使用。”“除了识别隐藏的漏洞和错误之外，还可以定期扫描开源项目以查找数据泄漏的迹象，例如贡献者无意中暴露的私钥和凭据。从去年开始，一些供应商已将自动扫描集成到他们的产品中以识别恶意软件发布到合法的开源存储库。这些技术将行为分析与机器学习相结合，以主动寻找“假部件”。独立开发人员致力于更小规模发布的实验性开源扫描器(npm-scan)也已经出现，它可以使用启发式方法检测易受攻击的组件。在组件进入供应链之前使用自动化工具实施如此广泛的安全审计有助于提高信任度和完整性开源生态系统中的问题。4.提防许可风险使用开源软件的一个主要好处是其许可证提供的自由。如果您在开源中发现错误，请自行修复，而不是等待供应商。您可以根据您的项目定制您认为合适的开源应用程序，并将定制版本交付给您的客户。但是，请注意使用开源组件可能产生的任何潜在后果可能需要更多技巧。2020年开源安全和Synopsys发布的风险分析报告指出，当代码库中包含开源组件，其许可可能与整体li冲突代码库的cense，会出现声明的许可冲突。例如，GNUGeneralPublicLicensev2.0(GPLv2)下的代码在编译成商业软件的正常分发时，通常会出现冲突问题。但对于被认为是服务(SaaS)软件的软件，相同的代码不是问题。”这些相互冲突的术语可能会让在不同上下文中使用相同开源应用程序的开发人员感到困惑。除了漏洞和恶意组件，一些自动化解决方案还可以识别大量许可证及其导致的潜在冲突。BlackDuck的一份报告发现，2019年审计的代码库中有67%包含存在许可证冲突的组件。对于某些行业，例如互联网和移动应用程序，百分比高得多（93%）。“GPL是比较流行的开源许可证之一，其各种版本也可能与代码库中的其他代码产生许可证冲突。事实上，前10个冲突许可证中有5个是GPL及其变体。身体，”报告说。
