什么是下一代软件成分分析?

目录

SCA 的发展历程

软件组成分析(Software Composition Analysis,简称 SCA)已经存在了相当长的时间,可以追溯到 2000 年代初。这使其成为一项超过二十年的技术。Blackduck 在企业级 SCA 市场中占据主导地位,而 OWASP Dependency Check 则填补了开源替代方案的空白。由于缺乏适合工具消费的标准化漏洞数据库,构建 SCA 工具曾被认为是一项劳动密集且资源密集的过去式任务。虽然 NVD 是首选数据库,但它缺乏适当的 enrichment 信息,无法使 SCA 工具有效地将 CVE 与代码库中识别的 OSS 组件(库)进行匹配。

问题是什么?

传统的软件组成分析(SCA)通过识别第三方库来工作,其方式要么是读取包清单文件,如 pom.xmlpackage-lock.json,要么在极少数情况下通过分析源代码或二进制文件来识别此类外部依赖项。这些工具随后通过使用库名称和版本查询公共数据库(如 NVD 数据库)来将已识别的库与公开已知漏洞(CVE)进行匹配,并报告所有匹配的漏洞。这种方法会产生大量噪音,由于软件规模合理时产生的告警疲劳,实际上大多数情况下是不可用的。这是因为,从根本上说

  1. 漏洞存在于某个库的某些代码中
  2. 存在漏洞的代码属于库中的一个函数
  3. 库中的其他一切都是存在漏洞的

这意味着,存在漏洞的并非库(版本)本身,而是库版本中的某组函数。因此,对于一个依赖具有已知漏洞的第三方库版本的应用,实际上只有在该应用直接或间接调用了第三方库暴露的函数中的漏洞代码时,才算真正存在漏洞。如果不是这样,那么就不能认为给定应用受到其所依赖的库版本中漏洞的影响。

总而言之,我们可以断言:一个给定应用只有在直接或间接使用了库中的漏洞代码时,才算对该应用所依赖的第三方库版本中的漏洞存在漏洞,而非仅仅因为依赖了该库的非漏洞代码就算存在漏洞。

这正是传统 SCA 工具所缺乏的。它们通过持续将组件版本与漏洞数据库进行匹配来不断倾泻大量问题,造成了巨大的告警疲劳。这就是为什么 SCA 问题需要重新审视。

什么是下一代 SCA

下一代 SCA 工具承诺真正解决漏洞修复问题,而不仅仅是漏洞识别。这意味着,目标不仅仅是识别并倾泻大量漏洞供安全和工程团队处理——这往往会导致告警疲劳——而是影响网络安全管理的最重要指标,即减少给定应用中的漏洞数量。

下一代 SCA 的承诺是什么

下一代 SCA 工具承诺使其真正实用。这意味着这些工具能够

  1. 通过消除无影响的漏洞来减少噪音
  2. 通过帮助修复具有实际影响的漏洞来改善结果
  3. 主动防护,防止从 OSS 引入恶意代码

引入可达性分析

传统 SCA 工具的头号问题是缺乏第一方代码上下文。将库版本与公共漏洞数据库进行匹配会导致高误报率,从而降低用户的工作效率。SCA 工具中的可达性分析正是为了解决这个问题——在识别问题时引入第一方代码上下文。

可达性是经典的编译器概念,涉及在控制流图中识别可达的基本块代码。如果基本块不可达,可以安全地消除它们,以避免不必要的机器码生成和可执行文件的膨胀。这一概念已在 SCA 工具中扩展为

识别第三方库中的漏洞函数是否可从第一方代码访问。

这是有意义的,因为第三方库中的 CVE 只有在漏洞代码在应用中可达时才会影响给定应用。可达性分析有助于消除第三方库中的无影响漏洞,从而显著减少修复这些漏洞的不必要工作。

恶意代码扫描

漏洞识别和修复的前提是"某人"确实已扫描、识别并负责任地披露了开源包中的漏洞。只要这个"假设"成立,更好的可达性分析可以改善 SCA 的问题。但漏洞代码并非唯一的问题。实际上,漏洞是由代码中的无意错误造成的。而恶意开源软件——在现实世界的软件供应链攻击中急剧增加——则是故意为之,违约可能性要高得多。故意恶意代码的问题已经使传统 SCA 的规范从查看第一方代码以获取上下文、查看公共数据库以获取漏洞信息的模式,转变为需要实际查看 OSS 代码并识别其是否存在造成危害的恶意意图。

挑战与前进方向

漏洞和恶意代码是当前 OSS 安全相关的两大问题。然而,实现这些可靠性存在多个问题。

全程序调用图

函数可达性分析需要在第一方和第三方代码(包括 OSS 库)之间构建调用图。调用图的构建是近似值,需要在多种用例之间进行权衡。构建一个精确的调用图来建模运行时所有可能的函数调用是不可能的。虽然带可达性功能的下一代 SCA 工具确实有助于优先处理可修复的可达漏洞,但通过静态分析发现不可达的严重漏洞在最佳情况下也只是近似值。在现实生活中,基于静态可达性分析保留未修复的严重漏洞并不总是一个可接受的风险。

漏洞函数签名

函数可达性分析需要获取给定 CVE 中漏洞函数的准确信息。这些信息并非总是可用的。这导致商业供应商维护可能并不总是准确的私有 enrichment 数据。

恶意代码检测

由于赖斯定理(Rice's Theorem),不可能将一个程序分类为恶意或非恶意。给定的代码是否恶意仅在上下文中才有意义。例如,在一个本应只执行计算操作的加密库中观察到的 HTTP 调用可能是恶意的。然而,同样的行为在 SaaS SDK 中则不是恶意的。

总结

总而言之,如果您正在寻找下一代 SCA 工具,请考虑以下几点

  1. 应具备代码感知能力,并在识别第三方风险时具有上下文意识
  2. 应超越 CVE 的范围,考虑 OSS 包的可信度
  3. 应超越 CVE,实际分析 OSS 代码
  4. 应能够识别 OSS 包中的恶意代码
  5. 应支持策略驱动,实现特定上下文的采用
  • sca
  • nextgen-sca
  • reachability
  • ossrisk
  • guide

来自 SafeDep 博客的最新内容

关注以获取开源安全与工程方面的最新更新和见解