Trivy 默认不扫描基础镜像层漏洞，因仅检查最上层构建内容；需显式添加 --security-checks vuln 才启用完整漏洞扫描，否则仅做配置检查。
trivy image 扫描时为什么总漏掉基础镜像层漏洞？
因为 trivy image 默认只扫描最上层镜像，不递归分析 base 镜像（比如 debian:12 或 alpine:3.20），除非显式启用 --scanners vuln 并配合 --security-checks vuln（旧版本需加 --skip-update 避免超时）。
常见错误是直接跑 trivy image myapp:latest 就以为全量覆盖了——实际只扫了你构建层新增的二进制和包，底层 OS 漏洞大概率被跳过。
- 必须加
--security-checks vuln，否则默认只做 misconfiguration 扫描 - CI 中建议固定 trivy 版本（如
v0.45.0），新版对 multi-stage 构建层识别更准 - 若用
FROM scratch或 distroless 镜像，vuln扫描会失效，得切到fs模式扫文件系统 - 网络受限环境务必加
--offline-scan --db-repository file:///path/to/trivy-db，否则首次运行卡死在下载漏洞库
trivy fs 扫描容器镜像解压目录时路径怎么选才不报错？
trivy fs 不接受 tar 包或镜像名，只认已解压的 rootfs 目录结构，且要求 /usr/bin、/etc/os-release 等关键路径存在。直接解压 docker save 出来的 tar 会得到多层 manifest+layer，不能直接喂给 trivy fs。
正确做法是先用 skopeo copy 或 umoci unpack 提取干净的 rootfs，或者用 docker create && docker export 蹲点导出：
- 推荐命令：
docker create --name tmp myapp:latest && docker export tmp | tar -C /tmp/rootfs -x - 扫描前检查：
ls /tmp/rootfs/etc/os-release和ls /tmp/rootfs/usr/bin必须存在 - 若目标是 Alpine 镜像，
trivy fs可能因缺少/etc/os-release降级为 generic 检测，误报率升高 - 避免用
tar -xf直接解压镜像 tar 包——它包含多个 layer 子目录，trivy fs会找不到系统标识而退出
trivy config 扫描 Kubernetes YAML 时哪些字段会被忽略？
trivy config 实际只解析 kind: Deployment、StatefulSet、Pod 等 workload 类型，对 ConfigMap、Secret、CustomResourceDefinition 默认跳过，除非加 --config-policy 指定 OPA 策略。
它也不校验 Helm 渲染前的模板（.yaml.gotmpl），只吃最终生成的 YAML 字符串；Kustomize 的 base/overlay 结构若没提前 kustomize build，也会漏检。
- CI 中务必先执行
kustomize build . > full.yaml，再传给trivy config full.yaml - 敏感字段如
env.valueFrom.secretKeyRef不报密钥泄露，但env.value明文密码会被标为CFG002 - 不支持
initContainers的 securityContext 继承检测，得单独提 issue 或补策略 - 若 YAML 含 Go template 语法（
{{ .Values.replicas }}），trivy config会直接解析失败，报yaml: unmarshal errors
CI 中并行跑 trivy image/fs/config 怎么避免重复拉镜像和 DB？
每个 trivy 命令默认独立初始化缓存，同一 runner 上多次运行会反复下载 GB 级漏洞数据库、重复 pull 镜像层——不是慢，是可能触发 registry 限流或磁盘爆满。
核心是复用三样东西：trivy binary、vuln DB、镜像 layer cache。GitHub Actions 或 GitLab CI 都得手动挂载 volume 或设置 TRIVY_CACHE_DIR。
- 统一设环境变量：
TRIVY_CACHE_DIR=/tmp/trivy-cache，所有 job 共享该目录 - 用
trivy image --download-db-only预热 DB，再让其他 job 加--skip-db-update - 对
trivy image，加--input指向本地docker save输出的 tar，避免重复 pull - GitLab CI 示例：
before_script: - docker save myapp:latest > /tmp/myapp.tar，后续trivy image --input /tmp/myapp.tar
trivy 的漏洞库更新机制和镜像层缓存逻辑是松耦合的，不手动干预就等于每次都在裸跑——尤其在自建 registry + air-gapped 环境里，这点最容易被当成“trivy 很慢”甩锅给工具本身。
