共计 2529 个字符，预计需要花费 7 分钟才能阅读完成。
软件成分剖析（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 危险的要害。
总 结
PCA 代表了下一代 SCA。它有着弱小的平安洞察力，是软件供应链平安平台的支柱。与未能思考整个部署流水线的工具相比，企业可能很大水平受害于 PCA，通过应用 PCA 作为在整个开发流水线中检测和修补破绽的伎俩，SDLC 更加平安，开发人员效率更高。
参考链接：
https://cycode.com/blog/multi…
https://www.cisa.gov/uscert/a…
https://cycode.com/blog/pipel…