Docker 镜像漏洞分类

要解决的问题

镜像扫描本身不难，难的是扫完之后怎么办。docker scan 或 Trivy 一键跑出的清单动辄几百条 CVE，其中大量是没有修复版本的老漏洞、被基础镜像上游标记为 won't-fix 的问题，或者低危的 DoS 项。把它们原样贴进工单，只会让值班工程师在无效信息里消耗注意力，真正需要本周处理的高优漏洞反而被淹没。

这个技能要解决的就是从扫描结果到可执行修复任务的最后一公里：把噪声滤掉，把优先级排清楚，产出一份能直接进 Jira 或 GitHub Issues 的结构化报告。

核心能力

技能内部做了三件事：

• 执行 Trivy 扫描：对指定的 Docker 镜像运行 Trivy，拉取漏洞库并逐层匹配镜像内安装的包；
• 按严重程度分组：结果按 Critical、High、Medium、Low 归类，并标注每条 CVE 是否已有可用修复版本；
• 过滤无修复项：没有 upstream fix 的 CVE 直接剔除，不进入最终报告。

最终输出是结构化文本，字段对齐工单系统的录入习惯，可以直接粘贴为 issue 描述，也方便脚本化追加到现有流水线里。

适用边界

几个值得提前知道的点：

• 技能只做漏洞分类与报告，不会自动 rebuild 镜像或升级依赖，实际修复仍需人工改 Dockerfile 或触发重建流程；
• 过滤策略只保留「有修复版本」的项，这意味着部分无法立即修复但确实存在的风险会被完全隐藏，如果你的场景需要完整审计留痕，需要关掉这个过滤逻辑；
• 结果质量依赖 Trivy 漏洞库的覆盖度，非主流发行版或私有包仓库里的组件可能匹配不到；
• 镜像来源需可被当前环境拉取，私有 registry 需要提前配置好认证。