SEO / GEO 工作自动化部署与实践规范（三十七）：Software Supply Chain / Artifact Identity / SBOM / Provenance / SLSA / Dependency Trust / Signed Build / Admission Control / Runtime Attestation——让生产系统只运行被批准、可验证、未被替换的软件

创作日期：2026年10月3日

第（三十六）篇，我们已经建立了一条完整的执行因果链：

Original Intent
↓
Verified Identity
↓
Delegation
↓
Decision
↓
Capability
↓
Signed Context
↓
Deputy Authorization
↓
Execution
↓
Verified Effect

它能够回答：Who requested this? Who executed this? On whose behalf? Under which authority? Because of which intent? With which payload?

但生产系统中仍然存在一个没有解决的问题：

真正执行这些操作的，究竟是哪一份软件？

例如 publisher-agent 身份验证完全正确，Capability 也完全正确，Intent 没有被篡改，Credential 也是短期 Credential。

但 publisher-agent binary 已经被替换；或者 GitHub Action 被上游供应链植入恶意代码；或者 npm dependency 在下一次 Build 时解析到了另一个版本；或者 Docker image tag 仍然叫 seo-publisher:latest，但实际 Digest 已经改变；或者 WordPress Plugin 文件已经被修改。

于是即使：

Identity = Valid
Authorization = Valid
Intent = Valid

最终运行的软件仍然可能：

NOT THE SOFTWARE
WE APPROVED

这就是第（三十七）篇真正要解决的问题：

Software Supply Chain Integrity

进一步说：

How do we prove that the software performing an authorized action is the software we actually approved?

一、Workload Identity 证明“谁在运行”，Artifact Identity 证明“运行的是什么”

第（三十五）篇重点建立 Workload Identity，回答 Who is this running workload?

第（三十七）篇进一步增加 Artifact Identity，回答 Exactly which software artifact is this workload running?

Workload Identity
≠
Artifact Identity

一个合法的 Workload Identity，仍然可能运行一个已经被替换的 Artifact。

二、真正成熟的生产身份应该连接两者

Runtime Identity
↓
Artifact Digest
↓
Build Provenance
↓
Source Revision

这样 Who is running? 和 What is running? 才能被放进同一条证据链。

三、软件供应链不是简单的“源码 → 部署”

Source Code
↓
Dependencies
↓
Build Workflow
↓
Build Platform
↓
Build Tools
↓
Artifact
↓
Registry
↓
Deployment
↓
Runtime

任何一层出现异常，最终 Production Runtime 都可能和开发者看到的源码不同。

四、因此攻击面也不是一个点

Source Compromise
Dependency Compromise
Build Script Compromise
CI/CD Compromise
Build Platform Compromise
Artifact Substitution
Registry Compromise
Deployment Substitution
Runtime Replacement

这就是 Software Supply Chain Risk。

五、传统 Code Review 只能覆盖其中一部分

PR reviewed → merged，只能说明 some source change was reviewed。

它不能自动证明 production binary was actually built from that reviewed commit。

六、所以必须建立 Source-to-Artifact Chain

Approved Source Revision
↓
Verified Build Process
↓
Artifact
↓
Artifact Identity

七、第一个基础概念：Artifact Identity

对于软件制品，真正稳定的身份通常不应该只是 name / version / tag / filename，而应该至少包含 cryptographic digest。

sha256:
07d8...

八、为什么名字不能成为 Artifact Identity？

因为 seo-publisher:v1 可以指向今天的 Artifact A，未来又被重新指向 Artifact B。

同样 latest 天然表达的是 whatever is latest now，而不是 the exact artifact we approved yesterday。

九、所以应该建立一个基本原则

Mutable Label
≠
Immutable Artifact Identity

十、真正的 Deployment Target 应尽可能绑定 Digest

image:
registry.example.com/seo-publisher@sha256:abc...

而不是只使用：

image:
registry.example.com/seo-publisher:latest

十一、这就是 Artifact Pinning

Approved Artifact
↓
Digest
↓
Deployment

如果 Artifact 内容发生变化，Digest 也会变化。

十二、但 Digest 只能回答“文件有没有变”

它不能回答：Who built it? From which source? Using which build process? Which dependencies? On which build platform? Was that build authorized?

于是进入：Provenance

十三、Provenance 是软件供应链中的“出生证明”

SLSA 将 Provenance 用于说明一个软件制品 what built it、how it was built、what inputs were used 等信息。SLSA Build Track 的核心目标，是让消费者能够把 Artifact 的实际 Provenance 与预期 Provenance 进行比较，从而判断这个 Artifact 是否按预期构建。

十四、一个简化 Build Provenance 可以包含

{
  "artifact_digest": "sha256:...",
  "source_repository": "repo-x",
  "source_revision": "commit-abc",
  "builder": "github-actions",
  "workflow": "deploy.yml",
  "build_started_at": "...",
  "build_finished_at": "...",
  "dependencies": [
    "..."
  ]
}

十五、Provenance 和普通 Build Log 完全不同

Build Log 是 something happened。

Provenance 是 structured claim about how this artifact was produced。

Build Log
≠
Build Provenance

十六、Provenance 还需要能够验证

如果任何人都可以创建 source=trusted-repo / builder=trusted-builder，那么它只是文本。

所以必须进一步加入：

Issuer Identity
+
Signature
+
Trust Policy

十七、这就进入 Attestation

Attestation 可以理解为：

An authenticated claim
about an artifact
or supply-chain event.

十八、Attestation 不只可以表达 Provenance

还可以表达：

SBOM
Test Result
Vulnerability Scan
Policy Verification
Source Verification
Build Provenance
Deployment Approval

十九、所以 Attestation 是更大的容器概念

而 Build Provenance 可以作为其中一种 Predicate。

二十、in-toto 提供了供应链 Attestation 的重要基础

in-toto 的核心目标之一，是验证软件供应链中的任务是否按照计划、由被授权主体执行，并且中间产物没有在传输过程中被替换。

传统 in-toto 模型通过 Layout + Signed Link Metadata 描述供应链步骤及各步骤产生的证据。

二十一、因此可以把 Build 看成一系列可验证步骤

Checkout
↓
Install Dependencies
↓
Compile
↓
Test
↓
Package
↓
Sign
↓
Publish

每一步都可以产生 Attestation。

二十二、这会形成 Supply Chain Evidence Graph

Node：

Source Revision
Dependency
Workflow
Builder
Artifact
SBOM
Signature
Attestation
Deployment
Runtime

Edge：

BUILT_FROM
DEPENDS_ON
PRODUCED_BY
SIGNED_BY
ATTESTED_BY
DEPLOYED_AS
RUNNING_AS

二十三、第二个重要概念：SBOM

SBOM，也就是 Software Bill of Materials，回答：这份软件里面到底包含哪些组件？

application
├── package A
├── package B
│   ├── package C
│   └── package D
└── package E

二十四、SPDX 是目前重要的 SBOM 标准之一

SPDX 已成为 ISO/IEC 5962:2021 国际标准；SPDX 官方目前列出的 Current Version 为 3.0。

二十五、CycloneDX 是另一个重要 BOM 标准体系

CycloneDX 的 Object Model 可以描述 Components、Services、Dependencies 以及更多软件和系统透明度信息；其用途已经远不止最初意义上的依赖清单。

二十六、因此 SBOM 的核心价值是 Inventory

What is inside
this artifact?

二十七、但 SBOM 不能证明 Artifact 是可信的

SBOM Exists
≠
Artifact Trusted

二十八、一个恶意 Artifact 完全可以拥有一份正确 SBOM

SBOM 可以非常准确地告诉你它包含哪些组件，但它仍然可能是恶意 Artifact。

二十九、所以 SBOM 解决的是 Transparency

不是 Authorization，也不是 Integrity，更不是 Trust。

三十、签名解决的则是另一个问题

数字签名主要帮助回答：

Was this artifact
signed by
the expected identity?

Has the signed content
changed?

三十一、但 Signed ≠ Safe

即使 Signature Valid，也可能只是证明 the attacker successfully used a compromised signing identity。

三十二、因此不能建立 Signed → Trust Everything

三十三、应该建立

Signature
+
Signer Identity
+
Provenance
+
Policy
+
Artifact Digest

共同判断。

三十四、Sigstore 解决的正是现代软件制品身份与签名问题的一部分

Sigstore 的 keyless signing 模型可以通过 OIDC 身份获得短期签名证书，并使用临时密钥完成签名；Cosign 则可以用于签名和验证 Container Image、Blob 以及 Attestation。Sigstore Public Good Instance 还通过 Rekor Transparency Log 记录签名事件。

三十五、这和第（三十五）篇 Secretless Identity 架构非常相似

传统签名：

Long-lived Private Signing Key
↓
CI System
↓
Artifact Signature

现代 Keyless Signing：

CI Workload Identity
↓
OIDC
↓
Short-lived Signing Certificate
↓
Ephemeral Key
↓
Signature

三十六、也就是说 Workload Identity 开始能够绑定 Artifact Signing Identity

三十七、GitHub Artifact Attestations 就采用了这一思路

GitHub Artifact Attestations 可以为构建出的 Artifact 产生加密签名的 Provenance Claim，其中可以包含 Workflow、Repository、Organization、Environment、Commit SHA、Trigger Event 等信息。

GitHub 文档说明其 Artifact Attestations 基于 Sigstore；同时也可以为 Artifact 生成包含 SBOM 的 Attestation。

三十八、这正适合 SEO Publisher 一类 CI/CD 系统

Repository:
seo-publisher

Commit:
abc123

Workflow:
deploy.yml

Environment:
production

Artifact:
worker-bundle

Digest:
sha256:...

三十九、最终生成 Build Provenance Attestation

并绑定 Artifact Digest。

四十、于是生产部署前就可以问

Was this artifact built
from the expected repository?

From the expected commit?

By the expected workflow?

In the expected environment?

Using the expected builder?

四十一、这比“文件来自 GitHub Actions”严格得多

因为 GitHub Actions 只是平台名字。真正需要的是 specific workflow + specific repo + specific source revision + specific artifact digest。

四十二、进入 SLSA

SLSA，也就是 Supply-chain Levels for Software Artifacts，是一个用于描述并逐步提升软件供应链安全保障的规范体系。

截至 2026 年 10 月，SLSA v1.2 是当前 Approved 版本，并正式包含 Build Track + Source Track。

四十三、这点非常重要

早期很多介绍还在讲 SLSA 1–4，或者只讲 Build Provenance。

当前 SLSA 已经明确拆分 Tracks，不同 Track 解决不同供应链风险。

四十四、SLSA Build Track 当前核心层级

Build L1
Provenance exists

Build L2
Signed provenance
+
hosted build platform

Build L3
Hardened / isolated
build platform

SLSA v1.2 的 Build Requirements 对 Hosted Build、Isolation 以及 Provenance 生成方式提出逐级增强的保证。

四十五、Build L1 解决“可追踪”

至少知道 how artifact was built。

四十六、Build L2 进一步解决“Build 后篡改”

因为 Provenance 需要 authenticated / signed，并来自 hosted build platform。

四十七、Build L3 进一步提升 Builder 本身的可信度

重点开始变成：Can another build interfere with this build? Can the build process be influenced outside declared inputs?

四十八、所以更高 SLSA Level 不是简单“多打一份签名”

stronger build isolation
+
stronger provenance guarantees
+
stronger builder trust

四十九、SLSA v1.2 还正式增加 Source Track

当前 Source Track 的简化层级包括：

Source L1
Use version control

Source L2
Preserve history
+
generate source provenance

Source L3
Enforce organizational
technical controls

Source L4
Require code review

五十、这使 Source Governance 和 Build Governance 可以真正连接

Source Track
↓
Approved Revision
↓
Build Track
↓
Verified Artifact

五十一、这是我们整个 SEO/GEO 自动化体系非常重要的一次升级

此前 Pull Request → Merge → Deploy。

现在变成：

Verified Source Revision
↓
Verified Build
↓
Verified Artifact
↓
Verified Deployment

五十二、但必须避免一种新的误区

SLSA Level
≠
Universal Security Score

SLSA 每个 Track 有明确的 Threat Model 和 Requirements。

不能简单理解为 L3 = software is secure。

五十三、因为软件本身仍然可能有漏洞

perfectly reproducible / perfectly attested / vulnerable software 完全可能存在。

五十四、因此需要区分两个问题

Was this artifact produced correctly? 与 Is this software free from vulnerabilities? 不是同一个问题。

五十五、这就是 Supply Chain Integrity 与 Application Security 的边界

Supply Chain Integrity
≠
Vulnerability Absence

五十六、NIST SSDF 提供了更广的 Secure Software Development 视角

NIST SP 800-218 SSDF v1.1 是正式发布的 Secure Software Development Framework，强调把安全开发实践集成进现有 SDLC，用于减少漏洞、降低未发现漏洞被利用后的影响，并降低根因重复出现的概率。

五十七、因此项目里应该避免一句话

错误：We use SLSA, therefore our software is secure.

五十八、更准确的说法

SLSA
strengthens supply-chain
integrity guarantees.

SSDF
addresses broader
secure development practices.

五十九、进入 Dependency Trust

现代软件很少完全由 First-party Code 构成。

seo-publisher
├── wrangler
├── typescript
├── cloudflare SDK
└── dozens of transitive packages

真正的攻击面往往来自 Dependency Graph。

六十、所以 Source Review 不能只审自己写的代码

还要审 Dependency Changes。

六十一、Dependency Identity 同样需要固定

例如 npm 项目中，package.json 通常描述 acceptable version range，而 package-lock.json 记录解析出的具体依赖树。

npm 官方说明 package-lock.json 用于描述实际生成的依赖树，使 CI、部署和其他开发者能够安装一致的依赖版本；其中还包含 resolved 与 integrity 等信息。

六十二、所以 CI 更适合使用 npm ci

而不是让 Production Build 在运行时随意重新解析依赖范围。

npm 官方说明，当希望严格按照 lockfile 安装、并确保 package.json 与 lockfile 保持同步时，应使用 npm ci。

六十三、这就是 Deterministic Dependency Resolution

Dependency Intent
↓
Lock File
↓
Resolved Artifact

六十四、但 Lockfile 仍然不是完整供应链安全

因为它主要帮助解决 Which dependency version? 并不能完整解决 Was the dependency publisher compromised? Was registry metadata tampered with? Was package itself malicious?

六十五、所以需要 Dependency Evidence

Package Identity
Version
Digest
Publisher
Provenance
Signature
License
Known Vulnerabilities
Dependency Path

六十六、SBOM 正好成为 Dependency Inventory 的标准载体之一

Artifact A
↓
SBOM
├── Dependency B
├── Dependency C
└── Dependency D

六十七、但 SBOM 必须绑定具体 Artifact

错误：project SBOM，却不知道它对应 which build?

六十八、应该绑定

Artifact Digest
↔
SBOM

六十九、这叫 SBOM-to-Artifact Binding

如果 Artifact 变化，SBOM 也需要重新生成或重新证明关联关系。

七十、GitHub Artifact Attestations 已经支持把 SBOM 与 Artifact Attestation 连接

这比 upload a random sbom.json 更强，因为消费者可以进一步验证 which artifact this SBOM belongs to，以及对应 Attestation 的签发上下文。

七十一、进入 GitHub Actions Supply Chain

很多团队保护了自己的代码，却忽略 uses: third-party/action@v1 本身也是代码执行。

七十二、GitHub 官方明确建议高风险场景 Pin 到完整 Commit SHA

GitHub Secure Use 文档指出，将 Third-party Action pin 到完整 Commit SHA，可以降低 Tag 被移动或上游仓库被篡改后执行不同代码的风险。

七十三、因此

uses:
action@v4

和：

uses:
action@<full-commit-sha>

供应链保障级别并不相同。

七十四、可以定义 Workflow Dependency Policy

Third-party Action
must be pinned
to full commit SHA.

Floating branch
DENY.

Unapproved publisher
DENY.

七十五、这和第（三十三）篇 Desired State 连接

Desired State 不只是 application config，还应该包含 approved workflow dependencies、approved action SHAs、approved builder versions。

七十六、如果 actions/setup-node 突然从 Approved SHA 变化为另一个 SHA

就应该触发 Supply Chain Drift。

七十七、这是一种新的 Drift 类型

此前已经有 Configuration Drift、Policy Drift、Identity Drift、Credential Drift。

现在增加：

Dependency Drift
Artifact Drift
Builder Drift
Workflow Drift
Supply Chain Drift

七十八、Dependency Drift 不一定意味着升级版本

例如 same tag / different digest，本身就是重要 Drift。

七十九、所以 Drift Detection 应比较 Identity，而不是 Display Name

Expected:
sha256:A

Actual:
sha256:B

即使 tag = v1 完全相同，仍然应该 DRIFT。

八十、进入 Signed Build

很多人说 signed build，但真正应该区分 signed artifact 和 authenticated build provenance。

八十一、Artifact Signature 回答

Who signed
this exact artifact?

八十二、Build Provenance 回答

How was
this exact artifact
produced?

八十三、两者最好同时存在

Artifact
├── Signature
└── Provenance Attestation

八十四、Cosign 可以验证普通 Signature

Sigstore Cosign 在验证 Container Image 时会核对签名以及 Artifact Digest；Cosign 也支持 Attestation Verification。

八十五、因此一个真正可靠的 Release Verification 可以是

Artifact Digest
↓
Verify Signature
↓
Verify Signer Identity
↓
Verify Provenance
↓
Verify Source Commit
↓
Verify Builder
↓
Verify Policy

八十六、但 Verify 不能只发生在 CI

很多系统 Build → Verify → Publish → Deploy whatever is in registry，中间又留下了替换窗口。

八十七、真正更稳健的方式是 Verification at Admission

也就是 Before Production Runtime starts, verify the Artifact again.

八十八、这就是 Admission Control

Deployment Request
↓
Admission Policy
↓
Artifact Verification
↓
ALLOW / DENY

八十九、Kubernetes 已经提供这一类控制位置

Kubernetes Admission Control 可以在对象真正持久化或运行前应用验证策略；Dynamic Admission Controller 还可以查询外部数据，例如从 OCI Registry 获取信息并验证 Container Image Signature / Attestation。

九十、GitHub Artifact Attestations 也提供了 Kubernetes Admission Enforcement 路径

intercept image admission
↓
verify artifact attestation
↓
evaluate cluster policy
↓
allow / reject

从而保证只有拥有有效 Attestation、并符合指定 Build Provenance Policy 的 Image 被部署。

九十一、Sigstore Policy Controller 还会解析 Image Tag 到 Digest

这有助于确保实际运行的 Image 不会和 Admission 时验证的 Image 不同，并能够根据 Signature 和 Attestation 应用 Policy。

九十二、这解决了一个典型问题

错误：

Verify:
app:v1

Deploy:
app:v1

看似一样，实际上 v1 可能已经被重新指向。

九十三、更安全

Resolve Tag
↓
Digest
↓
Verify Digest
↓
Deploy Same Digest

九十四、于是新的硬规则出现

Verified Artifact Digest
=
Deployed Artifact Digest

九十五、如果不等

DENY

九十六、这可以定义为 Artifact Continuity

Build
↓
Publish
↓
Registry
↓
Admission
↓
Runtime

整个过程中 Artifact Identity 不能发生未授权变化。

九十七、因此第五种 Continuity 出现

第（三十六）篇已经建立 Trace Continuity、Causal Continuity、Authorization Continuity、Integrity Continuity。

现在增加：

Artifact Continuity

九十八、Artifact Continuity 回答

Is the software
running at the end
the same artifact
verified earlier?

九十九、但是 Admission Verification 仍然只证明“启动前”

如果一个 Runtime 启动以后 binary replaced、plugin modified、filesystem tampered、memory injected，Admission 时的证明已经不足。

于是进入：Runtime Attestation

一百、Runtime Attestation 要解决的是

What is actually
running now?

而不是 What was approved before startup?

一百零一、这也是第（三十五）篇 Workload Identity 必须继续增强的地方

Runtime Workload Identity
↓
Runtime Artifact Identity
↓
Build Provenance
↓
Source Revision

一百零二、因此可以形成 Runtime Artifact Binding

workload_identity:
spiffe://.../seo-publisher

artifact_digest:
sha256:abc123

source_revision:
git:975503...

build_attestation:
att_xxx

一百零三、当 Runtime 请求生产 Capability 时

Governance Engine 不应只问 Who are you? 还可以问 What artifact are you running?

一百零四、于是 Capability Issuance 也可以加入 Artifact Condition

IF

workload_identity
=
publisher

AND

artifact_digest
=
approved_digest

AND

provenance
=
verified

THEN

may issue
production capability

一百零五、这意味着第（三十五）篇的公式升级

此前：

Identity Valid
+
Capability Valid
+
Authority Current
+
Policy Current
=
Credential Eligibility

现在增加 Artifact Trusted。

一百零六、完整公式变为

Credential Eligibility
=
Verified Workload Identity
+
Approved Artifact Identity
+
Verified Provenance
+
Valid Capability
+
Current Authority
+
Current Policy
+
Current Coordination

一百零七、于是 Artifact 也成为 Authority 的前置条件

Same Agent Role
+
Different Artifact
=
Different Trust Decision

一百零八、这非常重要

假设 publisher-agent 身份没变，但从 artifact A 升级到 artifact B，系统不应该 automatically inherit all production authority。

一百零九、Artifact B 应重新进入

Build
↓
Attestation
↓
Verification
↓
Release Gate
↓
Admission

一百一十、这和第（三十二）篇 Progressive Delivery 完全连接

New Artifact
↓
Release Risk
↓
Canary
↓
Observe
↓
Promote

一百一十一、所以 Release Unit 应该是 Immutable Artifact

而不是 latest code。

一百一十二、可以定义 Release Artifact Manifest

{
  "release_id": "rel_037",
  "source_revision": "git:abc",
  "artifact_digest": "sha256:def",
  "sbom_digest": "sha256:ghi",
  "provenance_id": "att_101",
  "signature_bundle": "sig_202",
  "builder": "github-actions",
  "release_policy": "prod-v3"
}

一百一十三、这个 Manifest 本身也应该 Immutable

因为如果 release approval 之后有人更换 artifact_digest，就发生了 Approval Drift。

一百一十四、所以可以绑定 Release Manifest Hash

第（三十二）篇已经讨论 Change Manifest，现在进一步变成：

Change Manifest
↓
Release Manifest
↓
Artifact Manifest

一百一十五、最终三者必须一致

Approved Change
=
Released Artifact
=
Running Artifact

一百一十六、任何不一致都要产生 Supply Chain Exception

ARTIFACT_MISMATCH
SOURCE_MISMATCH
BUILDER_MISMATCH
SIGNER_MISMATCH
SBOM_MISMATCH
PROVENANCE_MISSING
DEPENDENCY_DRIFT
UNAPPROVED_BUILD
RUNTIME_DRIFT

一百一十七、这可以形成 Supply Chain Gate

ALLOW
DENY
QUARANTINE
REQUIRE_REBUILD
REQUIRE_REVIEW
REQUIRE_REATTEST

一百一十八、为什么需要 QUARANTINE？

因为 Unknown Artifact 不一定立即证明 Malicious，但也绝不能 run in production。

一百一十九、于是未知软件进入隔离状态

Unknown
↓
Quarantine
↓
Analyze
↓
Attest
↓
Approve / Reject

一百二十、这和 Evidence Plane 的 KNOW / UNKNOWN 模型连接

第（二十六）篇已经明确 UNKNOWN 是合法状态。软件供应链中同样如此。

一百二十一、没有 Provenance 不应该自动解释成“安全”

而应该 Provenance: UNKNOWN，然后 Risk Engine 根据资源重要性决定 DENY / REQUIRE_APPROVAL / QUARANTINE。

一百二十二、尤其高风险生产环境

No Verified Provenance
→
No Production Admission

一百二十三、低风险内部实验环境则可以降低要求

Development:
unsigned permitted

Staging:
provenance required

Production:
signature
+
provenance
+
approved source
+
approved builder
+
SBOM

一百二十四、这就是 Risk-adjusted Supply Chain Assurance

不同环境具有 different assurance floor。

一百二十五、WordPress 也存在软件供应链

不要因为 WordPress is PHP 就认为供应链问题只属于 Container / Kubernetes。

一百二十六、WordPress 生产面至少包括

WordPress Core
Theme
Child Theme
Plugin
MU Plugin
Custom PHP
Composer Dependency
JavaScript Dependency
Deployment Script

一百二十七、每一个都可以产生 Supply Chain Drift

例如 Approved Plugin: v1.2 / Production: v1.2，版本相同，但文件内容不同。

一百二十八、WordPress.org Plugin 可以使用 Checksum Verification

WP-CLI 提供 wp plugin verify-checksums，用于把安装的 Plugin 文件与 WordPress.org 提供的 Checksums 进行核对。

一百二十九、这本质上也是一种 Artifact Integrity Verification

Installed Files
↓
Expected Checksums
↓
MATCH / MISMATCH

一百三十、因此我们的 WordPress Agent 可以增加 Pre-Publish Integrity Check

例如高风险操作前：

Verify Core
Verify Plugin
Verify Theme Hash
Verify Deployment Version

一百三十一、如果生产插件被异常修改

即使 Publisher Agent 完全可信，也应该降低 Autonomy Budget，甚至 freeze production mutation。

一百三十二、这和第三十篇 Incident Containment 连接

Supply Chain Integrity Failure
↓
Incident
↓
Kill Switch
↓
Freeze Release
↓
Revoke Capability

一百三十三、软件供应链事件应该被视为高等级 Incident

例如 Unexpected Artifact Digest、Unknown Production Binary、Invalid Signature、Unknown Builder、Attestation Failure、Dependency Tampering，都不应该只是 Warning。

一百三十四、尤其 Credential Broker 本身

第（三十五）篇已经把 Credential Broker 定义为 Tier-0 Component。

于是它的 Artifact Supply Chain 必须比普通应用更严格。

一百三十五、Tier-0 软件建议要求更高 Assurance

Pinned Source
Protected Branch
Required Review
Hosted Build
Build Provenance
Signed Artifact
SBOM
Admission Verification
Runtime Artifact Binding

一百三十六、否则可能出现最危险的情况

Compromised
Credential Broker
↓
issues legitimate credentials

所有下游日志都可能看起来 authenticated，但 Root of Trust 已经失效。

一百三十七、所以 Trust Infrastructure 自己也需要 Supply Chain Verification

包括 Governance Engine、Capability Issuer、Credential Broker、Action Gateway、Audit Writer、Reconciliation Controller。

一百三十八、这形成 Trust Bootstrapping Problem

Who verifies
the verifier?

一百三十九、一个可行方向是多层独立信任

Build Platform
↓
Artifact Attestation

Admission System
↓
independently verifies

Runtime Identity System
↓
binds admitted artifact

Audit Plane
↓
records evidence

一百四十、不能让同一个组件完成所有步骤

如果 builder 既能 Build，又能 self-approve / self-sign / self-admit / self-audit，那么供应链控制的价值会大幅下降。

一百四十一、所以需要 Separation of Duties

Producer
≠
Verifier

至少对 High-risk Production Artifact 如此。

一百四十二、GitHub Artifact Attestation 本身也强调一个重要事实

GitHub 官方明确指出，Generating attestations alone does not provide security benefit。真正的价值来自 verification。

Attestation Generated
≠
Attestation Enforced

一百四十三、这应该成为本文核心原则之一

Evidence without enforcement
is documentation.

Evidence + policy enforcement
becomes a control.

一百四十四、所以真正的成熟链应该是

Generate Evidence
↓
Store Evidence
↓
Verify Evidence
↓
Evaluate Policy
↓
Enforce Decision

一百四十五、只有 Generate SBOM 是不够的

Generate SBOM → archive somewhere，只是 documentation。

一百四十六、真正有价值的是

SBOM
↓
Dependency Policy
↓
Risk Evaluation
↓
Admission Decision

一百四十七、同样 Artifact Signature 如果从来没有被验证，价值同样有限

一百四十八、所以所有 Evidence 都应该进入 Policy Engine

例如 Artifact Digest、SBOM、Provenance、Signer、Builder、Source Revision、Dependency Risk，共同形成 Supply Chain Decision。

一百四十九、可以定义 Supply Chain Risk

Supply Chain Risk
≈
Source Trust Gap
×
Build Trust Gap
×
Dependency Exposure
×
Artifact Integrity Gap
×
Verification Gap
×
Runtime Drift

这是项目内部工程抽象，不是 SLSA、NIST 或 Sigstore 发布的官方公式。

一百五十、其中 Verification Gap 非常关键

即 Evidence exists but nobody enforces it。

一百五十一、Runtime Drift 也非常重要

因为 approved artifact 并不意味着 current runtime still matches it。

一百五十二、于是 Supply Chain Monitoring 需要持续化

Unsigned Artifact Rate
Missing Provenance Rate
Unknown Builder Rate
Artifact Digest Drift
SBOM Coverage
Unpinned Dependency Rate
Unpinned GitHub Action Rate
Admission Rejection Rate
Runtime Artifact Mismatch Rate
Unknown Production Artifact Rate
Critical Dependency Exposure
Attestation Verification Failure

一百五十三、其中最重要的一个指标：Unknown Production Artifact Rate

定义：

Running Production Artifact
without
recognized Artifact Identity

目标：0。

一百五十四、第二个关键指标：Provenance Coverage

Production Artifacts
with valid provenance
/
Total Production Artifacts

一百五十五、第三个关键指标：Admission Verification Coverage

不要只统计 signed artifacts，还要统计 how many deployments were actually verified before execution。

一百五十六、第四个关键指标：Source-to-Runtime Traceability

检查 Can every running workload be traced back to an approved source revision?

一百五十七、第五个关键指标：Dependency Provenance Coverage

即 How many critical dependencies have known source / publisher / integrity / provenance information?

一百五十八、Software Supply Chain 同样需要 Chaos / Game Day

测试 Replace artifact after build，预期 Digest mismatch → DENY。

一百五十九、测试 Modified SBOM

Artifact A + SBOM for Artifact B，预期 Binding verification failure → DENY。

一百六十、测试 Unsigned Artifact

Valid source + valid build + missing signature，生产 Policy 如果要求 Signature，则 DENY。

一百六十一、测试 Wrong Builder

Correct commit → Unapproved personal machine → Artifact。即使代码完全一致，高 Assurance 环境仍可以 DENY。

一百六十二、因为 Supply Chain Security 关注的不只是 Output

还关注 How was output produced?

一百六十三、测试 Third-party Action Drift

approved action SHA → unexpected SHA，预期 Workflow Policy Failure。

一百六十四、测试 Runtime Artifact Swap

Admission: digest A / Runtime: digest B，必须产生 SEVERE SUPPLY CHAIN INCIDENT。

一百六十五、测试 Provenance Replay

不能把 Artifact A provenance 绑定到 Artifact B，所以 subject digest 必须参与验证。

一百六十六、测试 Trusted Signer + Unauthorized Workflow

签名身份本身合法，但 Workflow 不在允许列表，结果 DENY。

一百六十七、这再次证明

Trusted Signer
≠
Trusted Build

一百六十八、最终生产 Artifact 应同时满足

Source Trusted
+
Change Approved
+
Dependencies Resolved
+
Build Trusted
+
Provenance Verified
+
Artifact Signed
+
Artifact Digest Approved
+
Admission Passed
+
Runtime Matches Artifact

一百六十九、这可以定义为 Artifact Eligibility

Artifact Eligibility
=
Source Eligibility
∩
Build Eligibility
∩
Dependency Eligibility
∩
Provenance Eligibility
∩
Signature Eligibility
∩
Admission Eligibility

一百七十、只有 Eligible Artifact 才能获得 Production Runtime

No Verified Artifact
→
No Production Runtime

一百七十一、进一步

No Approved Provenance
→
No High-risk Deployment

一百七十二、进一步

Runtime Artifact
≠
Admitted Artifact
→
Revoke Production Authority

一百七十三、进一步

Unknown Dependency Drift
→
Re-evaluate Artifact Trust

一百七十四、进一步

Attestation Valid
≠
Artifact Automatically Safe

一百七十五、进一步

SBOM Available
≠
Supply Chain Trusted

一百七十六、进一步

Signature Valid
≠
Policy Satisfied

一百七十七、进一步

Approved Source
≠
Approved Artifact

一百七十八、进一步

Approved Artifact
≠
Verified Runtime

一百七十九、完整的软件供应链 Control Plane

                        SOURCE
                          │
                          ▼
                 SOURCE GOVERNANCE
                          │
                   approved revision
                          │
                          ▼
                     DEPENDENCIES
                          │
                    dependency lock
                          │
                          ▼
                    BUILD PLATFORM
                          │
                          ▼
                    BUILD ARTIFACT
                          │
             ┌────────────┼────────────┐
             │            │            │
             ▼            ▼            ▼
           SBOM       PROVENANCE    SIGNATURE
             │            │            │
             └────────────┼────────────┘
                          ▼
                 ARTIFACT IDENTITY
                    digest / URI
                          │
                          ▼
                    ARTIFACT STORE
                          │
                          ▼
                     RELEASE GATE
                          │
                          ▼
                  ADMISSION CONTROL
                          │
                 verify + policy
                          │
                          ▼
                       RUNTIME
                          │
                          ▼
                 RUNTIME ATTESTATION
                          │
                          ▼
                  WORKLOAD IDENTITY
                          │
                          ▼
                       CAPABILITY
                          │
                          ▼
                    PRODUCTION EFFECT
                          │
                          ▼
                       EVIDENCE

一百八十、这形成一个新的控制平面

本项目可以定义为：

Software Supply Chain Assurance Plane

负责：

Source Verification
Dependency Resolution
Build Provenance
Artifact Identity
SBOM Binding
Signature Verification
Attestation Verification
Admission Policy
Runtime Artifact Binding
Supply Chain Drift Detection

一百八十一、它与现有控制平面的关系

Evidence Plane
↓
What do we know?

Governance Plane
↓
May this happen?

Identity Plane
↓
Who is acting?

Context Plane
↓
Why is it acting?

Supply Chain Plane
↓
What software is acting?

一百八十二、五个问题必须同时回答

WHO
=
Identity

WHY
=
Intent / Causality

WHAT MAY IT DO
=
Authority / Capability

WHAT SOFTWARE
=
Artifact / Provenance

WHAT HAPPENED
=
Execution Evidence

一百八十三、这才是真正完整的 Agent Production Trust Chain

Human Intent
↓
Source Revision
↓
Build
↓
Artifact
↓
Attestation
↓
Admission
↓
Runtime
↓
Workload Identity
↓
Delegation
↓
Capability
↓
Execution
↓
Verified Effect

一百八十四、所以 Agent Trust 不能只基于身份

publisher-agent 并不是一个完整的安全判断。

真正需要的是：

publisher-agent

running

artifact sha256:X

built by

workflow Y

from

commit Z

under

approved provenance

一百八十五、因此新的核心原则出现

Identity tells us who the workload is; provenance tells us what software became that workload.

一百八十六、再进一步

A trusted identity running an untrusted artifact is still an untrusted production actor.

一百八十七、这也是为什么 Runtime Attestation 最终必须连接 Authority

如果 Artifact Trust 下降，artifact_state: UNTRUSTED，那么 capability issuance 也应该自动收缩。

一百八十八、可以建立 Supply-chain-aware Autonomy

Artifact Trust:
HIGH
→
Autonomy Budget = HIGH

Artifact Trust:
UNKNOWN
→
Autonomy Budget = LOW

Artifact Trust:
FAILED
→
Autonomy Budget = 0

一百八十九、这让第（二十六）篇 Risk Engine 再次升级

Risk Engine 不再只读取 Action Risk、Environment Risk、Business Impact，还读取 Software Supply Chain Trust。

一百九十、最终 Residual Risk 需要考虑

Source Trust
Build Trust
Artifact Trust
Runtime Trust

一百九十一、Software Supply Chain Failure 也会进入 Incident Learning

例如发生 malicious dependency，Postmortem 后，不能只写 be more careful。

一百九十二、必须转化成新的机器控制

Pin Dependency
Require Provenance
Block Unknown Publisher
Add SBOM Rule
Require Review
Add Admission Policy
Add Runtime Check

一百九十三、这把第三十一篇 Reliability Learning Loop 再次闭合

Supply Chain Incident
↓
Postmortem
↓
Failure Mode
↓
Policy
↓
Admission Guard
↓
Regression Test
↓
Game Day

一百九十四、最终软件供应链也必须成为 Policy-as-Code

production:
  require_provenance: true
  require_signature: true
  require_sbom: true
  require_approved_builder: true
  require_approved_source: true
  require_digest_pin: true
  allow_unknown_artifact: false

一百九十五、Policy Engine 可以判断

Artifact A:
ALLOW

Artifact B:
REQUIRE_APPROVAL

Artifact C:
QUARANTINE

Artifact D:
DENY

一百九十六、最终 Release Gate 不再只问“测试通过了吗”

Tests Passed?

Artifact Signed?

Provenance Verified?

SBOM Available?

Dependencies Allowed?

Builder Trusted?

Source Approved?

Artifact Digest Fixed?

Admission Policy Satisfied?

一百九十七、这就是 Evidence-driven Release 的进一步完成

第（三十二）篇：Exposure must be earned by evidence.

第（三十七）篇进一步增加：Execution must be earned by artifact trust.

一百九十八、第（三十七）篇新的 Safety Invariants

此前已经有：

No Valid Decision
→
No Capability

No Capability
→
No Production Mutation

No Verified Workload Identity
→
No Privileged Credential

No Valid Root Intent
→
No Privileged Production Effect

现在增加：

No Verified Artifact Identity
→
No Trusted Production Runtime

一百九十九、再增加

No Artifact Digest Binding
→
No Strong Artifact Identity

二百、再增加

No Verified Provenance
→
No High-risk Production Admission

二百零一、再增加

Signed Artifact
≠
Automatically Approved Artifact

二百零二、再增加

SBOM Exists
≠
Artifact Trusted

二百零三、再增加

Deployed Artifact Digest
must equal
Approved Artifact Digest

二百零四、再增加

Runtime Artifact Drift
→
Revoke or Re-evaluate
Production Authority

二百零五、再增加

Unknown Build Origin
→
Unknown Artifact Trust

二百零六、最后增加

No Source-to-Runtime
Evidence Chain
→
No Strong Supply-chain
Trust Claim

结语：真正的 Agent Trust，最终必须落到“实际执行的那一份软件”上

从第二十五篇开始，我们不断缩小 Agent 的隐式信任空间。

从 Agent says it may act，升级为 Governance Decision，再升级为 Capability，然后加入 Reliable Execution、Reconciliation、Incident Control、Postmortem、Progressive Delivery、Desired State、Resource Ownership、Workload Identity、End-to-End Causality。

做到第三十六篇时，我们已经可以回答：

Who caused
this production effect?

但第三十七篇继续追问：

What software
actually produced
this production effect?

这是非常关键的一步。

因为：

Trusted Human
+
Trusted Agent Identity
+
Trusted Intent
+
Compromised Binary

最终仍然可以产生 Compromised Production Effect。

所以真正成熟的生产自动化必须建立：

Approved Source
↓
Verified Build
↓
Known Dependencies
↓
Artifact Identity
↓
SBOM
↓
Provenance
↓
Signature
↓
Admission
↓
Runtime Attestation
↓
Workload Identity
↓
Capability
↓
Production Effect

软件不再因为“它来自我们的 CI”就被信任，也不会因为“它有一个签名”就被信任，更不会因为“它有 SBOM”就自动被信任。

真正的信任来自：

Evidence
+
Identity
+
Provenance
+
Policy
+
Verification
+
Enforcement

于是我们可以在此前原则上继续增加一条：

Execute Fast
Stop Faster
Recover Carefully
Learn Permanently
Release Progressively
Reconcile Continuously
Coordinate Explicitly
Identify Cryptographically
Propagate Context Verifiably
Verify Software Before Trust

第（三十七）篇最核心的原则可以压缩为：

Do not trust software because of its name, tag, location or pipeline. Trust the exact artifact only after its identity, provenance and policy compliance have been verified.

进一步压缩：

Verify Source
↓
Verify Build
↓
Verify Artifact
↓
Verify Admission
↓
Verify Runtime
↓
Then Grant Authority

到这里，我们终于把 Who is acting? 和 What software is acting? 合并到了同一条生产控制链中。

这才是真正意义上的：

Verifiable Software Supply Chain for Autonomous Agents

官方依据与工程边界说明

SLSA v1.2：截至本文写作时，SLSA v1.2 是当前 Approved 版本，正式包含 Build Track 与 Source Track。Build Track 强调 Artifact Build Provenance 与逐级增强的 Build Platform Assurance；Source Track 则覆盖 Source Revision、History、Technical Controls 与 Code Review 等源代码治理问题。官方资料：https://slsa.dev/spec/v1.2/

in-toto：in-toto 提供用于保护软件供应链完整性的框架，通过受信任 Layout、供应链步骤以及签名 Link Metadata 等机制验证步骤是否按照计划执行、由授权 Functionary 完成，并验证中间产物没有在供应链过程中遭到替换。官方资料：https://in-toto.io/docs/specs/

GitHub Artifact Attestations：GitHub 可以为 Artifact 生成加密签名的 Build Provenance，并可关联 SBOM；GitHub 使用 Sigstore 实现 Artifact Attestations。GitHub 同时明确强调，仅生成 Attestation 并不能自动产生安全价值，必须对 Attestation 进行实际 Verification。官方资料：https://docs.github.com/en/actions/concepts/security/artifact-attestations

Sigstore / Cosign：Sigstore 支持通过 OIDC 身份和短期证书执行 Keyless Signing，Cosign 可以签名和验证 Container、Blob 与 Attestation；Public Good Instance 还使用 Rekor Transparency Log 提供公开可审计的签名记录。官方资料：https://docs.sigstore.dev/quickstart/quickstart-cosign/

SPDX：SPDX 是 ISO/IEC 5962:2021 国际标准，当前 SPDX 官方列出的现行版本为 SPDX 3.0，可用于表达软件组件、许可证、供应链和其他软件物料信息。官方资料：https://spdx.dev/use/specifications/

CycloneDX：CycloneDX 提供结构化 BOM Object Model，可描述组件、依赖、服务及其他软件和系统透明度数据，SBOM 是其重要应用之一。官方资料：https://cyclonedx.org/specification/overview/

Kubernetes / Sigstore Admission：Kubernetes Admission Control 可以在对象进入生产执行环境前应用 Policy；Sigstore Policy Controller 能够在 Kubernetes 中验证 Container Image Signature 与 Attestation，并把 Image Tag 解析到 Digest，降低 Admission 后 Artifact 被静默替换的风险。官方资料：https://kubernetes.io/docs/concepts/policy/

GitHub Actions Supply Chain：GitHub 官方安全指南建议将 Third-party Actions Pin 到完整 Commit SHA，以降低可变 Tag、上游仓库被篡改等供应链风险。官方资料：https://docs.github.com/en/actions/reference/security/secure-use

npm Dependency Lock：npm 的 package-lock.json 用于记录实际解析出的完整 Dependency Tree，并包含 resolved、integrity 等信息；在需要 CI 严格按照 lockfile 安装且不自动修改依赖解析结果的情况下，npm 官方推荐使用 npm ci。官方资料：https://docs.npmjs.com/files/package-lock.json/

WordPress Plugin Integrity：WP-CLI 提供 wp plugin verify-checksums，可将已安装 Plugin 文件与 WordPress.org 提供的 Checksums 进行验证，因此可以作为 WordPress Runtime Artifact Integrity Check 的一个基础控制。官方资料：https://developer.wordpress.org/cli/commands/plugin/verify-checksums/

NIST SSDF：NIST SP 800-218 SSDF v1.1 是当前正式发布的 Secure Software Development Framework；2025 年 12 月发布的 SP 800-218 Rev.1 / SSDF 1.2 属于 Initial Public Draft。因此本文将其作为当前演进方向参考，而不把 Draft 当作正式最终标准。官方资料：https://csrc.nist.gov/pubs/sp/800/218/final

本文提出的 Software Supply Chain Assurance Plane、Artifact Eligibility、Artifact Continuity、Supply Chain Gate、Supply Chain Drift、Runtime Artifact Binding、Supply-chain-aware Autonomy、SBOM-to-Artifact Binding、Release Artifact Manifest 等，是本 SEO / GEO 自动化体系在 SLSA、in-toto、Sigstore、GitHub、SPDX、CycloneDX、Kubernetes 和 NIST 等标准与工程实践基础上进一步形成的项目级抽象，并不是这些组织共同定义的一套统一 Agent Supply Chain 标准。

第（三十八）篇自然承接方向

第三十七篇解决以后，我们已经能够证明：

Which source?
↓
Which build?
↓
Which artifact?
↓
Which dependencies?
↓
Which runtime?

但对于 AI Agent，马上还会出现一个更棘手的问题：

Which model?

Which prompt?

Which system instruction?

Which tool definition?

Which MCP server?

Which knowledge base?

Which retrieved documents?

Which embedding model?

Which data snapshot?

Which evaluation set?

Which model version
actually produced
this decision?

传统 Software Supply Chain 只能证明 software artifact，却无法完整证明 AI behavioral inputs。

因此第（三十八）篇可以继续进入：

AI Supply Chain / Model Provenance / Prompt Provenance / Tool & MCP Trust / Dataset Lineage / RAG Corpus Integrity / Model Registry / Evaluation Attestation / AI Bill of Materials

把 What software performed the action? 进一步推进到 What model, prompt, tool, data and knowledge caused the Agent to make this decision?

Model
+
Prompt
+
Tool
+
Knowledge
+
Data
+
Software
+
Identity
+
Intent
↓
AI Decision Provenance

这会把整个系列正式从传统 Software Supply Chain 推进到：

Verifiable AI Supply Chain