过去的一年里，SolarWinds和Kaseya以及Apache log4j漏洞等黑客入侵事件让软件供应链风险得到了更多的关注，也给人们敲响了新的警钟：

无论是通过渗透软件交付管道，还是利用开源组件中现有的漏洞，攻击者都在利用供应链控制的漏洞来危害组织及其客户；安全漏洞威胁已然成为我们无法回避的问题。

开源软件数量呈指数增长，导致我们根本无法单纯通过人力对漏洞进行筛查；且庞大的开源数量群让库间关系越发复杂，我们很难察觉到漏洞的存在。

在快速发展的时代里，效率至上是大家默认的规则。为了尽快产出，研发人员必然会采用大量的开源组件和第三方库。

与此同时，开发者更多关注自身编码是否安全可行，却忽略了这些“外来者”的风险。显而易见的是，当第一个问题出现，后续影响都会接踵而来，从而引发多米诺骨牌效应，造成难以估量的经济损失。

层出不穷的软件安全事件也印证了这一点：黑客只需找到软件供应链中的一个漏洞就可以发起攻击，开发人员却要对整个软件供应链进行维护。一旦出现被攻击的情况，留给研发人员的时间便会被压缩。

我们必须对开源漏洞的审查完成更加自动化和高效化的要求。

为了解决开源应用威胁这一问题，SCA技术应运而生，这是目前对应用程序进行安全检测最有效的办法之一。

01 什么是SCA

SCA（Software Composition Analysis）软件成分分析，通过检测软件许可证、依赖项以及代码库中的已知漏洞和潜在漏洞来分析开源组件，使 DevOps 能够管理其安全风险和许可证合规性。

简单来说，SCA是一项通过分析软件包含的一些信息和特征来实现对该软件的识别、管理、追踪的技术。

02 SCA发展历程

2002年前后出现了第一个开源手动扫描器。尽管该扫描器对提升组织代码库的可见性起到了一定的效果，但同时也会导致很高的误报率。这种错误需要人工干预来解决，与我们最初敏捷开发环境的需求相悖。

时间来到2011年，随着技术的进步，已经能够实时自动检测漏洞和许可问题。与此同时，SCA技术与软件开发工具(如存储库、构建工具、包管理器和CI服务器)集成在一起，极大程度上帮助开发人员掌握开源管理和安全性。

在随后的演进过程中，逐渐丰富了连续自动检测和安全漏洞优先级功能：当软件或者组件的已知漏洞较多时，通过自动识别最大风险的安全漏洞，组织机构可以首先解决优先事项。

直到今天，SCA拥有能够自动修复安全漏洞的技术，可以帮助开发人员确定漏洞所在的位置，为修复提供有关影响构建的可能性数据，从而根据漏洞检测、漏洞严重性、CVSS评分或发布新版本时触发的安全漏洞策略启动自动修复工作流，帮助研发人员不断修补开源组件，减少已知漏洞数量，从而帮助我们远离安全漏洞风险。

03 SCA工作原理

SCA 工具可检查包管理器、清单文件、源代码、二进制文件、容器映像等。

其中，已识别的开源被编译成物料清单（SBOM），然后将其与各种数据库进行比较。但大多数情况下，SCA 扫描程序是从 CI/CD 管道中的生成目录中读取的，有时也会位于开发人员桌面或暂存于服务器上。

SCA可以采用多种策略识别代码库中来自第三方产品的文件，例如一个从已知软件产品中的文件预先计算的哈希列表。当扫描程序运行时，它会遍历计算机软件中所有文件的哈希值，并将它们与其列表进行匹配。因为每个文件的哈希值都是唯一的，所以当哈希匹配时，程序便会知道检测片段中装载了哪些组件以及相关的组件信息。

此外，许多扫描程序可以解析源文件，可以方便定位囊括在自己的代码中的专有代码片段。

由于 SCA扫描程序会更新其已知漏洞列表，即使代码保持不变，每次运行扫描程序时也可能得到不同的结果。这意味着上述过程是可持续发展的，哪怕在软件上线后的几年时间里，人们依然可以依据经常更新其已知漏洞列表去发现软件中的缺陷，极大便利了研发人员对已发布软件的维护。

04 SCA功能

软件成分分析(SCA) 是自动化对开源软件 (Open Source Software) 使用的可见性的过程，用于风险管理、安全性和许可证合规性。

随着所有行业软件中开源 (Open Source) 使用的兴起，跟踪组件的需求呈指数增长，以保护公司免受问题和开源漏洞的影响。由于大多数软件创建都包括操作系统，因此手动跟踪很困难，需要使用自动化来扫描源代码、二进制文件和依赖项。

SCA 解决方案允许在整个软件供应链中对开源使用进行安全风险管理，从而使安全团队和开发人员能够：

• 为所有应用创建准确的物料清单 (SBOM)

SBOM 将描述应用程序中包含的组件、所用组件的版本以及每个组件的许可证类型。SBOM 可帮助安全专业人员和开发人员更好地了解应用程序中使用的组件，并深入了解潜在的安全和许可问题。

• 发现并跟踪所有开源

开源软件和许可证管理扫描工具允许公司发现源代码、二进制文件、容器、构建依赖项、子组件以及修改和开源组件中使用的所有开源。这一点尤其重要，因为公司会考虑广泛的软件供应链，包括合作伙伴、第三方供应商和其他开源项目。

• 制定和执行政策

从开发人员到高级管理人员，开源软件许可证合规性在组织内的各个级别都至关重要。SCA 强调了制定策略、响应许可证合规性和安全事件以及在整个公司范围内提供操作系统培训和知识的需求。许多解决方案能够使审批流程自动化，并设置特定的使用和补救指南。

• 启用主动和持续监控

为了更好地管理工作负载并提高生产力，SCA 继续监控安全和漏洞问题，并允许用户针对当前和已发布产品中新发现的漏洞创建可操作的警报。

• 将开源代码扫描无缝集成到构建环境中

在 DevOps 环境中集成，以便扫描代码并识别构建环境中的依赖项。

01 SCA必要性

作为互联网研发公司，我们很难避免使用开源软件。但大多数开源软件都存在漏洞，且许多开源产品经过二次研发后，构成了由多个不同组件或包组成的复杂生态系统。

例如，使用Linux，Apache或Node.js的公司很可能有数百甚至数千个不同的软件包，这些软件包不是统一的，每一个都有自己的许可要求。

尽管使用容易被攻击的软件或错误的许可证会造成严重的后果，但事实上，我们甚至不知道研发过程中使用哪些第三方软件。

未知才是最大的风险，谁也不知道这座沉寂的火山会在何时喷发。

为了避免安全漏洞带来巨大的经济损失，我们必须进行软件成分分析。目前无论是开源版本还是商业版本，SCA都能识别大多数第三方组件。因其能解决开源软件所涉及的风险，现已广泛应用于软件研发的生命周期。

02 SCA重要性

SCA的重要性在于它提供的安全性和高效性。

手动跟踪开源代码理论上并非不可能，但这需要消耗不必要的人力和精力，面对当前开源的数量绝对不是最佳的方案。

所以，随着技术的进步，SCA技术逐渐完善自动化的高要求，以更好服务于软件研发周期。

软件成分分析是任何安全开发生命周期的标准基本部分。及早发现问题可以降低成本，提高敏捷性，使软件更安全，并帮助开发人员学会将安全性纳入其规划和设计决策中，对于维护软件安全起到了重要作用。

感谢每一位开源社区成员对OpenSCA的支持和贡献。

OpenSCA的代码会在GitHub和Gitee持续迭代，欢迎Star和PR，成为我们的开源贡献者，也可提交问题或建议至Issues。我们会参考大家的建议不断完善OpenSCA开源项目，敬请期待更多功能的支持。

GitHub：
https://github.com/XmirrorSecurity/OpenSCA-cli/releases

Gitee：
https://gitee.com/XmirrorSecurity/OpenSCA-cli/releases

OpenSCA官网：
https://opensca.xmirror.cn/