1. 课程导入与全景认知

容器镜像安全与漏洞治理，指的是围绕容器镜像从构建、存储、分发到运行的全生命周期，识别、评估、修复和持续控制其中安全风险的一整套工程实践。它关注的不是某一个扫描工具，而是“镜像里有什么、从哪来、能不能信、出了问题怎么修、修完如何证明”这条完整链路。镜像一旦构建完成，就成为一个不可变的交付物，它把操作系统基础层、语言运行时、应用依赖、配置文件和启动入口一起打包。这意味着传统“上线前扫一次主机”的思路不再适用：漏洞可能藏在基础镜像的某个系统库中，也可能来自应用依赖树深处，还可能因为构建过程引入了不该存在的密钥或调试工具。

理解这一领域，先要看清镜像的分层结构。镜像由多个只读层叠加而成，最底层通常是发行版基础镜像，中间是运行时与依赖安装层，最上层是应用代码与启动配置。容器运行时通过联合文件系统把这些层组合成可写容器。安全治理的关键在于：每一层都可能引入漏洞，而层与层之间存在继承关系——基础镜像的漏洞会被所有下游镜像继承。因此，治理必须从“源头”开始，而不是只盯最终产物。

从图中可以看到，镜像安全不是单点问题，而是一条链。构建阶段决定了镜像的“基因”，存储与分发阶段决定了“信任传递”，运行阶段决定了“暴露面”，退役阶段决定了“残留风险”。而漏洞来源分布在每一层：基础镜像的系统包、应用依赖树、构建残留、配置权限。治理控制点则对应五个动作：最小化基础镜像、依赖锁定与扫描、签名与准入、运行时加固、持续复扫。这五个动作构成一个闭环，而不是一次性任务。

核心挑战可以归纳为四点。第一，漏洞数量与修复速度的矛盾。一个典型的基础镜像可能包含上百个 CVE，但真正可被利用的往往只是其中一小部分。如果盲目追求“零漏洞”，会导致大量无效修复和版本冲突。第二，依赖传递的隐蔽性。应用直接依赖的库可能只有十几个，但传递依赖可能达到数百个，其中某个间接依赖的旧版本可能正是漏洞入口。第三，构建产物的不可变性带来的修复困难。镜像一旦推送，修改它意味着重新构建、重新扫描、重新签名、重新部署，链路长、成本高。第四，合规与审计要求。金融、医疗等行业需要证明“这个镜像在某个时间点是什么状态、修过什么、谁批准的”，这要求完整的元数据记录。

治理目标应当是可操作的，而不是口号。具体来说：可追溯，即每个镜像都能回答“它由哪些层、哪些包、哪些依赖构成”，这需要 SBOM（软件物料清单）；可验证，即镜像来源可信、内容未被篡改，这需要签名与校验；可修复，即发现漏洞后能快速定位影响范围并生成修复版本，这需要版本锁定与自动化重建；可审计，即所有扫描、审批、部署动作都有记录，这需要策略引擎与日志留存。

课程学习路径将围绕这条链展开。首先建立全景认知，理解镜像分层、漏洞来源与治理闭环；然后进入构建阶段，学习基础镜像选择、多阶段构建、依赖锁定与 SBOM 生成；接着进入扫描与评估，掌握 Trivy、Grype 等工具的使用，理解 CVSS 评分、可达性分析与误报处理；再进入签名与准入控制，学习 Cosign、Notation 与 OPA/Kyverno 策略；随后进入运行时加固与持续监控；最后通过综合案例，完成从漏洞发现到修复验证的完整闭环。

为了帮助建立量化认知，下面给出一个示例镜像的扫描结果摘要。该示例基于一个常见的 Node.js 应用镜像，使用 Trivy 扫描后得到如下统计（数据为教学示例，非实测结果）：

面对这样的结果，治理动作不是“全部升级”，而是分层处理：Critical 和 High 必须优先修复，Medium 结合可达性判断，Low 可以纳入定期清理。同时，要记录每个漏洞的修复状态，形成可追踪的治理台账。这个台账不需要复杂系统，一个结构化的 CSV 或数据库表即可，字段包括：镜像名称、标签、扫描时间、CVE 编号、严重等级、影响包、当前版本、修复版本、修复状态、负责人、验证时间。这样，当新的 CVE 披露时，可以快速检索哪些镜像受影响，而不是重新扫描所有镜像。