trivy 扫描失败主因是镜像未本地拉取或未配 --remote 参数；grype 漏洞扫描不准多因数据库缓存过期；两者差异源于数据源、包识别及默认范围不同；CI 中需预更新数据库、设超时、指定 platform。
trivy scan 报错 failed to analyze image 或找不到镜像
本地没拉取镜像时，trivy 默认不会自动 pull，直接报这个错。它只查本地镜像仓库（docker images 能看到的），不连远程 registry。
- 先确认镜像是否存在：
docker images | grep your-image-name - 不存在就手动拉取：
docker pull nginx:1.25，再跑trivy image nginx:1.25 - 想跳过本地检查、直连 registry（比如私有仓库），得加
--remote参数，并配好TRIVY_REGISTRY_AUTH环境变量，否则认证失败 - 用 tag 扫描比用 image ID 更稳——
trivy image sha256:abc...在某些版本里会解析失败
grype 为什么扫不出 CVE-2023-XXXX 这类新漏洞
grype 默认用本地缓存的漏洞数据库（~/.cache/grype/db），不是实时联网查。如果缓存超过 5 天（默认 TTL），它会静默跳过更新，继续用旧数据。
- 强制刷新数据库：
grype db update，成功后看到updated successfully才算生效 - 扫描时加
--fresh可跳过缓存直接更新再扫，但会拖慢单次执行（适合 CI 中确保最新） - 注意：
grype不支持私有 registry 的匿名访问，扫私有镜像必须提前docker login，否则报unauthorized - 它对 multi-platform 镜像支持弱，
grype docker:your-registry/app:latest可能默认选错 platform，建议显式指定--platform linux/amd64
trivy vs grype：同一镜像扫描结果差异大怎么办
差异主要来自三块：漏洞数据源、包识别逻辑、默认扫描范围。不是谁“更准”，而是策略不同。
-
trivy默认启用 OS 包 + language-specific（如package-lock.json）扫描；grype默认只扫 OS 包，要加--scope all-layers和--add-cpes-if-none才接近 trivy 行为 -
trivy用的是ghcr.io/aquasecurity/trivy-db，grype用的是anchore/grype-db，CVE 收录节奏和映射规则不一样 - 两者对 musl libc（Alpine）的识别准确率都偏低，
trivy可能漏掉apk包依赖链中的间接漏洞；grype对go mod生成的go.sum解析更细，但需要镜像里真有该文件 - 别直接比“漏洞数”，先用
--format json导出，按CVE字段去重再对比
CI 流水线里怎么避免扫描卡住或超时
容器镜像扫描在 CI 里容易变成瓶颈，尤其拉取基础镜像+解压+数据库加载全挤在单步里。
立即学习“Python免费学习笔记（深入）”；
- 把数据库更新拆成前置 job：
grype db update或trivy --download-db-only，缓存~/.cache/trivy/db目录 -
trivy加--timeout 5m防死等；grype没原生 timeout，得靠 shell 层包装：timeout 300 grype ... - 跳过非关键层：用
trivy image --security-checks vuln关掉config和secret检查（除非你真需要） - 小镜像（grype 通常快 2–3 秒；大镜像（>500MB）
trivy的并行解压优势明显，但得确认TRIVY_CACHE_DIR不在 tmpfs 上，否则反复重建缓存反而更慢
