容器镜像签名和扫描是防止供应链攻击和配置漏洞的两道防线，签名确保镜像来源可信，扫描发现已知漏洞，两者结合能挡住大部分安全风险。
容器镜像签名是什么：它阻挡的是信任链风险
镜像签名不是可选配置,而是从源头验证镜像发布者身份和内容完整性的机制，当攻击者向仓库推送恶意镜像，或中间人篡改传输中的镜像层，签名缺失会导致团队在不知情的情况下拉取被植入后门的容器。
签名解决的核心攻击场景
- 镜像劫持与替换：攻击者通过漏洞或凭证泄露，将合法镜像替换为恶意版本，签名通过公钥基础设施验证镜像摘要与签名是否匹配，一旦镜像内容被改，签名验证立即失败。
- 来源冒充：第三方伪装成官方发布者上传同名镜像，签名与发布者身份绑定，团队可以配置策略只接受指定签发者的镜像，阻止冒充行为。
- 镜像篡改：在CI/CD流水线中，镜像被构建后到部署前可能被篡改，签名在构建时生成，部署前验证，确保从构建到运行全链路未被修改。
实践中的签名操作路径
多数团队使用Cosign（来自Sigstore项目）或Notary（Docker原方案），操作流程通常包括：
- 生成密钥对或使用OIDC身份（Sigstore推荐方式）。
- 在构建完成后对镜像摘要签名：
cosign sign <镜像地址> - 部署前或拉取时验证签名：
cosign verify <镜像地址> --key <公钥或身份提供者> - 在Kubernetes中通过准入控制器（如Kyverno或OPA Gatekeeper）强制验证签名，阻止未签名镜像运行。
不实施签名,相当于在供应链入口处裸奔，行业共识认为，镜像签名能有效阻断镜像替换和来源伪造两类高发攻击。
容器镜像扫描能挡住哪些风险：从漏洞到合规
扫描是对镜像内部进行静态分析,发现操作系统包、应用依赖中的已知漏洞，以及配置不当、嵌入密钥等安全问题，与签名关注“谁发的”不同，扫描关注“里面有什么”。
扫描覆盖的风险类型
- 已知漏洞（CVE）：基础镜像和第三方库中包含的漏洞，扫描工具比对各层软件包与漏洞数据库，标记出严重程度，并给出修复建议。
- 配置安全基线：例如容器以root运行、特权模式、敏感端口暴露、文件系统只读未设置等，扫描工具会基于CIS Docker Benchmark等标准检查配置偏离。
- 密钥与敏感信息泄露：开发者在构建时不慎将API密钥、数据库密码、私钥等直接写入镜像层，扫描能识别常见密钥模式，提醒及时移除。
- 恶意软件与后门：部分扫描工具集成病毒库，可检测镜像中嵌入的已知恶意文件。
扫描在流水线中的位置
- 开发阶段：在IDE或本地构建时扫描，开发者即时修复新增漏洞，避免遗留到仓库。
- CI/CD环节：镜像构建后自动扫描，策略控制：严重漏洞阻断构建，低风险允许但记录。
- 仓库与运行时：定期扫描仓库中所有镜像，并监控运行中容器是否出现新漏洞（因为基础镜像可能更新，数据库也在更新）。
容器镜像扫描工具怎么选是团队常问的问题，主流工具包括Trivy（轻量，支持多种语言）、Clair（项目成熟，常与Harbor集成）、Anchore Grype、Snyk等，选择标准通常看：漏洞数据库更新频率、语言/包支持广度、性能开销、与CI/CD集成难度，没有绝对最优，但多数团队倾向Trivy因其速度和支持面。
容器镜像签名与扫描区别：分工明确，缺一不可
很多团队会在初期混淆两者作用,认为只做扫描就够了，但签名与扫描解决的是不同维度的风险，这一点在安全事件复盘时格外明显。
| 对比维度 | 容器镜像签名 | 容器镜像扫描 |
|---|---|---|
| 核心目标 | 验证来源与完整性 | 发现镜像内部问题 |
| 防御对象 | 供应链投毒、篡改、冒充 | 已知漏洞、配置错误、密钥泄露 |
| 是否依赖数据库 | 否（依赖公钥基础设施） | 是（依赖漏洞库更新） |
| 能否阻止零日漏洞 | 不能 | 不能（但可发现已知利用） |
| 实施时机 | 构建时签名，部署前验证 | 构建后、部署前、运行时均可 |
| 典型工具 | Cosign, Notary, Notation | Trivy, Clair, Grype, Snyk |
| 是否可被绕过 | 验证失败则阻断 | 取决于策略配置（如允许低危通过） |
为什么两者需要结合
- 签名无法阻止镜像内部存在漏洞,即使是官方签名的高版本镜像，也可能包含未被发现的CVE。
- 扫描无法阻止镜像被替换,攻击者可以构建一个完全无漏洞的镜像，但其中包含恶意逻辑，扫描工具可能无法识别（因为不是已知漏洞），签名则能确保只有受信任的发布者才能部署。
- 两者结合构成“来源可信+内容安全”的双重保障。容器镜像安全方案对比中，只做扫描的方案在供应链攻击面前形同虚设。
容器镜像安全实施：从团队规模出发的落地建议
不同阶段的团队面临的风险优先级不同,安全投入也应有所侧重，以下按场景给出具体路径。
初创团队或小规模（< 20人）
- 优先启动扫描：使用开源工具（如Trivy）集成到CI中，对每次构建扫描，严重漏洞阻止构建。
- 签名可以暂缓,但建议从重要镜像开始，比如对外暴露的服务镜像，用Cosign签署，简化密钥管理（使用Sigstore无密钥模式）。
- 操作示例：在GitHub Actions中增加扫描步骤，yaml中配置
trivy image --severity CRITICAL --exit-code 1 <镜像名>。
中大型团队（50人以上）
- 必须同时部署签名和扫描,且策略应自动化。
- 签名：使用私有密钥对或集成OIDC，在Kubernetes中通过准入控制器强制所有镜像必须经过签名验证才能运行。
- 扫描：在仓库（如Harbor）中配置自动扫描，同时设置漏洞容忍策略：严重漏洞只能降级不可直接部署，高危需要限期修复。
- 定期审计：将签名策略和扫描结果纳入安全仪表盘，与事件响应联动。
多云与混合云场景
- 签名和扫描策略需统一,但工具链可能因平台差异而不同，例如AWS ECR支持镜像扫描但签名需额外集成；Azure ACR原生支持Notation签名。
- 行业共识认为,跨云场景下，将签名验证下沉到容器运行时层（如Kubernetes）是实现一致性的关键。
容器镜像签名与扫描常见问题解答
如果已经用了镜像扫描，为什么还要加签名？
扫描无法验证镜像是否来自可信发布者，也无法防止镜像被篡改，2021年某知名事件中，攻击者向官方仓库推送了恶意镜像，扫描工具未检出（因为无已知漏洞），但签名验证可以阻止它，因为镜像内容与原始签名不匹配，签名和扫描覆盖的是不同攻击面，两者不能互相替代。
镜像签名会影响构建速度或部署延迟吗？
签名操作本身是轻量级加密计算，通常在构建后增加毫秒级时间，验证阶段在拉取或准入时执行，对运行性能无影响，但签名密钥管理、轮换和策略配置需要规划，尤其当团队规模较大时，建议使用自动化工具（如Sigstore的Keyless模式）降低管理负担。
容器镜像扫描工具怎么选更靠谱？
核心评估三点：漏洞数据库的更新频率（主流工具都在小时级更新）、对所用语言和运行时的覆盖度（Java、Python、Node、Go等）、以及CI/CD集成文档是否完善，Trivy在社区活跃度和速度上表现突出，Clair在Harbor生态中整合度高，Snyk对商业支持较好，建议先试用开源工具，根据实际阻断效果和误报率决定是否付费，没有万能工具，但定期更换评估标准比固定一个工具更安全。