维度企业做法我们评价部署凭据OIDC 联合身份无长期密钥长期 ed25519 forced command⚠️ 落后但裸 VPS 无 IAM 可联合镜像引用digest 钉死digest 钉死✅ 很多团队还在部署 :latest镜像可信cosign 签名 SLSA 溯源 准入控制拒绝未签名仅 Trivy 扫描❌ 最值得补的一项密钥管理Vault / Secrets Manager可轮换可审计服务器上一个 600 的明文文件❌ 最弱环节审批变更管理 职责分离作者不能批自己的必需审批人同一人单人项目的固有限制发布策略金丝雀/蓝绿 SLO 自动回滚up -d 硬切换单节点单用户金丝雀无意义版本可追溯部署标记打进 APM构建→标签→healthz→metrics→部署后核验✅ 比多数小团队做得好数据库迁移独立步骤 expand-contract容器启动时 alembic upgrade head❌ 公认反模式cosign 签名 SLSA 溯源是什么文章目录cosign签名 SLSA 溯源介绍Cosign 签名核心概念给镜像盖一个数字印章工作原理它防什么Keyless 模式企业常用SLSA 溯源SLSA 是什么SLSA Provenance溯源声明它和 Cosign 怎么配合对我们来说意味着什么当前状态最小改进投入产出比最高cosign签名 SLSA 溯源介绍好问题。这两个概念经常一起出现解决的是同一个核心问题的两个层面这个镜像是谁造的有没有被篡改过Cosign 签名核心概念给镜像盖一个数字印章注Cosign 是一个命令行工具CLI它是 Sigstore 项目下的一个可执行程序用 Go 语言编写就像你签一份合同——你的签名证明这份内容是我确认的没被改过。Cosign 对容器镜像做同样的事。工作原理构建阶段 1. CI 构建出镜像得到一个 digest比如 sha256:abc123... 2. CI 用私钥对这个 digest 签名 3. 签名被存到 registry 里和镜像关联在一起 部署阶段 1. 服务器拉镜像前先拿到镜像的 digest 2. 用公钥验证这个 digest 上的签名是否合法 3. 验证通过 → 拉取并部署 4. 验证失败 → 拒绝报警它防什么我们当前的攻击面当前流程无签名 1. CI 构建镜像标签是 abc1234 2. Trivy 扫描这个镜像 → 通过 3. 部署时服务器去 GHCR 解析 abc1234 标签 → 拿到 digest → 拉取部署 攻击 - 在步骤 2 和 3 之间有人或有权限的 CI job往 GHCR 推了一个恶意镜像也打标签 abc1234 - 服务器解析到的 digest 变了拉到的是恶意镜像 - Trivy 扫的是原来的镜像但部署的是新的恶意镜像 - 我们毫无察觉有签名后 1. CI 构建镜像 → cosign sign → 签名存入 registry 2. 部署时 → cosign verify → 验证签名 3. 如果有人推了恶意镜像覆盖标签 - 新镜像没有合法签名攻击者没有私钥 - cosign verify 失败 → 部署中止Keyless 模式企业常用传统的签名需要管理一对密钥私钥保密、公钥分发很麻烦。Keyless 模式用 OIDC 联合身份来签名签名时 - CI 从 GitHub 拿到一个 OIDC token证明我是 repo X 的 workflow Y - 这个 token 被用来向 Sigstore一个公共的、透明的签名日志服务请求一个短期签名证书 - 用这个证书签名 - 签名记录被写入透明日志rekor不可篡改 验签时 - cosign verify 检查 - 签名证书是否由可信的 OIDC 发行方签发 - OIDC token 里的身份repo、workflow是否符合预期 - 透明日志里是否有这条记录好处不需要管理密钥签名自带我是谁在哪里构建的信息。SLSA 溯源SLSA 是什么注SLSA读作 “salsa”全称是 Supply-chain Levels for Software Artifacts。它是一个安全框架和标准由 Linux 基金会下的 OpenSSF 维护。Supply-chain Levels for Software Artifacts软件制品供应链安全等级。Google 发起的一套框架回答一个问题这个软件制品是从哪来的经过了哪些步骤我能信任这条生产线吗分四个等级越高越严格等级要求类比L1有构建记录知道是谁构建的食品包装上写了生产厂家L2构建过程有签名可验证厂家有资质认证包装有防伪标L3构建环境隔离源码到制品的路径可审计生产线有监控录像原料来源可追溯L4构建过程完全可重现双人审批全程有独立第三方监督SLSA Provenance溯源声明一个 JSON 文件记录{builder:{id:GitHub Actions},buildType:https://github.com/actions/runner,invocation:{configSource:{uri:githttps://github.com/myrepo/app,digest:{sha1:commit_hash},entryPoint:.github/workflows/build.yml}},metadata:{buildStartedOn:2026-01-15T10:00:00Z,completeness:true},materials:[{uri:githttps://github.com/myrepo/app,digest:{sha1:...}}]}翻译成人话这个镜像是由 GitHub Actions 在某个时间、从某个 commit、用某个 workflow 构建的。它和 Cosign 怎么配合1. CI 构建镜像 2. SLSA generator 生成溯源声明provenance 3. Cosign 把溯源声明和镜像签名绑在一起存入 registry 4. 部署时 - cosign verify → 签名合法 - 检查溯源声明 → 是预期的 repo、branch、workflow 构建的 - 全部通过 → 部署Cosign 回答这个镜像没被改过SLSA 回答这个镜像是从正确的地方造出来的。对我们来说意味着什么当前状态我们现在做的 构建镜像 → Trivy 扫描漏洞检查→ 推到 GHCR → 部署时解析标签拉取 我们没做的 ❌ 没有签名 → 无法验证镜像是否被替换 ❌ 没有溯源 → 无法验证镜像是否来自正确的构建流程最小改进投入产出比最高CI 里加一行 cosign sign ghcr.io/myrepo/appsha256:abc123 部署脚本里加一行 cosign verify ghcr.io/myrepo/appsha256:abc123 效果 即使有人能写 GHCR推了恶意镜像覆盖标签 没有合法签名的镜像会被拒绝部署。SLSA 溯源是锦上添花——在单人项目里你知道镜像是自己造的溯源的价值不大。但 Cosign 签名验证是实打实堵住了一个当前存在的攻击面。