下一代 SCA：流水线成分分析 - HelloWorld开发者社区

软件成分分析（SCA）是检测开源库等依赖项中漏洞的重要工具。随着现代应用程序的组成从以自定义代码为主的转变为高达70-90%的开源，管理来自第三方的依赖项的漏洞比以往任何时候的重要性都高出许多。然而现有的 SCA 解决方案专注于应用程序代码中的依赖，但它们不涵盖软件交付流水线中的许多其他依赖项，比如构建模块（如 GitHub Actions）、开发工具（如 Jenkins）、开发工具插件（如插件生态系统）等。

到目前为止，保护整个流水线包含的依赖很少受到关注。根据之前的 SolarWinds 事件发现，攻击者通过突破过时和易受攻击的构建服务器版本，从而扩大攻击的规模和影响。易受攻击的依赖无论是在应用程序的代码中还是软件交付流水线中，都能构成漏洞风险。

为了使解决方案与漏洞风险保持一致，不仅需要将依赖项的定义扩展到应用程序代码之外，还必须考虑优先级和修补。由于了解交付流水线或运行时环境在本质上限制了可使用的范围，传统的 SCA 工具目前还无法实现这些动作。

本文将会讨论 SCA 的不足之处，并探索和分析流水线成分分析（Pipeline Composition Analysis, PCA）这一概念在现代 SDLC 保护依赖的能力，以及未来趋势。

为什么 SCA 落后了？

传统的 SCA 始于2002年。从2011年到2016年，这期间的 SCA 供应商把更多重心放在将 SCA 嵌入开发人员的工作流程中，而产品核心本身是没有变化的。但与此同时， SDLC 发生了巨大的变化，随着现代开发实践的变革，对开发速度要求更高，团队也需要更紧密地合作，企业在整个开发流水线中使用了更多的工具和第三方组件。这就导致现代应用程序使用的依赖比以往任何时候都多。

而 SCA工具本身只关注应用程序代码。应用程序代码可能包含漏洞，但依赖不仅仅存在于应用程序的源代码。今天，整个软件交付流水线中通常存在易受攻击的依赖，包括：

开发工具（如Jenkins）
开发工具插件（如Jenkins插件）
构建模块（如 Github Action）
构建模块依赖（如GitHub Action libiaries）
IaC 依赖

传统的 SCA 对这些组件并不具备良好的可见性，因此无法确定它们是否易受攻击。此外，传统 SCA 无法判断易受攻击的组件部署的具体位置，甚至无法判断这些组件是否已部署。

PCA 将是 SCA 二代吗？

PCA 是一种概念上的进化和变革，重新思考 SCA 并使其适应依赖对现代开发流水线构成的实际风险。PCA 通过深入了解交付流水线每个阶段使用的工具、配置、流程、活动、组件和依赖，从而改进 SCA。

PCA 对 SDLC 本身的洞察在几个关键方面打破了 SCA 的局限性，包括依赖覆盖的广度、通过部署位置进行快速修补以及基于运行时可利用性的优先排序。

覆盖范围的广度：保护应用程序代码之外的依赖

软件依赖是应用程序所依赖的第三方编写的任何代码，现代应用程序使用的依赖的数量和种类大幅增加。除了应用程序代码中的依赖外，现代应用程序依赖还包括以下内容：

1. 开发工具

构成软件交付流水线的工具和基础设施是关键的依赖。源代码控制管理系统、构建系统、注册表、容器和云环境都是支持应用程序的第三方软件。这些工具中的漏洞是 AppSec 团队常见的漏洞来源。

2. 开发工具插件

不仅是开发工具依赖，而且许多开发工具提供的生态系统也是必须被保护的依赖。比如最近 Jenkins 宣布了数十个需要更新的易受攻击的插件。

3. 构建模块

随着 GitOps 的趋势走高，也提高了 GitHub Actions 和 GitLab Runners 等构建模块的受欢迎程度。这些是第三方代码，能够以难以捉摸的方式将漏洞引入软件供应链。

4. 构建模块引入依赖

不仅构建模块本身可能很易受攻击，而且一些构建模块还引入了其他依赖，这些依赖也需要保护。

5. IaC 引入的依赖

与构建模块一样，IaC文件还可以引入 AppSec 团队需要管理和监控的其他依赖。

快速响应易受攻击的依赖

漏洞依赖比自定义代码具有更大的风险，因为一旦常见的软件漏洞公开，漏洞利用就会随之而来，这给了攻击者可乘之机。PCA 的一个关键功能是跟踪 SDLC 所有阶段（从代码到云）依赖的部署路径。PCA 不仅可以确定哪些依赖易受攻击，还可以确定其是否已经部署以及部署到对应位置。

鉴于 Log4Shell 事件，快速响应新的易受攻击的依赖显得至关重要，但这并不是件简单的事，因为修复根本问题常常需要多次更新。需要明确的是，确切了解易受依赖的部署位置，对于提高应用修复的速度和确保所有易受攻击实例被修复都非常重要。虽然传统的 SCA 能够在源代码中找到缺陷，但在确定漏洞部署到生产中的位置存在盲区。

优先级：运行时中的可利用性

修补速度至关重要，但并不是所有的漏洞都可以在部署它们的每个运行时环境中被利用。开发人员时间很宝贵，因此了解依赖是否可以在部署的运行时环境中被利用也格外关键。

虽然 Log4Shell 是需要快速修补的漏洞的例子，但 Spring4Shell 是大多数生产环境中可能不需要修复的漏洞的一个例子。为了利用 Spring4Shell，运行时环境必须包括：

JDK 9 或更高
Apache Tomcat 作为 servlet 容器
作为传统 WAR 打包，并部署在独立的 Tomcat 实例中（使用嵌入式 servlet 容器或响应式 Web 服务器的典型 Spring Boot 部署不受影响）
spring-webmvc 或 spring-webflux
Spring Framework版本5.3.0至5.3.17、5.2.0至5.2.19及更早版本

Spring4Shell 的复杂可利用性凸显了了解构成运行时环境的所有组件的重要性。由于很少有组织修复过所有漏洞，因此确定优先级是降低 AppSec 风险的关键。