扫描报告里列出一长串 CVE，并不等于每一条发行版都已经给出补丁。自己构建、自己有权限查看的镜像扫完之后，对照报告看哪些是官方标了能修的。这里只扫自己有权限的镜像，不拿扫描结果去打别人的系统，也不把扫描器当成漏洞利用教程。
Trivy 的 README 把它写成通用的安全扫描器，扫描目标包括容器镜像、文件系统、远程 Git 仓库、虚拟机镜像和 Kubernetes。查找内容包括操作系统软件包和依赖（SBOM）、已知漏洞（CVE）、基础设施即代码里的配置问题、敏感信息和密钥，以及软件许可证。用户指南的入口是 User Guide。通用用法在 README 里写成 trivy <target> [--scanners <scanner1,scanner2>] <subject>。扫自己的镜像，命令写在 Container Image 里：trivy image 后面跟上自己的镜像名和标签即可。文档把容器镜像的扫描对象分成两类：镜像里面的文件，以及镜像元数据。对文件而言，默认会做漏洞扫描和密钥扫描。如果只想看漏洞，可以加上 --scanners vuln。镜像配置上的错误配置和密钥扫描默认是关的，需要时再按文档打开 --image-config-scanners。安装不要走已经失效的旧路径，当前说明在 Installation。README 也列了常见装法，例如 brew install trivy、docker run aquasec/trivy，或按 README 的说明，到 GitHub Releases 下载二进制。把镜像名换成自己构建、自己有权限查看的那一份，不要拿它去扫别人的仓库或别人的主机。
跑完之后，对照报告里的汇总和明细，才能分清哪些条目是发行版已经给出修复的。Reporting 的表示例里，前面会给出各扫描目标的条数汇总，后面的明细表通常包含 Library、Vulnerability ID、Severity、Status、Installed Version、Fixed Version、Title 这些列。对照 Vulnerability 的说明，Fixed Version 有值，表示当前发行版给出了补丁版本。Status 为 fixed 时，官方解释是该漏洞在这个平台上已经有修复。把 Installed Version 和 Fixed Version 放在一起看，就能知道自己镜像里装的是哪一版、官方认为该升到哪一版。反过来，文档把 unfixed/unfixable 写成：发行版还没有提供补丁。这类条目即便严重级别看起来不低，也不等于马上就能升级修掉。严重级别本身也要看报告里怎么标：文档说明会优先采用发行商数据源里的评级，因为它往往比 NVD 更贴近该发行版的实际编译和默认配置。数据源没提供时，再按 CVSS 分数换算。JSON 报告里可以用 SeveritySource 看到这一条用的是哪家评级。输出 JSON 时，官方还提醒：VulnerabilityID、PkgName、InstalledVersion 和 Severity 一般会有值，其他字段则可能为空，所以不要假定每一行都有完整的 Fixed Version。
想只留下官方认为能修的项，可以用 --ignore-unfixed。Filtering 写明，这是 --ignore-status affected,will_not_fix,fix_deferred,end_of_life 的简写，效果是只显示 status 为 fixed 的漏洞。也可以自己用 --ignore-status 按状态筛，或用 --severity 按严重级别收窄，例如只保留 HIGH,CRITICAL。状态含义看官方列表：affected 是受影响但尚未发布补丁，will_not_fix 是受影响但目前不打算修，fix_deferred 是受影响、将来可能会修，end_of_life 是包里有相关组件、但没有做受不受影响的分析。unknown、not_affected、under_investigation 这几个状态，官方说根本不会被检测出来，只是为了完整才列在文档里。部分状态只在有限的发行版上提供，文档表格里 Debian、RHEL 和其他发行版的支持范围并不完全一样。
某一条 CVE 能不能修，只看那份扫描报告里的 Fixed Version、Status，以及发行版自己的说明，不要另外编一个修复比例。随后按官方给出的修复版本去升级软件包，或更换自己有权限维护的基础镜像。扫描对象仅限于自己构建、自己有权限查看的镜像。
你们扫完是 Fixed Version 已经有值、准备升级依赖，还是不少条目根本没有补丁版本？