什么是软件成分分析 (SCA)？

SCA 工具通过扫描软件的源代码，将其收集到数据库中，与已知漏洞数据库进行比较，检查更新或许可证问题，然后生成报告来运作。 

虽然软件成分分析可以扫描各种软件元素，包括专有组件和容器镜像，但它最常用于分析开源库。几乎所有现代代码库都在一定程度上包含了开源组件，并且由于这些代码中的漏洞是公开的，因此保持开源软件的更新和透明尤为重要。

SCA 工具管理着来自未知来源软件组件的安全漏洞风险、不同开源许可证之间的兼容性问题，以及开源库文档或支持不完整或不足所带来的风险。 

软件成分分析是 云原生  DevOps  管道的一部分，该管道将软件开发流程与 IT 运维相结合。作为  DevSecOps  管道的一部分，SCA 也支持组织的 安全态势 ，该管道将安全与开发和运维相结合。SCA 工具可以部署在 集成开发环境 (IDE) 中，在开发过程中提供实时代码分析。

SCA 不同于其他形式的 漏洞扫描 ，例如静态应用安全测试 (SAST)、 动态应用安全测试 (DAST)  和依赖项扫描。

IT 团队经常使用 SCA 工具来生成 软件物料清单 (SBOM)。 SBOM 以机器可读的格式列出软件产品中的所有组件、库和模块，用于合规性和供应链安全。SBOM 还可以进一步为 SCA 扫描策略提供信息。

根据国际数据公司的调查数据， 截至 2024 年，在员工人数至少为 100 人的公司中，有 93% 使用开源软件，这凸显了对 SCA 解决方案的广泛需求。¹

SCA 通过收集源代码、与漏洞数据库进行比较、分析代码库以发现潜在的合规性问题、去除误报，并为网络安全和开发团队创建报告来工作。 

SCA 工具在开发过程中主动扫描和分析代码，是贯穿整个开发生命周期的 持续集成和持续交付 (CI/CD) 管道 的一部分，主要关注开源组件和第三方依赖项。

为此，SCA 工具首先列出 IT 环境中所有软件的基本元素，包括它们的组件、框架、库、 容器镜像、模块和依赖项。SCA 扫描的两种主要形式是： 

• 静态扫描（或清单扫描）， 它读取配置和 元数据 文件，以查找其中明确描述的元素。

• 动态扫描（或运行时扫描）， 它通过扫描二进制代码来识别实时运行的库。 

两种扫描类型各有优缺点。静态扫描可能会包含源代码中第三方组件的漏洞，而这些组件实际上并未部署在运行时环境中，从而产生误报。另一方面，动态扫描可能永远不会完全彻底，因为并非代码的所有元素都会在运行时环境中执行。许多组织结合使用这两种扫描方式。

一旦 SCA 工具完成代码收集，它会创建一个软件物料清单 (SBOM)，并将 SBOM 的组件与描述常见漏洞和现代软件安全风险的数据库进行比较。

安全团队将 SBOM 与已知安全漏洞的专有数据库以及公共数据库 (NVD)（如 国家漏洞数据库 NVD  或 常见漏洞与风险 (CVE)  列表）进行比对。一旦标记出潜在漏洞，SCA 工具会为每个漏洞分配一个威胁评分（ 常见漏洞评分系统 (CVSS)），帮助网络安全团队确定修复优先级。

部分安全工具通过在 CI/CD 管道中自动应用相应的补丁或更新来实现漏洞管理的自动化。安全团队通常会对这一过程进行监控，确保所做的更改不会影响现有的依赖关系或功能。

SCA 工具还会根据公司关于软件许可的政策和法律法规检查 SBOM，确保合规。

开源促进会列出了超过 100 种经批准的开源许可证，其中一些允许基于开源代码创建专有产品。然而，并非所有许可证都相互兼容，这意味着组织有责任确保其产品符合相关规定。

SCA 解决方案可以检查所有开源软件是否包含所需的归属声明，或者确保受“著佐权”（即禁止将其用于专有版权软件）约束的元素未被纳入该专有软件的开发中。 

软件成分分析还可以检测项目组件之间的依赖关系，这是潜在漏洞的一个主要来源。

SCA 工具既能检测直接依赖关系（即软件组件在代码层面直接相互使用的情况），也能检测传递性依赖关系。传递性依赖是指某个软件间接依赖于其某个直接依赖项所依赖的另一个软件组件。例如：组件 A 依赖于组件 B，而组件 B 依赖于组件 C。在这种情况下，组件 A 就传递性地依赖于组件 C。

SCA 工具必须判断哪些依赖关系会引入漏洞，哪些不会，从而减少误报。它们通过评估软件供应链并确定代码中的漏洞是否“可达”来实现这一点——即，在当前网络配置下，该漏洞是否会在运行时环境中被调用。 

软件成分分析的结果随后会被编译成报告，通常通过专有仪表板、JSON 文件等原始数据、新的 SBOM 或这三者的某种组合来呈现。

近年来，开发人员在减少这些报告中的误报方面取得了进展。

• 漏洞方法分析通过追踪软件组件的调用路径，确保检测到的漏洞是可达的。

• 机器学习 和 人工智能 有助于识别误报。通过正确的训练，模型能够准确判断漏洞是否可达。 自然语言处理技术 也被用于分析来自 GitHub 等仓库的版本控制提交信息，检测代码中无法识别的潜在问题。 

一些 SCA 工具包含持续监控和自动修复功能，进一步将该实践集成到 DevSecOps 开发工作流中。自动修复通常通过发起拉取请求来实现，通知开发者修复许可问题或应用新的安全补丁。

SCA 的优势包括提升组织对其合规性和网络安全状况的信心，以及提高 IT 工作流的自动化程度。

通过帮助确保 IT 生态系统中所有开源组件的使用都符合其许可和合规要求，SCA 可以帮助组织降低法律风险。

识别由开源软件组件的不可预测性造成的网络漏洞，是 IT 风险管理的关键部分。通过提高开源软件供应链的透明度，组织可以享受可定制性和较低成本带来的好处，同时确信他们已经降低了随之而来的安全风险。

通过自动化处理大量的漏洞、依赖项和合规性跟踪工作，SCA 解决方案解放了 IT 团队，让他们能够完成其他任务。这种广泛的自动化也有助于强化组织的 DevOps 实践。

软件成分分析带来的一些挑战包括：跟踪漏洞的全面性不足、限制误报以及管理分析范围。

软件成分分析不同于 DAST 和 SAST，后两者是用于识别现代应用程序安全漏洞的另外两种测试方法。 

SCA 为 IT 团队提供软件组件、依赖项和漏洞的全面地图，而 DAST 和 SAST 则侧重于揭示这些组件以及它们所构成的更大软件应用程序中的个体缺陷。

DAST 和 SAST 之间的区别类似于 SCA 中静态扫描与动态扫描的区别。动态应用安全测试 (DAST) 在应用程序的生产环境中对其进行评估，模拟恶意用户行为和网络攻击，帮助识别安全问题。静态应用安全测试 (SAST) 则深入应用程序的源代码，在代码编写过程中搜寻其中的漏洞。  

SCA 侧重于枚举和分析给定软件中的组件，而 DAST 和 SAST 则专门侧重于测试该软件的安全漏洞，前者针对运行时，后者针对源代码。两者通常与 SCA 一起使用，但也可以独立进行。 

SCA 不同于 依赖项映射，后者是在组织的 IT 运营中识别、理解和可视化应用程序、系统及流程之间关系的过程。

SCA 工具提供组件依赖关系的概览，并识别可能由此产生的潜在漏洞，但依赖项映射指的是更广泛的可观测性实践类别，旨在识别整个 IT 环境中的依赖关系。

依赖项映射可以关注应用程序内部及之间的依赖关系，但它也可以范围更大，寻找网络基础设施或整个真实世界系统（如智能电网）中的依赖关系。依赖项映射通常是 SCA 实践的一个组成部分，但也可以独立于 SCA 解决方案单独执行。