Trivy 容器镜像漏洞扫描器

问题：漏洞往往在镜像构建完成后才被发现

容器镜像是一层一层叠出来的：基础镜像里的包管理器层、应用层的语言依赖、再加上团队自己打进来的层。传统做法是等镜像推到仓库、甚至已经在生产里跑起来之后，再由安全同学人工抽查，或者干脆等到被通报。到那时漏洞已经存在数天甚至数周，回滚和重建的成本都很高。

更麻烦的是，同一个镜像里同时存在操作系统包和语言依赖两类风险来源。扫描结果如果只是一份原始 JSON，很难快速回答「哪些是今天必须修的」。

这个技能做了什么

该技能把 Aqua 出品的 Trivy 封装成一次可调用的扫描动作：输入一个 Docker 或 OCI 镜像引用，输出整理好的漏洞表。核心流程分三步：

• 拉取并解包镜像：读取 manifest 与各层内容，还原文件系统，同时识别容器运行时与 SBOM 相关信息。
• 识别依赖面：匹配操作系统包管理器（如 apt、rpm、apk），以及各语言生态的依赖清单，例如 requirements.txt、package-lock.json、go.mod。
• 关联漏洞库并输出：将每个依赖与漏洞数据库比对，输出包含 CVE 编号、CVSS 评分、命中包名与可用修复版本的表格，支持按严重程度筛选。

修复版本这一列是值得写进流水线的关键字段：当修复版本存在时，这条漏洞通常可以通过升级依赖解决；当字段为空或缺失时，往往意味着要等待上游补丁、绕过该依赖，或者调整实现方式。

适用边界与注意点

• 只扫镜像，不扫运行态：Trivy 检查的是固化在镜像层里的静态内容，不覆盖运行时的文件变更、密钥泄露或配置错误。
• 检出能力依赖漏洞库时效：数据库更新越及时，结果越可靠，扫描前应确认库处于最新状态，否则 clean 的结论并不可信。
• 上游存在 canary 构建：Trivy 会通过 Docker Hub、GitHub 与 ECR 等渠道发布 canary 版本，使用时应明确自己依赖的是哪个渠道，避免不同构建之间行为不一致。
• 修复版本字段不是绝对保证：部分漏洞在上游尚未发布补丁，字段可能为空，此时仍需结合业务风险决定是否先阻断发布。