grype与sbom包名/版本不匹配主因是默认宽松匹配策略，需配合--scope all-layers、--add-cpes-if-none、--version-pattern loose等参数，并确保syft生成sbom时保留cpe/purl字段。
grype 扫描结果和 SBOM 中的包名/版本对不上怎么办
根本原因是 grype 默认用“宽松匹配”查漏洞库，它会把 github.com/sirupsen/logrus 当成 logrus，把 v1.9.3 归到 1.9.x 范围里 —— 但你的 SBOM 可能写的是完整模块路径或带 +incompatible 后缀的版本，一匹配就漏报。
- SBOM（如 CycloneDX JSON）里写的
name字段如果是 Go module path（如golang.org/x/net），得确保grype开启了--scope all-layers并配合--add-cpes-if-none补全上下文 - 版本字段含
rc、beta、dev等预发布标识时，grype默认不认为它们等价于正式版，必须加--version-pattern loose - 若 SBOM 来自
syft，检查是否用了-q（quiet mode）导致cpe和purl字段被裁剪；建议固定用syft packages -o cyclonedx-json --file sbom.json生成
grype vulnerability-db 更新后扫描结果反而变少
不是 db 损坏了，而是新 db 默认启用更严格的 CPE/PURL 解析策略：旧版可能把 openssl 错标成 libssl 而误报，新版修掉后“看起来”漏了，其实是去噪。
- 运行
grype db status确认当前 db 是不是最新（last-updated时间戳 +schema-version: 2） - 对比前后差异，用
grype your-image:tag --output json | jq '.matches[] | select(.vulnerability.id | contains("CVE-2023"))'抽样查特定 CVE 是否还在 - 如果确实少了，先关掉严格模式试下：
grype your-image:tag --ignore-policy grype-ignore.yaml --fail-on medium，其中grype-ignore.yaml临时加一条exclude: {cpe: "*"}强制退回到 PURL-only 匹配
如何让 grype 基于本地 SBOM 文件做离线精准匹配
grype 本身不直接读 SBOM 文件扫描，它只接受镜像、目录或 syft 输出的 JSON；所谓“基于 SBOM”，本质是复用 syft 的解析结果，跳过重新提取包信息。
- 先用
syft your-image:tag -o json > sbom.json导出，确保没加--exclude过滤掉语言层 - 再用
grype sbom:./sbom.json --only-fixed（注意前缀是sbom:，不是file:） - 关键参数：
--distro必须显式指定（如ubuntu:22.04），否则 Go/Python 包可能因缺失发行版上下文而无法关联 CVE - 若 SBOM 含多架构镜像信息，
grype默认只处理amd64，需加--platform linux/amd64显式对齐
grype 扫描 Java JAR 包时 CVE 匹配率低的常见原因
Java 生态的组件识别最混乱：同一个 commons-collections 在 Maven Central、JFrog、甚至 vendor patch note 里坐标、版本格式、打包方式全都不统一，grype 靠 purl 和 cpe 双轨匹配，任一环节断就丢。
- 确认
syft提取时用了--scan-depth 5（默认为 1），否则嵌套 JAR（如spring-boot-loader里的lib/*.jar）不会被解压分析 - 检查
sbom.json中每个component是否有packageUrl字段；没有的话，grype无法生成有效purl，只能靠文件名猜，准确率暴跌 - 遇到
org.apache.logging.log4j:log4j-core这类带 scope 的坐标，要确保grype版本 ≥ 0.75.0 —— 旧版会截断冒号后内容，当成log4j-core单独查库，完全失准
真正卡住精度的，往往不是 db 新不新，而是 SBOM 里那个 purl 字段有没有生成、生成得对不对；别急着调 grype 参数，先用 jq '.components[] | select(.purl == null)' 扫一遍空值。
