别再“跑得通就行”了：软件供应链安全这事，迟早轮到你（SBOM / Sigstore / in-toto 实战聊聊）

作者：Echo_Wish

说句掏心窝子的实话。

以前做运维，大家的安全观念是这样的👇

系统能跑、业务不炸、告警不红，就是好系统。

但这两年，我自己明显感觉到一个变化：
安全不再是“上线后的事情”，而是从你敲下 git push 那一刻就开始了。

而软件供应链安全，说白了，就是一句话：

你跑的这些代码、镜像、依赖，到底是不是“你以为的那一套”？

今天这篇文章，我不想讲一堆概念定义，而是站在运维 / DevOps 实战视角，聊聊这三样东西怎么真正“落地”：

• SBOM：你到底引了多少“祖宗十八代”
• Sigstore：你这个包，到底是谁给你“签的名”
• in-toto：这玩意儿，是不是被人半路掉包过

一、先别谈安全，先承认一个现实

我先说一个你我都心里有数的现实👇

90% 的系统，代码不是我们写的，是我们“拼”的。

• OS 是别人的
• Runtime 是别人的
• SDK 是别人的
• 镜像里一层一层，全是别人写的

那问题就来了：

• 出事了，你知道是哪一层吗？
• 被投毒了，你能定位到吗？
• 审计来了，你拿什么证明？

这时候，SBOM、Sigstore、in-toto 就不是“安全圈的高级玩具”，而是运维兜底工具。

二、SBOM：别再“我大概知道用了啥”

1️⃣ SBOM 到底解决什么问题？

SBOM（Software Bill of Materials），翻译过来就是：

软件的“配料表”

不是你脑子里“我记得我用了 Spring Boot + Log4j”，
而是机器可读、可审计、可比对的清单。

它回答的不是“你觉得你用了什么”，而是：

• 你到底引了哪些组件？
• 版本是多少？
• 从哪来的？
• 有没有漏洞？

2️⃣ SBOM 落地第一步：先生成再说

别一上来就搞治理、平台、流程，
第一步只有一个字：生成。

比如，用 Syft 给镜像生成 SBOM：

syft nginx:1.25 -o json > sbom.json

你会看到什么？

• libc、openssl、zlib
• 版本号
• 依赖路径
• 包管理器来源

那一刻你会意识到一件事👇
你对自己跑的系统，其实没你想得那么了解。

3️⃣ 我个人对 SBOM 的态度

说点真心话。

SBOM 不会立刻提升系统安全性，
但它会极大提升三样东西：

• 可见性
• 可追责性
• 安心感（这点很重要）

运维最怕的不是问题本身，
而是出问题时——你连底牌都没有。

三、Sigstore：别再靠“我信你”

1️⃣ 传统签名的痛点，运维都懂

以前做镜像签名、包签名，基本是这样：

• 私钥存哪？
• 过期了怎么办？
• 换人了怎么办？
• CI 机器被攻了咋办？

很多团队干脆就一句话：

算了，先不签了。

但 Sigstore 干了一件特别“运维友好”的事👇
把复杂的密钥管理，直接“云化 + 身份化”。

2️⃣ 用 cosign 给镜像签名（真的不复杂）

cosign sign my-registry/app:1.0.0

不需要你自己管私钥
直接用 OIDC（GitHub Actions / GitLab CI）

验证的时候：

cosign verify my-registry/app:1.0.0

你能验证什么？

• 是不是 CI 产出的
• 是不是这个 Repo
• 是不是这个 Workflow

这对运维意味着什么？

以后你可以理直气壮地说：
“没签名的镜像，别想进集群。”

3️⃣ Sigstore 在运维侧的真实价值

我不夸大它的安全性，只说一句实在的👇

Sigstore 让“责任”变得清晰了。

谁构建的
谁发布的
谁背锅的

都写在签名里。

四、in-toto：把“过程”也保护起来

1️⃣ 你有没有想过这个问题？

假设：

• 镜像有签名 ✅
• SBOM 也有 ✅

但中间过程呢？

• 构建机有没有被篡改？
• 测试结果是不是伪造的？
• 制品是不是被偷偷替换过？

in-toto 解决的就是一句话：

“你这玩意儿，是不是一路干净地走过来的？”

2️⃣ in-toto 的核心思想（运维版）

不讲理论，讲人话：

• 每个关键步骤都有“证明”
• 每一步都可追溯
• 最终制品 = 一整条可信链路

3️⃣ 一个简化示例（构建步骤签名）

in-toto-run \
  --step-name build \
  --products app.tar \
  --key builder.key \
  -- make build

最后你会得到一个 metadata 文件，
记录了：

• 谁执行的
• 执行了什么
• 生成了什么

你再也不是“我觉得这个包是干净的”，
而是——我能证明它是干净的。

五、别一口气全上，我给你一个“运维友好”落地顺序

这是我自己比较认可的顺序👇

第一阶段（最现实）

• 镜像 SBOM
• 基础漏洞扫描
• SBOM 归档

第二阶段（防止误操作）

• Sigstore 镜像签名
• 集群侧校验（Admission Controller）

第三阶段（安全成熟度）

• in-toto 关键链路
• 构建 / 测试 / 发布全留痕

记住一句话：

安全不是“全上”，而是“别再裸奔”。

六、写在最后：供应链安全，其实是运维的尊严

我最后说点不那么技术的。

很多运维兄弟姐妹，其实背了不少锅：

• 包不是你引的
• 代码不是你写的
• 事故却是你通宵处理的

软件供应链安全，本质上是在帮运维做一件事：

把“我不知道”变成“我能证明”。

这不是形式主义，
这是职业尊严。