开源项目SLSA等级达标了吗

本文目录导读：

1. 明确“达标”的定义
2. 主流开源项目的达标现状（截至 2025 年 5 月）
3. 如何自己判断一个项目是否达标？
4. 常见误区
5. 结论建议

这是一个非常专业且具有时效性的问题,要给出准确的“达标/未达标”必须明确具体是哪个开源项目（Kubernetes、curl、npm CLI 等），以及你关心的是 SLSA 的哪个等级（L1、L2、L3、L4）。

简而言之：目前只有极少数顶级关键基础设施项目达到了 L3/L4 级别（如 Tekton、Sigstore），大多数主流开源项目仍在向 L1/L2 努力，很多知名项目甚至尚未达标。

以下是详细的分析和判断标准,帮助你自行评估或理解现状：

明确“达标”的定义

SLSA（Supply-chain Levels for Software Artifacts，软件供应链级别）是一个安全框架，共 4 个等级，要求逐级递增。

• L1（基础）： 构建过程必须可重复（例如使用脚本而非手动操作）。
• L2（增强）： 使用版本控制 + 托管构建服务（如 GitHub Actions、GitLab CI）。
• L3（严格）： 构建平台无访问权限（防止篡改）+ 生成并验证不可否认性来源（签名）。
• L4（最高）： 双人审计 + 完全可复现构建 + 硬件信任根。

“达标”在不同语境下含义完全不同。 一个项目可能满足 L1，但远未达到 L4。

主流开源项目的达标现状（截至 2025 年 5 月）

• 达到 L3/L4 的典型代表：

  • Tekton（SLSA L3）： 作为构建工具，其自身严格遵循 SLSA 规范。
  • Sigstore（SLSA L3）： 提供了签名基础设施，自身安全等级较高。
  • Angular CLI（L3）： 使用了受控构建环境。
  • Kyverno（L3）： 云原生策略引擎。
  • 部分 CNCF（云原生计算基金会）毕业项目： 如 Helm、Flux 等正在积极达标。

• 尚未达标或处于低水平的典型代表（情况变化较快）：

  • Kubernetes（核心项目）： 其构建过程非常复杂，虽然努力多年，但仍未正式通过 L3 认证，部分子项目（如 kubernetes/release）可能达标，但核心二进制的来源声明仍在改进中。
  • curl： 主要依赖手动或半自动发布流程，未达到 L2+，但社区正在计划改进。
  • Node.js： 构建过程复杂，尚未正式发布 SLSA 等级声明。
  • OpenSSL： 虽然安全审计严格，但构建溯源（SLSA）方面起步较晚，可能处于 L1 或 L2 边缘。
  • 大多数 npm/GitHub 上的流行库： 即使使用 GitHub Actions，如果不使用 actions/attest-build-provenance 创建并签名来源，仅能达到 L1 或 L2（无签名）。

如何自己判断一个项目是否达标？

不要依赖口头宣传,使用以下官方推荐的方法：

查看 SLSA 验证器输出 使用 Google 开发的 slsa-verifier 工具（如果该项目发布了 SLSA 证明）：

slsa-verifier verify-artifact --source-uri <GitHub_URI> --source-tag <vX.Y.Z> <artifact>

如果验证成功,会显示类似 PASSED: Verified SLSA level 3 的信息。

检查项目发布页面

• 去 GitHub Releases 或官方网站。
• 寻找 attestations（证明）区域，如果发布时附带了一个 attestation.intoto.jsonl 文件或 .sigstore 签名，说明至少达到了 L2+。
• 检查其 build.yaml 或 CI 配置文件，若使用 actions/attest-build-provenance 或 sigstore/cosign 进行签名，则是积极信号。

查看 SLSA 官方数据

• SLSA Level Map： 社区维护了部分项目的达标状态（查看 https://github.com/slsa-framework/slsa/blob/main/docs/levels.md 或相关 Issue）。
• OpenSSF Scorecard： 运行 ossf/scorecard-action 会检查项目的 SLSA 实践（如 Pinned-Dependencies（固定依赖）、Token-Permissions（权限限制）等，这些是 SLSA 的组成部分）。

常见误区

• 用 GitHub Actions L2。
  • 真相： 只有当你使用预先配置好的、受信任的构建器（如 slsa-github-generator），并且生成的产物附带了经过签名的、不可否认的来源（Provenance）时，才算 L2+，仅运行 npm run build 不算。
• 发布到官方 Registry（如 npm、Docker Hub）就是安全的。
  • 真相： 这些 Registry 不验证 SLSA，攻击者可以上传伪造包（如 lodash 的恶意版本）。
• L4 才是目标。
  • 真相： 对于绝大多数项目，达到 L3 已足够（阻止 90% 的供应链攻击），L4 成本极高，通常只用于必须完全防篡改的软件（如加密库）。

结论建议

1. 如果你是用户： 优先选用已明确声明 SLSA L3+ 且经过 slsa-verifier 验证的项目，对于关键基础设施（如 TLS 库、容器运行时），请务必检查其版本对应的来源证明。
2. 如果你是维护者： 建议从 L1 开始（固定 CI 步骤、记录来源），然后利用 slsa-github-generator 或 actions/attest-build-provenance 快速达到 L2/L3，这是当前提升项目安全性的最高优先级任务之一。
3. 如果你在评估“是否达标”： 最严谨的方式是运行验证工具，仅凭文档或口头承诺并不可靠。

目前阶段，你可以预期 90% 的开源项目在 SLSA 方面是不达标的（尤其是 L2 以上），但这是一个快速改善的领域，那些最受依赖的项目正在尽快达标。