3. IDP 制品类型与签名链路全景
在 IDP（Internal Developer Platform）黄金路径中，制品签名是保障供应链安全的核心环节。不同制品类型具有截然不同的打包结构、签名机制和验证工具链。本章系统梳理五种主流制品类型——容器镜像、Helm Chart、JAR 包、NPM 包、Python Wheel 包——的签名链路特征，为后续自动化测试验证方案的设计奠定基础。
3.1 五种制品类型签名链路对比总览
下表从签名工具、签名对象、验证入口、元数据位置、自动化测试关键点五个维度，横向对比五种制品类型：
| 制品类型 | 主流签名工具 | 签名对象 | 验证入口 | 签名元数据位置 | 自动化测试关键点 |
|---|---|---|---|---|---|
| 容器镜像 | cosign (Sigstore) | 镜像摘要 (digest) | cosign verify | 镜像仓库 OCI 制品 / Rekor 透明日志 | 签名绑定镜像 digest；验证公钥或 OIDC 身份 |
| Helm Chart | helm gpg / cosign | Chart 包 (tgz) 或 OCI Chart | helm verify / cosign verify | Chart 内 prov 文件 / OCI 签名附件 | Chart 版本与签名一致性；公钥信任链 |
| JAR 包 | jarsigner / maven-gpg-plugin | JAR 内 MANIFEST.MF + 签名文件 | jarsigner -verify | JAR 内 META-INF 目录 | 签名算法强度；证书链有效性；时间戳 |
| NPM 包 | npm sign (npm CLI 9+) | package.json + 包内容 | npm audit signatures | npm registry 签名注册表 / 包内 sig 字段 | 签名与包版本绑定；注册表公钥同步 |
| Python Wheel 包 | pip / twine + sigstore | Wheel 文件内容 (RECORD + METADATA) | sigstore verify / pip verify | PyPI 注册表 / 独立 .sig 文件 | Wheel 哈希校验；签名者身份 OIDC 验证 |
3.2 容器镜像签名链路
容器镜像是 IDP 中最常见的部署制品。其签名链路以 cosign 为核心工具，遵循 Sigstore 标准。签名过程不修改镜像层，而是将签名作为独立的 OCI 制品存储在镜像仓库中。
签名链路关键步骤：
- 计算镜像 digest：对镜像 manifest 进行 SHA256 哈希，得到不可变标识符。
- 生成签名载荷：使用私钥或 OIDC 身份对 digest 进行签名，生成 DSSE (Dead Simple Signing Envelope)。
- 存储签名：将签名以
sha256-<digest>.sig的 tag 格式推送到镜像仓库。 - 透明日志记录：可选将签名记录到 Rekor 透明日志，提供公开可审计性。
- 验证：验证方从仓库拉取签名，使用公钥或 Fulcio 证书验证签名与 digest 的绑定关系。
3.3 Helm Chart 签名链路
Helm Chart 的签名链路分为传统 GPG 签名和现代 cosign OCI 签名两种模式。在 IDP 黄金路径中，推荐使用 OCI 签名模式以统一工具链。
两种签名模式对比：
| 维度 | GPG 签名模式 | cosign OCI 签名模式 |
|---|---|---|
| 签名工具 | gpg + helm gpg plugin | cosign |
| 签名对象 | Chart 包 (.tgz) 的 SHA256 | OCI Chart 的 manifest digest |
| 元数据位置 | Chart 同目录下的 .prov 文件 | OCI 仓库中的签名附件 |
| 验证命令 | helm verify --keyring |
cosign verify |
| 自动化测试复杂度 | 中等（需管理 GPG 密钥环） | 低（与镜像签名一致） |
3.4 JAR 包签名链路
JAR 包签名基于 Java 的 JAR Signing 规范，签名信息内嵌于包内 META-INF 目录。这是五种制品中签名结构最复杂的一种，涉及多个签名相关文件。
JAR 签名文件结构：
META-INF/
├── MANIFEST.MF # 清单文件，包含每个文件的 SHA256 摘要
├── SIGNER.SF # 签名文件，对 MANIFEST.MF 的签名
├── SIGNER.DSA/RSA/EC # 签名者证书和签名数据
└── (可选) *.SF / *.DSA # 多个签名者时存在多个文件对自动化测试验证要点：
- 签名算法强度：拒绝使用 MD2/MD5/SHA1 等弱算法，强制要求 SHA256 及以上。
- 证书链有效性：验证签名证书是否过期、是否由受信任的 CA 签发。
- 时间戳：如果签名包含时间戳，验证时间戳的合法性（防止证书过期后签名失效）。
- 完整性：验证 MANIFEST.MF 中的摘要与 JAR 内实际文件内容一致。
- 多签名者：如果 JAR 被多个实体签名，需验证每个签名均有效。
jarsigner -verify -verbose -certs my-app.jar输出中应包含 "jar verified" 字样，且证书链信息完整。自动化测试应解析输出中的警告（如证书过期）并判定为失败。
3.5 NPM 包签名链路
NPM 包的签名机制自 npm CLI 9.0 起正式支持。签名基于 Sigstore 基础设施，使用 OIDC 身份进行无密钥签名。签名信息存储在 npm registry 的签名注册表中，而非包内。
签名与验证流程：
- 发布时签名：npm publish 自动调用
npm sign，使用发布者的 OIDC 身份对包内容签名。 - 签名存储：签名记录上传至 npm registry 的
/-/npm/v1/signatures端点。 - 安装时验证：
npm install自动执行npm audit signatures，验证所有已安装包的签名。 - 失败处理：签名验证失败时，npm 输出警告但默认不阻止安装（需配置 strict 模式）。
3.6 Python Wheel 包签名链路
Python Wheel 包的签名目前尚未形成统一标准。社区主流方案是使用 Sigstore 对 Wheel 文件进行独立签名，签名文件与 Wheel 包一同上传至 PyPI 或私有仓库。
推荐签名方案：
# 使用 sigstore 对 Wheel 签名
sigstore sign my-package-1.0.0-py3-none-any.whl
# 验证签名
sigstore verify my-package-1.0.0-py3-none-any.whl \
--certificate my-package-1.0.0-py3-none-any.whl.crt \
--signature my-package-1.0.0-py3-none-any.whl.sig自动化测试关键点：
- 签名文件完整性：验证 .sig 和 .crt 文件与 Wheel 包同名且位于同一目录。
- OIDC 身份验证：验证签名者身份（如 GitHub Actions OIDC ）是否属于允许的发布者列表。
- Wheel 哈希一致性：验证 Wheel 包内 RECORD 文件的哈希值与实际文件一致。
- 回退检测：检测是否存在未签名的 Wheel 包被混入仓库。
3.7 本章小结与自动化测试设计要点
五种制品类型的签名链路虽然工具和流程各异，但存在以下共性特征，可作为自动化测试框架的设计基础：
- 签名绑定不可变标识：每种制品的签名都绑定到一个不可变标识（digest / 版本号 / 文件哈希），测试需验证绑定关系的完整性。
- 公钥信任链管理：所有签名验证都依赖公钥或 OIDC 身份。测试框架需提供统一的密钥/身份管理接口。
- 在线/离线双模式：容器镜像和 NPM 包的签名验证依赖在线仓库，JAR 和 Wheel 可离线验证。测试框架应支持两种模式切换。
- 失败模式覆盖：需测试签名缺失、签名不匹配、证书过期、算法弱、身份不合法等异常场景。