cosign 3.1.3 / 2.6.5 修复旧版 bundle 签名验证绕过

当天发生了什么

2026-08-06 01:09（UTC），sigstore 在 GitHub 发布了 cosign v3.1.3（同日稍早还发布了 v2.6.5），并在同一天公开了安全公告 GHSA-fx35-mq7g-6g98，标题为通过旧版 bundle 中的公钥绕过验证，严重性为高（CVSS 3.1 评分 7.4），未列出 CVE 编号。公告说明：当 verify-blob 或 verify-blob-attestation 读取旧版 JSON bundle 时，如果 cert 字段无法解析为 X.509 证书，会被静默当作原始公钥处理，于是证书链校验和身份策略检查被跳过，--certificate-identity 与 --certificate-oidc-issuer 等参数不起作用，验证仍以退出码 0 报告成功；另外，在使用 --key 时，bundle 里的公钥还可能替换受信任的公钥。受影响范围为 v2 ≤ 2.6.4、v3 ≤ 3.1.2；OCI 镜像验证和 protobuf bundle 格式不受影响。

对保护应用逻辑的人意味着什么

越来越多独立开发者用 cosign 给发布包、更新包、模型文件或 SBOM 签名，并在 CI 或更新流程中验证。签名的价值完全取决于验证是否正确：这次的问题恰好是「验证报告成功，但身份约束没有生效」，也就是说，若流水线验证的是攻击者提供的旧版 bundle，被替换的产物可能顺利通过。公告也给出了限制条件：只影响旧版 JSON bundle 和 blob 验证命令，CVSS 向量要求用户交互，即需要有人去验证攻击者提供的 bundle。它提醒我们，保护应用逻辑不只是混淆和加固，交付链路上的完整性检查同样是防线，而这条防线本身也依赖依赖项的及时更新。

可以落地的检查

第一，检查所有 CI 和发布脚本中使用的 cosign 版本，升级到 v2.6.5 或 v3.1.3 及以上。第二，搜索流水线里对 verify-blob 和 verify-blob-attestation 的调用，确认是否在处理旧版 JSON bundle；公告建议迁移到标准化的 protobuf bundle 格式并使用 --new-bundle-format 验证，现有 bundle 可用 cosign bundle create 转换。第三，增加一个反向测试：用错误身份签出的产物，验证步骤必须失败，否则视为流水线缺陷。第四，把这类签名工具纳入依赖更新与安全公告订阅范围。

行动清单

• 将 cosign 升级到 v2.6.5 / v3.1.3 或更高
• 排查流水线中处理旧版 JSON bundle 的验证调用
• 迁移到 protobuf bundle 并使用 --new-bundle-format
• 加入「错误身份必须验证失败」的反向测试