软件成分分析及其如何识别开源软件风险
软件成分分析的定义
软件成分分析(SCA)是指分析了解应用程序中使用了哪些开源组件和依赖关系，以及如何自动化地使用这些组件和依赖关系。SCA的目的是评估这些组件的安全性并识别它们带来的潜在风险或许可证冲突。为了确保引用的代码不会在产品中引入安全风险或合规问题，将SCA工具有效地纳入软件开发工作流程是加强软件供应链安全性和完整性的重要一步。
为什么需要软件组成分析
从零开始开发软件应用的日子已经一去不复返了。开源软件的广泛引用给应用程序的开发方式带来了变革。个体开发人员和企业可以在他们的代码中引用已有的组件和库来实现各种功能，从简单的Web 表单验证到复杂的加密操作等。
虽然开源代码的引用在一定程度上避免了“重复造轮子”，但随之而来的也包括一些隐患: 例如你引用的代码可能存在着 bug 或脆弱性，又或者代码携带的许可证与所开发应用本身的许可证相冲突。谁来检查这些又是一个问题。
人工检查一批组件或许是个简单的任务，但现代软件应用通常是由数百个库构成的。这些库本身又可能有其他依赖关系。而且一个程序可以运行很多层，若没有意识到这一点，一个应用程序表面上只包含了少量的库，但是在其内部很可能已经引入了成百上千的传递性依赖关系。这时候就需要SCA来解决了。
软件成分分析和SBOM（软件物料清单）
大多数SCA工具都可以生成软件物料清单（SBOM）。SBOM是一个详细清单，这个清单包含了应用程序中所有的依赖关系和组件。一个理想的SBOM可以提供应用程序中所有组件的名称、版本号、发布日期、校验和、许可证信息以及其他元数据。
这可以通过以下方式之一实现：
清单扫描 SCA工具扫描应用程序的构成清单文件，例如package.json、用于JavaScript或pom.ApacheMaven（Java）项目的XML，并根据这些，生成依赖关系列表。如果没有版本控制系统（例如GitHub、GitLab或SVN）中所包含的最终打包文件，那么开发人员可以使用这种方法来扫描应用程序。
二进制扫描 SCA工具扫描打包文件，并通过二进制指纹识别开源组件。此方式通过识别应用程序的最终打包文件中所有包，从而减少误报，并识别以非标准方式引入到应用程序中的第三方软件和库。然而，并不是每个SCA工具都有二进制扫描功能。
清单及二进制扫描 一些SCA解决方案可能会选择混合方法：清单和二进制结合扫描，以获得高精度的SBOM。因此，SCA解决方案的复杂程度决定了它识别隐藏组件的准确程度。
通常，SBOM是以XML、JSON或类似格式的文本文件的形式出现的，这些格式对人和机器都是可读的。XML文档基于OWASP CycloneDX标准，列出了组成KeyClock的组件，包括它们的校验和、版本号、发布日期和许可证信息。值得注意的是，SBOM所含数据显示，单一版本的KeyClope包含900多个组件。
同样是基于文本，但Linux基金会的SPDX标准与CyoNeNDX标准并不相同。
SCA工具如何帮助查找开源漏洞？
自动化的SCA工具可以帮助研发团队开发和发布高质量的代码，并为参与者提供一种积极主动的风险管理方法。在软件开发过程的初期，SCA工具通过识别安全漏洞和风险，使软件开发人员提前无缝地选择更为安全的组件。在应用程序中引入第三方组件和库的初期就充分考虑了安全性评估，降低了重复进行安全评估的需要，从而加快开发过程。
如果具有已知风险和漏洞的组件对于开发工作来说是不可或缺的，那么开发团队可以在首次引入该组件时对其进行判断，并找出更好的解决方法来安全地使用该组件。
SCA方法和工具的目标不仅仅是扫描应用程序的资源和二进制文件来生成SBOM，更关键的挑战在于准确地将组件的每个版本对应已知的漏洞。此外还有合规性方面：让参与者无缝地检查和解决组件造成的许可证冲突。
几年前，这个过程可能很简单。只要检查MITRE或NVD提供的CVE feeds，并将它们对应到应用程序的组件版本就足够了。在一项研究中，中佛罗里达大学、乔治梅森大学和佐治亚理工大学合作发表了一篇论文，表明：CVE的建议往往是不准确的，并且具有不一致性。另外，CPE（Common Platform Enumeration）平台数据在这些建议中的呈现方式，也可能使CVE数据被曲解。
例如，针对Tomcat服务器中漏洞发布的CVE建议可能仅适用于Apache Tomcat命名空间下的选定组件，例如org、Apache、tomcat:coyote，而不是整个ApacheTomcat名称空间，但CVE建议中提到的CPE，可能并不能从而清楚地从而此局限性。
因此，SCA工具需要足够智能，以准确地将安全漏洞对应到受影响的组件，而不是盲目地相信CVE建议，标记良性组件。为了最大限度地减少开发人员之间的冲突，同时让安全评估和合规团队和平相处，SCA解决方案需要在避免引入漏报的风险（即未能发现安全风险）的情况下，最大限度地减少结果中出现误报漏洞的可能性。但这可能需要人工干预、安全研究以及基于签名的文件扫描工具。
此外，仅依靠CVE feeds获取安全情报是不够的。漏洞咨询可能出现在产品供应商网站、GitHub和许多其他地方，包括私人数据库。同样的，关于零日攻击的概念验证漏洞以及已知漏洞可能会出现在漏洞数据库、黑客论坛和其他神秘的地方。然而，并不是所有的SCA工具都是相同的，也并不是所有的SCA工具都需要有从大量的资源中获取情报，并理解成千上万的情报的能力。
新的供应链威胁：恶意软件、被劫持的库、依赖关系混乱
组织选择SCA工具时，不仅需要考虑已知的安全风险和漏洞，同时也更加需要考虑层出不穷的新型攻击。
就好像领先零日攻击已经不再是问题一样，正如我们所见，误植域名攻击以及渗透到npm、PyPI和RubyGems等开放源代码注册中心的依赖混淆恶意软件的出现率越来越高。并且，这些攻击均处于一个不断发展的阶段。
通过分析渗透到开源生态系统中的数百个恶意软件样本和依赖混淆，。2021年10月，功能性勒索代码第一次被发现包含在一个名为noblox.js-proxies的“误植域名”中。这个合法的包名为noblox.js-proxied，是官方Noblox的镜像，Roblox游戏的一个API封装包。
同月，不法分子还劫持了热门的NPM库、 ua-parser-js、 coa 和 rc，向其中安装加密器和密码窃取器。由于UA解析器库每周下载超过700万次，脸书、微软、亚马逊、谷歌等科技公司都在使用它，这也表明了此次劫持可能造成的影响巨大。同样地，coa每周的下载量约为900万次，rc约为1400万次。
然而，这起供应链事件并不仅仅是一次误植域名攻击或依赖关系劫持攻击，同时不法分子也窃取了这些项目背后的主要维护者的npm账户。JetBrains透露了对Kotlin/JS开发人员的潜在影响：由于uaparser-js是Karma测试框架的依赖项之一，Kotlin/JS开发人员在遭到攻击期间运行了Karma测试用例。
所有这些都引发了一个问题：你的SCA工具是否能够在恶意软件注入、网络钓鱼攻击、依赖性劫持和受损库分布到下游前发现它们？
对于自动化工具来说，识别构成应用程序的数千个组件本身就是一项艰巨的任务，更不用说开发人员团队了。同样困难的还有筛选安全源的任务，这需要列出数千个可能适用于或不适用于你应用程序的漏洞。最后，不断演变的威胁形势进一步使软件供应链的安全性和完整性问题变得复杂。将全面、快速、准确的SCA解决方案集成到软件开发工作流程中已经变得至关重要，然而获得一个能够解决上述大多数新威胁的解决方案仍然是一个挑战。
附：数世咨询中国数字安全能力图谱中“开发安全”及能力企业
开源组件的广泛引用，为高速迭代的软件应用开发带来了极大的便利，提高研发效率的同时，也降低了开发成本。但与此同时，开源组件所携带的的各种安全隐患也一并进入了软件应用。随着应用交付规模和频率的日益增长，人们越来越重视开发效率，却逐渐淡化了安全的重要性。然而软件开发安全才是“木桶上那根最短的木板”。只有做好合规风险管控和安全态势的感知，才能使软件开发工作顺利且高质量的完成。所以，选择适合自己的SCA工具，并有效地将其集成在开发流程中是软件开发工作中的必不可少的环节。
参考阅读