SLSA 与供应链安全

• SLSA 的定位：供应链安全成熟度模型
• Build L0-L3 与 Provenance L0-L3 的对应
• 各级别的安全保证

SLSA（Supply chain Levels for Software Artifacts）是 Google 发起、OpenSSF 维护的供应链安全"成熟度模型"，通过逐级提升构建与来源（provenance）的强度来降低供应链攻击风险。SLSA v1.0 的级别（Build L0~L3）对应 Provenance（出处证明）L0~L3，每级代表不同的安全保证：Build L0（Provenance L0）——无任何保证，自由/松散构建（loose build），没有可验证的出处；Build L1（Provenance L1）——构建过程自动化，并生成可验证的出处（provenance），说明构建了哪些源码、如何构建，但来源可能不可信；Build L2（Provenance L2）——使用托管构建平台（如 GitHub Actions），出处由构建平台签名，防篡改，来源可信；Build L3（Provenance L3）——隔离构建（hermetic build，无网络依赖、封闭环境）、两步审查（two-person review）、不可参数化，防止构建被篡改或注入，且防止构建者伪造出处。级别越高，对"构建过程可信 + 出处可靠"的保证越强。SLSA 是渐进式采用的安全基准，而非一次性达标。

核心是"级别越高，构建与出处的可信度/防篡改越强"。答题要点：L0 无保证、L1 自动化+出处、L2 托管平台+签名、L3 隔离+两步审查+无参数化。它与 Provenance 级别一一对应。

• slsa-verifier 验证 SLSA provenance
• cosign 验证镜像签名与完整性
• 在 CI/CD 部署门禁中落地

SLSA provenance 的验证落地是通过"部署前校验"把供应链安全收口到 CI/CD 门禁。slsa-verifier：校验构建产物的 SLSA provenance（出处证明），验证其签名、来源仓库、构建方、构建平台，确认制品确实来自可信的构建流程且未被篡改；cosign：签名并验证容器镜像/制品的签名与完整性（Sigstore 生态），用 cosign verify 校验镜像签名、cosign verify-attestation 校验 in-toto attestation。集成方式：在 CI/CD 的"部署前门禁"阶段加入校验步骤——拉取制品后，先用 slsa-verifier 验证 provenance 的构建来源与平台，再用 cosign 验证镜像签名与 SBOM 等 attestation，全部通过才允许部署；任一校验失败则阻断部署（fail-closed）。门禁还常结合：仓库授权（只允许白名单仓库）、分支/标签校验（只允许 main/release 标签）、不可否认的签名吊销检查。这样即使上游被投毒，被篡改或伪造的制品无法进入生产。

落地关键是"部署前门禁 fail-closed"。slsa-verifier 验 provenance 来源、cosign 验签名完整性，二者结合覆盖"来源可信 + 未被篡改"。答题强调"在部署门禁中强制校验"。

• Sigstore 的目标：免费、自动化、开放的软件签名
• cosign：签名/验证工具
• Fulcio：免费短时证书 CA

Sigstore 是 OpenSSF 推出的开源软件签名与验证生态，目标是让软件签名"免费、自动化、开放"。三大组件：cosign——签名/验证工具，用于对容器镜像、二进制、文档签名（cosign sign）与验证（cosign verify），支持 keyless 签名；Fulcio——签发短时证书的证书颁发机构（CA），基于 OIDC 身份（如 GitHub/GitLab 登录）为开发者签发短期签名证书，实现"keyless"签名（无需长期密钥管理）；Rekor——透明日志（transparency log），记录签名与制品元数据，使签名可审计、可验证不可否认，任何签名都会进入 Rekor 日志实现永久留痕。整体流程：开发者用 OIDC 向 Fulcio 请求短时证书 → 用该证书对制品签名 → cosign 把签名与证书提交到 Rekor → 验证方用 cosign 校验签名、通过 Rekor 查询并验证证书。Sigstore 解决"密钥管理复杂、签名普及难"的痛点，使供应链签名可大规模落地，是 SLSA/cosign 供应链签名的核心基础设施。

核心是"keyless 签名 + 透明日志"。答题要点：cosign 签名/验证、Fulcio 短时证书（OIDC keyless）、Rekor 透明日志（审计/不可否认）。理解三者协作流程。

• provenance：制品如何构建（来源、构建过程）
• SBOM：制品包含哪些组件（软件物料清单）
• 漏洞响应与来源审计中的分工

SLSA provenance 与 SBOM 回答两个不同问题，互补而不重叠。Provenance（出处证明，SLSA）：回答"制品如何构建"——构建了哪些源码、由谁在哪个平台构建、用了哪些构建参数，用于"来源/构建可信度"审计，验证制品是否来自可信、未被篡改的构建流程。SBOM（Software Bill of Materials，软件物料清单）：回答"制品包含哪些组件"——列出制品依赖的第三方组件、版本、许可证等，用于"漏洞响应"——发现已知漏洞（CVE）时，通过 SBOM 快速定位受影响制品与升级路径。职责边界：来源审计（验证构建来源、防投毒/伪造）主要靠 provenance；漏洞响应（识别脆弱组件、评估影响、修复升级）主要靠 SBOM。两者配合：SBOM 告诉"有哪些组件可能有问题"，provenance 告诉"这些制品是否可信、从哪来"，共同支撑完整的供应链风险管理。实践中两者都生成并随制品分发、签名验证。

分工是"如何构建（provenance）vs 包含什么（SBOM）"。答题强调"来源审计靠 provenance、漏洞响应靠 SBOM、二者互补"。这是概念区分的关键题。

• 依赖投毒：恶意组件被植入
• 依赖劫持/命名混淆：恶意包冒充合法包
• 降低风险的措施

第三方依赖引入供应链风险，主要包括"投毒"与"劫持"。依赖投毒（Dependency Poisoning）：攻击者把恶意代码注入实际存在的流行包（如通过入侵维护者账号、提交恶意版本、或利用 typo-squatting 命名相似包），使开发者安装到恶意代码。劫持（Hijacking）包括：账号劫持（攻击者拿走维护者账号发布恶意版本）、包劫持（typosquatting 拼写错误包、brandjacking 仿冒包名、squatting 抢占未发布包名）、以及"依赖劫持"（lockfile 或依赖解析被篡改指向恶意源）。风险后果：恶意代码在开发者环境/CI/生产执行，导致数据窃取、凭证泄露、后门。降低风险的措施：固定依赖版本与 lockfile（锁定）、校验依赖完整性（checksum/签名）、来源白名单（只从可信源拉取）、依赖扫描（SCA 识别已知漏洞与恶意包）、审查许可证与维护者信誉、最小化依赖、监测依赖变更与流行包新增版本、使用私有镜像/代理仓库缓存可信版本。

核心区分"投毒（污染真实包）"与"劫持（冒充/抢占包）"。答题强调"锁定版本 + 完整性校验 + 来源白名单 + SCA 扫描 + 最小化依赖"。

• xZ utils 后门事件的手段（长期潜伏、社交工程、提交者信誉）
• 两阶段 review：人审 + 工具审
• 隔离构建：无网络依赖、封闭环境、防构建注入

xZ utils 后门事件（2024 年）是典型的高复杂度供应链攻击：攻击者通过多个伪装身份、长期维护贡献建立信誉，花费数月逐步植入后门（先是修 bug 建立信任，后在测试文件/构建脚本中隐藏恶意代码，最终通过 SSH 认证逻辑注入后门），利用"看似正常提交"混入主流发行版。启示：1）攻击者利用"社交工程 + 长期信誉积累"绕过单一信任，说明仅靠"提交者可信"不够；2）恶意代码常藏在"不易审查的文件"（如测试夹具、构建脚本、压缩文件）中。两阶段 review（two-person review）能拦截：要求至少两名独立审查者批准合并，降低单人恶意的单点风险；但需配合"审查者真正的审查"而非形式主义。隔离构建（hermetic build）能拦截：构建在封闭、无网络依赖、参数固定的环境中进行，不允许构建时动态拉取/执行不可控代码，使恶意代码无法在构建时通过网络下载 payload 或通过构建参数注入，且可复现。两者分别从"审查环节"与"构建环节"封堵注入点，是 SLSA L3 的核心要求。

事件启示是"信任需多方验证 + 构建需封闭可控"。答题强调"两阶段审查瓦解单点信任、hermetic 构建阻断构建期注入/下载"。与 SLSA L3 关联。

• lockfile 锁定版本并提交
• 镜像 digest 固定与扫描
• 安全与更新效率的平衡

依赖锁定与镜像锁定是供应链稳定的基础。lockfile：把依赖的精确版本（及传递依赖）锁定并提交到仓库，保证构建可复现、可审计，避免"不可控地升级到可疑版本"；更新策略是"显式、可评审的升级"——用 Dependabot/Renovate 等工具定期提出升级 PR，经 CI 与审查后合入，而非默认自动升级。镜像锁定：拉取容器镜像时固定到 digest（不可变摘要，如 image@sha256:...）而非只固定 tag（tag 可变），保证使用的镜像是验证过的那个，并配合"镜像扫描"（trivy、grype 等）在拉取/部署前扫描已知漏洞与恶意内容。平衡安全与更新效率：完全锁定会滞后安全补丁，完全开放又引入风险，因此采用"分层策略"——锁定当前版本保证可复现，同时用自动化的依赖升级机器人 + 漏洞扫描驱动"受控的及时更新"，更新经 CI 验证（测试、安全扫描）后合入；对高危漏洞设置紧急升级路径，对低危采用定期批次更新。核心是"锁定保证稳定与可审计，自动化驱动及时打补丁"。

锁定是"稳定性"，更新是"及时性"，平衡靠"自动化受控升级"。答题强调"lockfile 提交 + digest 固定 + 扫描 + Dependabot/Renovate 受控更新"。

• 可复现构建：相同输入产出相同制品
• 归一化时间戳、路径、构建顺序
• 对 provenance 验证的意义

可复现构建（Reproducible Builds）指"相同源码 + 相同构建工具 + 相同构建环境"产出"字节级相同"的制品，从而任何人都能验证制品确实由声称的源码构建而来。落地需消除构建中的"非确定性来源"：时间戳——构建嵌入的时间需归一化（固定为源码/环境提交时间，或用 SOURCE_DATE_EPOCH 环境变量固定构建时间）；路径——构建中写入的绝对路径需归一化（用相对路径或固定构建目录）；构建顺序——依赖并行/文件顺序导致的不确定性需固定（排序、固定迭代顺序）；此外还有随机数、uname、locale、压缩元数据等也要固定。可复现性对 provenance 验证的意义：它让"出处（provenance）可被独立验证"——验证方可以"复现构建"来确认 provenance 里声明的源码/构建参数确实生成了一致制品，从而验证制品来源可信、未被篡改；不可复现则无法独立验证，只能信任构建方。可复现构建是 SLSA L3（hermetic）与高强度 provenance 的重要支撑。

可复现的核心是"消除非确定性"。答题要点：固定时间戳/路径/顺序，用 SOURCE_DATE_EPOCH 归一化，意义是"可独立复现验证 provenance"。

• 引入评估：许可证、维护、安全、质量
• 漏洞应急与替换流程
• RACI 角色分配与 SLA 时限

供应链风险管理是"评估—监控—应急—替换"的闭环流程。引入评估：在新依赖进入前评估其许可证（合规）、维护活跃度（是否有人维护）、安全历史（是否常出漏洞、是否有 CVE）、质量（测试、文档）、信誉（star/下载量、是否知名组织维护）、依赖规模（新增多少传递依赖），并评估替代方案（已有依赖、自研、成熟库），形成准入清单。漏洞应急：通过 SCA 持续扫描依赖漏洞，发现高危漏洞时按"受影响程度"评估（是否受影响、是否可被利用、版本是否可升级），分优先级响应（紧急补丁/降级/临时缓解）。替换：当依赖被弃维护、漏洞无法修复或存在严重供应风险时，规划替换（评估替代、迁移、灰度、回滚）。RACI 设定：明确"负责（Responsible，如应用团队执行升级）、批准（Accountable，如安全/架构负责人）、咨询（Consulted，如安全团队）、知会（Informed，如运维）"的角色。SLA 设定：按漏洞严重度设定响应时限（如 Critical 24h 内响应、7 天内修复/缓解，High 72h/30 天，依此类推），并设定"依赖准入评估时限""升级 PR 合并时限"等。流程要文档化、可执行、纳入 CI/CD 门禁。

流程核心是"评估→监控→应急→替换"闭环 + 明确角色与时限。答题要点：引入评估维度、漏洞应急优先级、RACI 四角色、按严重度的 SLA。强调"落地到 CI/CD 与组织职责"。

• L1：自动化构建 + 生成 provenance
• provenance 内容：构建了哪些源码、如何构建
• L1 的局限（来源不可信）

SLSA Build L1 是供应链安全的最低有效级别，要求：1）构建过程自动化——构建由 CI/CD 系统自动触发，而非人工手工执行，保证构建可复现、可审计；2）生成 provenance（出处证明）——记录构建产物对应的源码、所使用的构建命令/参数、构建环境等信息，并随制品一起分发。L1 的核心价值是"建立可验证的构建出处"：即使 provenance 本身可能来自不可信构建方，但至少提供了"制品由哪些源码、如何构建"的元数据，为后续审计与升级基础。L1 的局限：provenance 不由受信任的构建平台签名，来源可能不可信，任何人都可伪造声明；没有防篡改、防伪造的保证。它适合作为"供应链安全起步"，把"构建自动化 + 出处生成"作为基础，再逐步升级到 L2（托管平台签名）与 L3（隔离构建）。

L1 是"自动化 + 出处"，但来源不可信。答题要点：自动化构建、生成 provenance、局限是"来源未签名/不可信"。理解 L1 是起点而非终点。

• L2：托管构建平台 + 签名 provenance
• 托管平台保证构建环境可信
• 签名 provenance 防篡改

SLSA Build L2 在 L1（自动化 + 出处）基础上，要求：1）使用托管构建平台（如 GitHub Actions、GitLab CI、Google Cloud Build 等受信任的 SaaS 构建服务）——构建在受信任的平台上运行，而非开发者本机或不受控环境，因为托管平台自身有审计、隔离与可信保证；2）签名 provenance——provenance 由构建平台（或持平台密钥的身份）签名，使出处可验证、防篡改，验证方可通过平台签名确认出处确实由该受信任平台生成。L2 的意义：把"来源可信"从"信任构建者"提升为"信任托管平台"，并通过签名确保 provenance 未被伪造或篡改。它比 L1 强在于：来源可追溯到受信任平台、出处签名防篡改。局限：构建环境本身仍可能受源码/依赖影响（未隔离），仍需 L3 的 hermetic 才能彻底防止构建被篡改。

L2 核心是"托管平台 + 签名出处"。答题要点：托管构建平台保证环境可信、签名出处防篡改，来源可信度提升。理解与 L1/L3 的递进关系。

• L3：隔离构建（hermetic）+ 两步 review + 无参数化
• hermetic：封闭、无网络、可复现
• 两步 review：防单点恶意

SLSA Build L3 是构建安全的最高级别，要求：1）隔离构建（hermetic build）——构建在封闭、无网络依赖、参数固定的环境中进行，构建所需依赖全部预先锁定，不允许构建时动态拉取或执行不可控代码，保证构建可复现且不被注入；2）两步审查（two-person review）——源码/构建脚本的变更必须经至少两名独立审查者批准，防止单一恶意提交者（或被盗账号）注入恶意代码；3）不可参数化（no parameterization）——构建流程不可由外部参数动态改变（如禁用构建时传入的任意参数/环境变量），防止通过参数注入改变构建行为。三者共同封堵供应链攻击的注入点：hermetic 阻断"构建期网络下载/执行"，两步 review 阻断"单点恶意提交"，无参数化阻断"通过输入参数篡改构建"。L3 使构建来源高度可信、可复现，是最高强度 provenance 的基础。

L3 是"隔离 + 两步审查 + 无参数化"三件套。答题要点：hermetic 封闭可复现、两步 review 防单点恶意、无参数化防输入注入。理解各自封堵的攻击面。

• L0：自由/松散构建
• 无自动化、无出处、不可验证
• 是成熟度模型的起点而非可接受目标

SLSA Build L0 是 SLSA 成熟度模型的起始级别，代表"无任何保证的自由构建（loose build）"：构建没有自动化（可能手工执行）、不生成 provenance（出处）、来源不可验证、可能发生在任何人本机或不可控环境。由于没有可验证的出处、没有可信的构建环境，制品无法被独立审计其来源与真实性，任何供应链攻击（投毒、伪造）都无法被检测。L0 不是"安全目标"，而是描述"现状"的基线——大多数尚未采用 SLSA 的项目都处于 L0。SLSA 模型的意义在于引导从 L0 逐步提升到 L1（自动化+出处）、L2（托管平台+签名）、L3（隔离+审查+无参数化），每上一级就增强一项供应链保证。因此理解 L0 是为了理解"为什么需要升级到更高级别"。

L0 是"无保证基线"。答题要点：无自动化、无出处、不可验证，是起点而非目标。强调它对应"自由构建"的含义。

• SLSA 是渐进式成熟度模型
• 逐级提升构建与 provenance 保证
• 用于评估与改进供应链安全

SLSA 等级是一个"供应链安全成熟度模型"，通过 L0~L3 的分级，把"软件构建与来源可信度"从"无保证"渐进提升到"高强度保证"。它既是一种"评估标尺"（衡量组织/项目当前供应链安全水平），也是一种"改进路线图"（明确每级要做什么、如何升级）。价值在于：1）把抽象的安全目标转化为可执行、可验证的分级要求（自动化、出处、托管平台、签名、隔离、审查、无参数化）；2）提供通用语言，让供应商、部署方、消费者对齐供应链安全预期；3）与 SLSA provenance、in-toto、Sigstore 等技术结合，形成可落地的供应链框架；4）渐进式采用，避免一次性高门槛，让组织从 L1 起步逐步提升。SLSA 是软件供应链安全领域事实标准之一，与 SBOM、可复现构建、cosign 等互补。

SLSA 是"成熟度模型 + 评估标尺 + 路线图"。答题要点：分级渐进、可评估、可落地、与技术生态结合。强调"渐进式而非一次性达标"。

• in-toto 的 layout 与 link 元数据
• root/delegated 密钥与信任模型
• 逐环节记录与验证（谁、何时、对什么、执行什么命令）

in-toto 是一个供应链证明框架，用于在软件交付的每个环节记录"谁在哪个环节、对哪些材料、执行了什么命令"，并进行验证。其核心元数据：layout（布局）——由供应链所有者（root）用签名密钥定义交付流程，描述各环节（步骤）及其要求，并委托（delegated）给各环节执行者的密钥；link（链接）——每个环节的执行者生成，记录该环节的输入（材料）、输出（制品）、命令与环境，用执行者私钥签名。验证时，验证方用 root 公钥验证 layout 签名与委托关系，再对每个 link 验证其签名是否匹配委托密钥、输入输出是否与布局一致、材料在环节间是否被篡改（前一个环节的输出是否等于后一个环节的输入）。这样实现"端到端可验证"：任何环节的替换或篡改都会导致验证失败。SLSA provenance 采用 in-toto 的 Statement/ResourceDescriptor 格式承载构建出处，是因为该格式是标准的、可互操作的证明载体：Statement 声明"要证明什么（subject 制品）+ 用哪种 predicate（如 SLSA provenance）"，ResourceDescriptor 描述材料的身份与摘要（digest），使构建出处能被 in-toto 生态工具统一生成、验证与互操作。

in-toto 关键是"layout 定义流程 + link 记录环节 + root/delegated 密钥授权 + 端到端验证"。SLSA 用 in-toto Statement/ResourceDescriptor 是借用其标准证明载体。答题要把战略模型与格式两个层面讲清。

• 可复现性：相同输入产出相同制品
• 来源验证：验证构建出处与来源
• 两者互补：可复现支撑独立验证

构建可复现性与来源验证是互补的供应链保证。可复现性（Reproducible Builds）：指相同源码 + 相同构建环境产出"字节级相同"的制品，它让"制品→源码"的映射可被独立验证——任何人可复现构建来确认制品确实由声称的源码生成。来源验证（provenance verification）：验证制品"来自哪里、如何构建"——校验 provenance 的签名、构建平台、来源仓库、构建参数，确认制品确实来自可信构建流程且未被篡改。两者关系：可复现性是"来源验证"的有力支撑——若制品可复现，验证方可以"复现构建"来比对，从而独立确认 provenance 声明真实，不依赖单方面信任；若不可复现，则只能信任构建方，无法独立验证。反过来，来源验证（可信构建、签名出处）保证可复现构建所用的环境与来源本身可信。工程上：可复现构建 + 签名 provenance + 独立复现比对，共同构成"来源可信、可独立验证"的供应链闭环。

关系是"可复现支撑独立验证、来源验证保证环境可信"。答题强调"可复现让 provenance 可被独立复现比对，两者构成闭环"。

• 签名：用私钥对制品生成签名
• cosign 签名/验证命令
• 与透明日志、keyless 结合

软件签名与完整性验证用于确保制品"未被篡改且来自可信来源"。cosign 是 Sigstore 的签名工具：签名时 cosign sign 用私钥（或 keyless 证书）对制品（镜像、二进制）生成签名并附加到制品；验证时 cosign verify 用公钥/证书校验签名，确认制品未被篡改且签名有效。完整性验证通过比对制品摘要（digest）与签名中的摘要一致性实现；来源验证通过校验签名证书/公钥与 Sigstore 信任链（Rekor 透明日志、Fulcio 证书）实现。keyless 模式：开发者用 OIDC 身份从 Fulcio 获取短时证书签名，签名记录进 Rekor，验证方用 cosign verify 校验证书链、通过 Rekor 查询签名，实现"无需管理长期密钥"的签名。此外 cosign verify-attestation 可验证 in-toto attestation（如 SBOM、provenance）。工程上：构建 CI 中对制品签名，部署门禁中 cosign verify 校验后再部署，形成"签名—验证"闭环。Sigstore/cosign 让签名既免费又自动化，降低采用门槛。

核心是"sign 签名 + verify 验证 + keyless（Fulcio+Rekor）"。答题要点：cosign 的命令流程、完整性（摘要比对）与来源（证书/透明日志）验证、keyless 免密钥管理。

• 锁定：依赖与镜像版本锁定
• 审计：依赖扫描、许可证、变更审计
• SBOM：组件清单与漏洞响应

供应链安全实践围绕"锁定、审计、SBOM、签名"展开。锁定：依赖用 lockfile、镜像用 digest 固定版本，保证构建可复现、可审计，避免不可控升级，是稳定性的基础。审计：持续扫描依赖（SCA）识别已知漏洞与恶意包、审查许可证合规、记录依赖变更（谁在何时改了哪个依赖）、对高速迭代的依赖做变更审计，发现并处置风险。SBOM（软件物料清单）：生成并随制品分发组件清单，列出依赖组件与版本，用于漏洞响应（发现 CVE 时快速定位、评估影响、升级）、供应链透明度与合规审计；配合签名验证 SBOM 未篡改。此外还有：来源签名（cosign/Sigstore）验证制品来源、provenance（SLSA）证明构建出处、可复现构建、最小化依赖、依赖维护者信誉评估。整套实践形成"锁定稳定 + 审计发现 + SBOM 定位 + 签名/出处验证来源"的完整供应链防线。

供应链实践是"锁定 + 审计 + SBOM + 签名/出处"的组合。答题要点：锁定保稳定、审计发现问题、SBOM 支撑漏洞响应与清单、签名验证来源。强调四者互补。

• L1：自动化构建 + 生成 provenance
• L2：托管平台 + 签名 provenance
• L3：隔离构建 + 两步审查 + 无参数化

SLSA 落地是"渐进式升级"，从 L1 到 L3 逐步增强。L1：先把构建自动化（接入 CI/CD），并引入工具生成 provenance（如 GitHub Actions 的 slsa-github-generator、slsa-framework 生成器），建立"构建出处"基础；L2：把构建迁移到托管构建平台（如 GitHub Actions 官方）并让平台签名 provenance，使来源可信、出处防篡改；L3：实施隔离构建（hermetic，封闭网络、依赖锁定、可复现）、两步审查（合并保护要求两人批准）、不可参数化（构建流程固定、禁用外部参数篡改），达到最高构建保证。落地策略：不必一次到位，按"当前风险与能力"分步推进——先从 L1 快速落地（自动化+出处，收益高成本低），再按需升级 L2（托管签名）、L3（隔离+审查）。同时配套：provenance 在部署门禁中验证（slsa-verifier/cosign）、结合 SBOM 与可复现构建、定期评估进度。关键是"渐进、可验证、纳入 CI/CD 门禁"。

落地是"从 L1 起步逐级升级"。答题要点：L1 自动化+出处、L2 托管+签名、L3 隔离+审查+无参数化，以及"渐进式、门禁验证、配套工具"。理解每级的具体动作。