多年来，攻击者一直逐个攻击应用程序。如今，他们的策略发生了改变：既然可以攻击多个应用程序，为什么还要攻击单个应用程序呢？ pipeline 建造了很多？Xygeni 的 恶意软件预警 (MEW) 检测 2025年将出现4,452个恶意软件包 以及 截至目前，2026年还将新增1,281个。过去几年发生的每一起备受瞩目的软件安全事件都波及到软件交付链中的不同环节：
- 太阳风 (2020)：构建环境妥协；向 18,000 名客户推送了带有后门的更新。
- Codecov（2021）：配置错误的 Docker 镜像让攻击者能够修改 bash 上传脚本，从而窃取超过 23,000 名客户的 CI 机密信息。
- CircleCI（2023）一名工程师笔记本电脑上的会话 cookie 被盗，导致生产访问令牌泄露；所有客户都被告知要轮换使用每个密钥。
- XZ Utils 后门 (2024) 一场持续多年的社会工程攻击活动，几乎波及了所有 Linux 发行版。
- tj-actions (2025) — GitHub Actions 供应链级联事件导致 23,000 多个存储库使用的组件受到污染。
- 进攻 Aqua Trivy 以及 Checkmarx (2026) TeamPCP 行动将两款广泛使用的安全扫描器变成了攻击载体，然后利用窃取的扫描器进行攻击。 CI/CD 将凭据向下传递到 npm、OpenVSX 和 PyPI。
每次攻击都利用了不同的部分 pipeline构建环境、CI 工具、依赖项、开发人员凭证、维护者信任、对工件的可变引用。大多数组织会采取以下措施：点控制、在 CI 中使用扫描器、在身份提供商 (IdP) 上启用双因素身份验证 (2FA)、分支保护。 main通常缺少的是一种提问的方式。 我们的系统性保障是否到位？ 而非 上次事件发生后，我们是否记得启用 X 功能？
应用安全厂商正处于风口浪尖，一旦其产品遭到破坏，所有信任其产品的客户都将受到影响。从被动控制转向系统性防御的压力并非纸上谈兵，而是迫在眉睫的现实。cis是什么促使您采用 OWASP SPVS standard 作为首要任务项目。
SPVS是什么，以及为什么其结构很重要
起源故事很简单。在2023年的LASCON大会上，Farshad Abasi和Cameron Walters一直在互相问同一个问题：ASVS在哪里？ pipelineOWASP ASVS 为应用程序安全提供了全面、可验证的评估方法。 standard不存在类似的东西 CI/CD.
还有OWASP Top 10 CI/CD Risks 侧重于提高风险意识，但无法进行测试；SLSA 仅关注构建溯源；S2C2F 仅关注依赖项消耗；以及 OpenSSF 评分卡涵盖了具体的存储库检查项目。每个项目只检查了一部分，没有一个项目涵盖了全部内容。
| 框架或项目 | 主要范围 |
|---|---|
| OWASP顶级10 CI/CD 风险 | 意识导向 CI/CD 风险指导，而非可测试的验证 standard. |
| 萨尔瓦多 | 构建溯源和工件完整性。 |
| S2C2F | 安全依赖项消费。 |
| OpenSSF 记分卡 | 特定的存储库级别安全检查。 |
差距： 每个框架都涵盖了重要的部分 software supply chain security但没有一个方案能够提供端到端、可验证的方案。 standard 整个 CI/CD pipeline.
那次对话最终演变成两年的工作，2025 年 1.0 月，SPVS 工作组发布了 v1.0 版本：涵盖生命周期（规划、开发、集成、发布、运营）的 127 项要求，并分为三个成熟度级别：L1 基础级、L2 高级。 Standard以及 L3 高级认证。每一项要求都与 NIST SP 800-53 和 OWASP 标准相对应。 CI/CD 前十名，以及CWE。
结构才是关键。用SPVS作者自己的话说：
请核实您的全部信息 pipeline不仅仅是某个组件。这正是大多数组织面临的难题。他们扫描依赖关系，却忽略发布治理。他们签署工件，却不进行威胁建模。 pipeline 建筑设计。他们监控生产过程，但不监控建造环境。
这是大多数组织面临的难题。他们会扫描依赖关系，却忽略发布治理；他们会签署工件，却不进行威胁建模。 pipeline 架构。他们监控生产环境，但不监控构建环境。
这就是证明这项工作合理性的论点。一个阶段的优势并不能弥补另一个阶段的劣势。攻击者只需要破坏一个环节即可。生命周期 standard 它强制你检查所有项目，而从 L1 到 L2 再到 L3 的循序渐进的学习方式让你无需费力就能完成。SPVS 并不会取代 SLSA、S2C2F、Scorecard 或 Sigstore；它只是为你提供了一个框架，告诉你每个工具的适用位置。
适应 Standard 致贵组织
自然而然的第一步是直接对照每一项要求对您的组织和软件基础设施进行审核。一份来自官方的 Google 表格。 SPVS 要求 CSV 可以作为很好的起点。三种视图很有用：包含每个控件的状态和所有者的需求矩阵、每个存储库的热力图以及 dashboard 按阶段和层级推进进度。产出结果自然而然地融入技术路线图，这是一份动态文件，涵盖从计划到运营的每个阶段。
大多数成熟的工程组织在进行初步架构映射时，都会发现自己已经处于 L2 级别左右。这实际上是一个有利的位置：这意味着第一阶段可以专注于弥补具体的差距，而不是从零开始构建基础。
然而，电子表格只是快照，而SPVS要求的信息更多。V1.1.7强制要求对版本控制系统（VCS）管理员进行季度审计；V5.1.1至V5.1.3增加了定期用户审计、访问日志审查和特权访问监控；V2.1.x、V3.3.x和V4.2.x的多个控制项要求持续维护工作流YAML文件。如果全公司手动执行这些工作，每个季度就需要花费半天时间进行点击跟踪，而且极易出现疏漏。这类工作要么会被自动化，要么只有在发生严重问题后才会进行审查。
某些SPVS控制措施并非一次性检查清单项目。它们需要定期审查、审计证据以及跨存储库、用户、工作流程和特权访问的偏差检测。
| SPVS区域 | 需求类型 |
|---|---|
V1.1.7 |
对版本控制系统管理员进行季度审计。 |
V5.1.1–V5.1.3 |
定期进行用户审计、访问日志审查和特权访问监控。 |
V2.1.x, V3.3.x, V4.2.x |
持续进行工作流程 YAML 清理。 |
答案是构建或采用以组织所有者身份运行的工具，并生成结构化的季度包：管理员名册、分支保护、CODEOWNERS 覆盖范围、带有固定操作的工作流 YAML 规范、显式权限。 pull_request_target 门控、成员双因素身份验证、已安装的 GitHub 应用和部署密钥。过去需要半天时间才能完成的电子表格挖掘工作，现在只需一条命令即可生成 JSON 和 Markdown 格式的文件。季度审查 CISO 和组织管理员成为一个 decis这是一场讨论会议，而不是数据收集会议，可操作的调查结果会变成积压问题，并根据严重程度制定服务级别协议 (SLA)。
包含已批准管理员、已批准应用以及按功能划分的存储库和工作流权限的允许列表策略，应以 YAML 格式存储在版本控制的存储库中，并由安全团队通过 PR 审核进行控制。任何允许列表的更改都会留下审核记录，从而自动生成审计证据。这样做可以将原本具有愿景意义的控制措施（例如“我们应该每季度进行一次审计”）转化为例行控制措施（例如“本季度的审计已于周一完成”），并为组织提供一个可重复的机制，以检测端到端原则所要求的偏差。
你应该预料到的摩擦
技术控制是容易的部分，难的是人。
最突出的例子几乎总是 CODEOWNERS。添加 .github/workflows/ @your-org/security 在每个代码仓库都进行安全审查听起来似乎微不足道，只不过是一个文件，一行代码而已。但这意味著多年来一直自行合并工作流程变更的工程师们现在需要接受安全审查。即使是那些安全意识很强的人也会反对：这个工作流程是我写的，我理解它，为什么还要等？
真正的对话对于弄清原因至关重要。工作流程可能导致凭证泄露、重定向工件，并损害下游用户。多一双眼睛进行审核并非出于不信任，其逻辑与对生产数据库变更进行四眼监控相同。如果能找到一个具体的、近期发生的供应链事件作为参考，无论是来自行业还是自身环境，都将大有裨益。没有什么比一个真实的案例更能凸显控制措施的缺失。
其他摩擦也遵循相同的形状：
- 明确权限： 工作流中的阻塞会导致持续集成失败，直到贡献者理解了权限范围。这不是权限问题，而是认知模型问题。
- 标签不可更改性： 破坏了多年来一直在悄悄重新标记的发布工具。
- 签名 commits: 在所有工作站上正确设置 GPG 或 SSH 密钥之前，会造成用户注册过程中的不便。SPVS 强制要求每个代码库和贡献者（而不仅仅是主要代码库和贡献者）都必须进行此操作。
- 替换传统个人访问令牌： 涉及多个存储库和工作流程文件，几乎影响到每个团队。
行之有效的模式是：针对每项控制措施，分别引入它所拦截的特定威胁；在一两个代码库中进行试点；逐步推广，并设置例外规则；最后，按照既定的时间表逐步取消这些例外规则。那些最初反对最激烈的工程师，一旦理解了其中的道理，往往会成为最坚定的支持者。
更深层次的一点是：端到端原则在这里至关重要。你不能选择性地执行某些措施。如果只加强构建阶段而放松发布管控，会给人一种虚假的自信，而这正是SPVS作者所指出的失败模式。每个阶段都必须协同推进，即使单独来看，某个控制措施似乎过于繁琐。
成本权衡： 第一阶段大约耗时一个月，主要针对小型组织的L2合规性，涉及DevOps、安全和工程审核人员。这项投资很容易获得回报。一次供应链事故的预防就能带来数倍的收益。规模更大的组织应该按比例增加预算，但分阶段的L1-L2-L3结构意味着在项目完成之前就能产生价值。
接下来是什么？
SPVS v1.5 即将推出，其中包含与人工智能相关的控制功能：人工智能辅助代码的溯源； guardrails 对于调用 LLM 的 CI 工作流程，审查 AI 生成的跟踪记录 pull requests以及针对新兴威胁（例如域名抢注，攻击者注册的软件包名称会被人工智能编码助手错误地复制）的防御措施，还有 CrowdStrike 报告的在实际环境中出现的由人工智能生成的恶意软件。已经标记人工智能辅助程序的组织 commit内部开发指南中的 s 和 PR 会发现这种调整是渐进式的，而不是一项新的工作计划。
预计 2.0 版本将深化运行时监控和凭证生命周期要求。合理的组织路线图：在 2026 年第二季度末之前弥补剩余的 L3 差距，包括 SLSA provenance 融入 standard CI/CD手动设置生产部署的门禁，并采用集中式身份提供商，然后切换到维护模式。每个新存储库都以合规性为准，每个季度的审计都能及早发现偏差。
衷心感谢 Farshad Abasi、Cameron Walters 和 OWASP SPVS 工作组。像这样的项目降低了所有希望系统性而非被动地开展供应链安全的组织的门槛。
关键精华
以下几点可以推广到我们特定的语境之外：
- 不妨试试： 下载 SPVS 要求 CSV 文件，并在电子表格中映射您当前的控制措施。一天之内您就能知道是否符合要求。
- 选定一个目标级别并全力以赴，然后再去追求下一个目标。 L1 到 L2 到 L3 是一项功能，而不是限制。
- 此 pipeline 是目标。 以应用为中心的控制是必要的，但还不够；处理 pipeline 作为一流的攻击面。
- 核实全部内容 pipeline一件也没有。 强大的依赖项扫描能力并不能弥补薄弱的发布管理或缺乏监控的构建环境。
- 电子表格反映的是快照；而漂移是持续不断的。 构建自动化系统，哪怕只是一个简易的内部工具，也能检测审计结果之间的偏差。
- 组织工作比技术工作更难。 预留时间进行对话和试点，然后再进行推广，并解释每个控制措施所阻止的具体威胁。
阅读更多
- 开放式安全计划： 安全消息传递 Pipeline 企业验证 Standard （SPVS）v1.0OWASP 项目页面。
- 法沙德·阿巴西： 我们为什么创建 OWASP SPVSOWASP SPVS 文章。
- 法沙德·阿巴西： Pipeline 攻击事件愈演愈烈。以下是如何做好准备。OWASP SPVS 文章。
- 法沙德·阿巴西： OWASP SPVS 与其他供应链框架的比较OWASP SPVS 文章。
- 开放式安全计划： 前10名 CI/CD 安全风险OWASP 项目页面。
- SLSA： 软件工件的供应链级别. slsa.dev。
- OpenSSF: 记分卡. securityscorecards.dev。
