container-diff 不能直接识别安全补丁是否应用，仅报告包版本或文件变更；需结合 CVE 数据库、安全通告和包 changelog 手动验证。
container-diff 是 Google 开源的镜像差异分析工具，专为对比 Docker 镜像层、包列表、文件系统变更等设计，但它不直接识别“安全补丁”是否已应用——它只告诉你「某个包的版本变了」或「某个文件被删了/新增了」。真正的安全补丁差异判断，需要你结合 CVE 数据库、基础镜像更新日志和包管理器输出来交叉验证。
为什么 container-diff 不能直接告诉你“修复了哪些 CVE”
container-diff 的能力边界很明确：它解析镜像的文件系统快照和包管理数据库（如 dpkg、rpm、apk），输出两镜像在以下维度的差异：
-
apt或apk包列表（含版本号） - 文件系统新增/删除/修改的路径
- Docker 镜像层元数据（如构建命令、时间戳）
- 用户、权限、环境变量等配置项
但它不会调用 NVD API、不查 debian-security 更新公告、也不解析 apt list --upgradable 的语义。所以当你看到 libssl1.1 从 1.1.1n-0+deb11u5 升到 1.1.1n-0+deb11u6，container-diff 只报“版本变更”，而 deb11u6 是否对应 CVE-2023-xxxx 的修复，得你手动查 Debian 安全通告。
用 container-diff 对比两个镜像前必须做的三件事
跳过这些准备，结果会误导你判断安全状态：
- 确保两个镜像都已
docker pull到本地，且 tag 明确（比如myapp:v1.2.0和myapp:v1.2.1）；container-diff不支持远程 registry 直连对比 - 确认基础镜像类型一致（都是
debian:11或都是alpine:3.18），混用会导致aptvsapk解析失败 - 如果镜像用了多阶段构建且最终层没保留包管理器数据库（例如 Alpine 镜像删了
/lib/apk/db/），container-diff就无法提取包列表——这时要改 Dockerfile，保留apk info或dpkg -l输出供后续审计
container-diff diff 的关键参数与安全相关输出解读
执行命令示例：
container-diff diff daemon://myapp:v1.2.0 daemon://myapp:v1.2.1 --type=apt --type=file --no-pull
重点关注以下输出段：
-
APT packages表格中，Changed列显示版本号变化，Added/Removed列提示新装或卸载的包——尤其注意curl、wget、gcc等攻击面扩大类工具是否被意外引入 -
Files表格里，/etc/ssl/certs/或/usr/lib/ssl/下的文件变动，可能意味着证书信任库更新，间接反映基础镜像是否同步了 CA 根证书轮换 - 若
container-diff报error: could not get package info for image，大概率是镜像构建时清除了包数据库（如 Alpine 的rm -rf /var/cache/apk/*过度清理），需回退到未清理的中间层重试
真正判断“安全补丁是否生效”的最小闭环流程
仅靠 container-diff 不够，但可以把它嵌入下面这个轻量流程：
- 用
container-diff diff ... --type=apt找出所有变更的 Debian 包及其新旧版本 - 对每个变更包，运行：
apt changelog（在对应基础镜像容器内执行），看 changelog 是否提及 CVE 编号 - 或查官方来源：
https://security-tracker.debian.org/tracker/source-package/，输入包名和版本，确认该版本是否标记为“fixed” - 把
container-diff的Files差异和changelog结果对齐——例如openssl版本升了，且 changelog 提到 “Fix CVE-2023-0217”，再检查/usr/lib/x86_64-linux-gnu/libssl.so.1.1的 mtime 是否更新，才敢说补丁落地了
这个闭环里，container-diff 是差异发现器，不是漏洞判定器。容易忽略的是：很多团队只比对镜像，却忘了验证容器运行时实际加载的共享库是否真的被替换——ldd 和 readelf -d 在容器内查动态链接，比看镜像层更可靠。
