1. 课程概述与目标
1.1 为什么需要制品签名？
在内部开发者平台（IDP）中，制品（Artifact）是软件交付的核心载体，包括容器镜像、Helm Chart、JAR 包、NPM 包等。未经签名的制品在流转过程中面临以下风险：
- 篡改风险：制品在构建、存储、传输环节可能被恶意或意外修改。
- 来源不可追溯：无法确认制品由哪个构建任务、哪个开发者、哪个提交产生。
- 供应链攻击：依赖投毒、镜像替换等攻击手段可绕过传统安全检测。
- 合规审计缺失：无法满足 SOC2、PCI-DSS、FedRAMP 等对制品完整性验证的要求。
关键数据：根据 Sonatype 2024 年报告，过去三年软件供应链攻击增长 742%，其中 89% 的攻击涉及未签名或签名失效的制品。
1.2 制品签名链路全景
IDP 中的制品签名不是单一操作，而是一条从密钥管理到签名生成、再到验证与策略执行的完整链路。下图展示了签名链路的核心阶段：
1.3 自动化测试验证方案的整体目标
本方案旨在建立一套可重复、可审计、可集成的自动化测试体系，对 IDP 制品签名链路进行端到端验证。核心目标如下：
| 目标维度 | 具体描述 | 验收标准 |
|---|---|---|
| 完整性验证 | 确保签名算法正确、签名数据未被篡改、签名与制品一一对应 | 篡改后验证失败率 100% |
| 链路覆盖 | 覆盖密钥管理、签名生成、存储分发、验证策略全链路 | ≥95% 的链路节点被自动化用例覆盖 |
| 异常场景 | 测试密钥过期、算法降级、签名缺失、策略冲突等异常路径 | 异常场景覆盖率 ≥80% |
| 性能基线 | 签名与验证操作在 CI/CD 管道中不成为瓶颈 | 签名耗时 ≤3s，验证耗时 ≤1s（单制品） |
| 可集成性 | 测试用例可嵌入 Jenkins、GitLab CI、GitHub Actions 等流水线 | 提供标准 CLI 与 API 两种触发方式 |
1.4 适用范围
本方案适用于以下场景与角色：
- 平台工程团队：在 IDP 中集成或升级制品签名能力时，用于验证签名链路的正确性。
- 安全测试团队：对签名链路进行安全审计与渗透测试，发现配置缺陷与实现漏洞。
- DevOps 工程师：在 CI/CD 流水线中嵌入签名验证步骤，确保只有经过签名的制品才能进入生产环境。
- 合规审计人员：通过自动化测试报告证明签名链路满足合规要求。
适用范围边界：本方案聚焦于 IDP 内部的签名链路测试，不涵盖外部依赖（如上游公共仓库）的签名验证。对于外部制品的信任策略，建议参考 SLSA（Supply-chain Levels for Software Artifacts）框架另行设计。
1.5 测试验证的核心挑战
在自动化测试签名链路时，需要特别关注以下挑战：
- 密钥安全：测试环境不能使用生产密钥，但测试密钥的生成、存储、销毁必须模拟真实流程。
- 时间敏感性：签名包含时间戳，测试用例需要处理签名有效期、证书吊销列表（CRL）等时间相关逻辑。
- 多平台兼容：同一签名链路可能需要在 Linux、macOS、Windows 容器中运行，签名工具链的跨平台行为需要验证。
- 幂等性：同一制品多次签名应产生可验证的相同结果（或可区分的合法结果），避免 CI 重试导致签名不一致。
1.6 方案交付物概览
本课程将交付以下核心资产：
| 交付物 | 说明 | 格式 |
|---|---|---|
| 测试用例设计文档 | 覆盖正常路径、异常路径、边界条件的完整用例清单 | Markdown / PDF |
| 自动化测试框架 | 基于 Pytest + Cosign + OPA 的可扩展测试框架 | Python 代码 + Dockerfile |
| CI/CD 集成模板 | Jenkinsfile、GitLab CI、GitHub Actions 示例 | YAML / Groovy |
| 测试报告模板 | 包含签名链路覆盖率、通过率、性能指标的 HTML 报告 | HTML + JSON |
| 故障注入工具集 | 模拟密钥泄露、签名篡改、算法降级等攻击场景 | Shell / Python 脚本 |
重要提示：本方案中的所有测试密钥、证书、签名材料仅用于自动化测试环境。严禁将测试密钥用于生产环境，也严禁将生产密钥导入测试框架。密钥隔离是签名链路安全的基础。