📚 课程目录第1章课程导论与核心概念

一、课程导论与核心概念：什么是软件证明保障？为什么需要它？核心术语（SBOM、SLSA、Sigstore）概览

1.1 从一次真实的供应链事故说起

2019 年，SolarWinds 的构建系统被入侵。攻击者往合法更新里插了后门，全球 18000 多家客户中招。我那时候正好在帮一家金融机构做安全审计，客户问我：「我们用的第三方库，到底安不安全？」

说实话，我当时答不上来。因为没人能证明——从源码到构建、从构建到分发，中间到底发生了什么。代码是谁写的？谁编译的？有没有被篡改过？这些信息全是黑盒。

这就是我们今天要聊的：软件证明保障（Software Provenance Assurance）。

1.2 什么是软件证明保障？

说白了，就是给软件生产全流程做「证据链」。你想想看，刑事破案要讲证据链——谁在什么时间、什么地点、做了什么。软件也一样：

源码是谁提交的？
构建是在哪个环境跑的？
依赖的第三方库有没有被改过？
最终发布的制品是不是从那个构建产物来的？

这些信息如果能被可验证地记录下来，就叫软件证明保障。我个人的理解是：它让「信任」从「我信你」变成了「我能查你」。

核心定义：软件证明保障是指通过可验证的元数据，记录软件制品从源码到分发的完整生命周期，确保每个环节的完整性、真实性和可追溯性。

1.3 为什么我们需要它？

原因其实就三个字：不信任。

传统软件供应链是「隐式信任」——你从 npm 装个包，默认相信这个包没问题。但现实呢？

2021 年，一个叫 ua-parser-js 的 npm 包被植入挖矿脚本，影响了几百万个项目。
2022 年，node-ipc 的作者故意往包里写了个删文件的逻辑，只因为他不喜欢某个国家的用户。
2023 年，PyPI 上发现了大量「依赖混淆」攻击，恶意包名字跟官方包只差一个字母。

这些攻击的共同点是什么？你没法证明你拿到的包，就是作者当初写的那个包。

我曾经帮一个团队做事后复盘，他们被供应链攻击坑了三个月才发现。原因很简单：没人记录构建时用了哪些依赖，也没人验证依赖的哈希值。说白了，整个流程是「裸奔」的。

避坑指南：我曾经见过一个团队，把 SBOM 当成「合规交差」的工具——生成一份扔给客户就完事了。结果出事之后，那份 SBOM 里连依赖版本号都是错的。记住：证明保障不是用来「交作业」的，是用来「救命」的。

1.4 三个核心术语：SBOM、SLSA、Sigstore

要落地证明保障，有三个工具你绕不开。我按「记录什么、怎么验证、谁来签名」这个逻辑来介绍。

1.4.1 SBOM：软件物料清单

SBOM（Software Bill of Materials）就是一份「成分表」。你买瓶饮料，包装上会写配料、营养表。软件也一样——SBOM 列出了制品里包含的所有组件、版本、许可证、依赖关系。

我习惯把 SBOM 分成两类：

类型	说明	常见格式
源码级 SBOM	记录源码仓库中的依赖	CycloneDX JSON
构建级 SBOM	记录构建产物中的依赖（含传递依赖）	SPDX, CycloneDX

举个例子，你用 npm 装了个 express，SBOM 会告诉你：

{
  "bomFormat": "CycloneDX",
  "components": [
    {
      "name": "express",
      "version": "4.18.2",
      "purl": "pkg:npm/express@4.18.2",
      "licenses": ["MIT"]
    },
    {
      "name": "body-parser",
      "version": "1.20.1",
      "purl": "pkg:npm/body-parser@1.20.1",
      "licenses": ["MIT"]
    }
  ]
}

小技巧：生成 SBOM 不是一次性工作。我建议每次构建都自动生成一份，并跟制品一起归档。这样万一出事，你能快速定位「哪个版本用了哪个依赖」。

1.4.2 SLSA：供应链安全等级

SLSA（Supply-chain Levels for Software Artifacts）是一套安全等级标准。它把供应链安全分成 L1 到 L4 四个等级，等级越高，证明越强。

等级	要求	我见过的典型场景
L1	有构建流程，能生成 SBOM	大部分开源项目都停在这
L2	构建过程有版本控制，使用托管构建	企业内部 CI/CD 基本能达到
L3	构建过程可复现，有防篡改的 provenance	Google、Microsoft 的核心项目
L4	完全可复现构建，双人审计	安全敏感项目（如加密库）

我个人的建议是：先做到 L2，再往 L3 努力。L4 的成本太高，不是所有项目都值得。

1.4.3 Sigstore：签名与验证基础设施

SBOM 记录了「有什么」，SLSA 定义了「多安全」，那谁来保证这些记录没被篡改？

答案是：签名。

Sigstore 就是一套开源的签名基础设施。它解决了传统 PGP 签名的痛点——密钥管理太麻烦。Sigstore 的核心思路是：

用 OIDC 身份（比如 GitHub 账号）代替长期密钥
签名后把证据存到公共透明度日志（Rekor）
任何人都可以验证签名是否有效

一个典型的 Sigstore 签名命令长这样：

# 签名
cosign sign-blob --key azurekms://mykey myfile.txt

# 验证
cosign verify-blob --key azurekms://mykey --signature myfile.txt.sig myfile.txt

一句话总结：SBOM 告诉你「里面有什么」，SLSA 告诉你「有多可信」，Sigstore 告诉你「谁签的、有没有被改过」。

1.5 三者如何协同工作？

光讲概念不够，我们来看一张图。这张图展示了从源码到部署的完整证明链：

你看，这三个东西不是孤立的。SBOM 告诉你「用了什么」，Provenance（SLSA 的核心产物）告诉你「怎么做的」，Sigstore 告诉你「谁签的」。三者合在一起，才构成完整的证明链。

1.6 一个简单的落地场景

假设你维护一个 Java 微服务。你想做到 L2 级别的证明保障，流程大概是：

构建时：用 Maven 插件生成 CycloneDX 格式的 SBOM
构建后：用 cosign 对 JAR 包和 SBOM 分别签名
发布时：把签名后的制品和 SBOM 一起上传到制品仓库
部署前：验证签名是否有效，SBOM 是否完整

我当年第一次跑通这个流程时，心里只有一个感觉：终于能睡个安稳觉了。因为我知道，就算出事了，我也能拿出证据——「这个包确实是从我的 CI 出来的，没被人动过」。

我的建议：别想着一步到位。先选一个项目试点，跑通 SBOM + 签名。等团队习惯了，再慢慢往 SLSA L3 推进。我见过太多团队一上来就想搞 L4，结果搞了半年连 SBOM 都没生成出来。

1.7 本章小结

这一章我们聊了：

软件证明保障是什么——说白了就是给软件生产做「证据链」
为什么需要它——因为隐式信任已经不可靠了
三个核心术语：SBOM（成分表）、SLSA（安全等级）、Sigstore（签名基础设施）