镜像签名与漏洞扫描有什么区别?

很多团队在讨论镜像安全时，会把签名和扫描当成同一类门禁，甚至认为只要其中一项通过就够了。这个混淆会带来两种相反的错觉：签了名就以为镜像安全，或者扫过没发现漏洞就以为来源可信。实际上，这两项检查回答的是完全不同的问题——一个问“你是谁、有没有被改过”，一个问“你里面有什么问题”。

一个管来源，一个管内容

镜像签名验证的对象是不可变摘要与签名身份。它用密码学手段把镜像摘要和发布者身份绑定，在准入阶段确认签名是否由信任列表中的主体签发、部署请求引用的摘要是否与签名一致。它能挡住 tag 被重新指向、镜像在仓库中被替换、来源不明的镜像进入集群这类风险。但它对镜像内容本身几乎一无所知：只要签名有效，即使镜像里包含有问题的组件，校验照样通过。签名证明的是“这个产物确实由这个身份发布、中途没被改动”，不是“这个产物是安全的”。

漏洞扫描的对象正好相反，是镜像内部的软件成分。它解析包清单和版本，对照漏洞数据库给出已知问题。这决定了它天然带有时间滞后——今天新披露的漏洞不会出现在昨天的扫描结果里；也带有覆盖边界——私有补丁、未收录的组件、配置类风险，往往落在扫描范围之外。扫描给出的是某一时刻的风险快照，不是永久结论。

各管一段，失效方式也不同

两者在流水线里的位置不同。扫描适合放在构建阶段作为质量门禁，发现问题可以阻断构建、触发修复或记录豁免；签名适合放在产物发布与部署准入，保证产物从仓库到集群这段路上摘要不被替换。顺序上也有讲究：签名应当在扫描和必要验证之后进行，否则签下的可能是一个尚未被检查过的产物。

更关键的是失效方式不同。扫描的结论是概率性的、可协商的：阈值怎么定、误报怎么处理、豁免给不给，都会影响最终判断。签名验证则是二值的：验过或没验过，中间没有灰区。这也意味着，签名策略一旦开启阻断，暴露的是存量镜像的签名覆盖率问题；扫描门禁暴露的则是漏洞积压和修复节奏问题。两者对发布流程的冲击形态不同，治理手段也不能互换。

还有一个共同盲区：它们都约束不了“谁能写入仓库”。如果推送权限过宽，攻击者完全可以拿一个合法身份签名恶意镜像。签名和扫描都需要仓库的不可变 tag 策略、CI 身份的最小权限、密钥访问审计来配合，否则门禁的强度会被上游环节稀释。

判断顺序可以这样理：先确认镜像来源可信、摘要未被篡改，再判断内容风险是否在可接受范围内，剩下的交给权限控制和运行时防护。签名是扫描的前置条件，不是它的替代品。