Trivy 使用方式与典型场景
使用方式与典型场景
下面这些命令可以直接复制。注意所有示例的前提是：只扫描自有镜像与自己拥有、或已获得书面授权扫描的制品。扫描第三方公共镜像做学习研究可以，但把它接进自动化流程去批量扫别人的制品、或把扫描结果对外发布，都不在授权范围内。
示例一：CI 里构建完立刻扫，卡 CRITICAL 门禁
思路是先把噪音收敛掉再卡门禁：先用 --ignore-unfixed 去掉无法修复的，再只看 CRITICAL，这样门禁不会天天误伤，团队才愿意留它。第一次上线建议先用 --exit-code 0 跑一周观察，确认基线之后再切到 1。
# 构建
docker build -t my-registry/my-app:$CI_COMMIT_SHA .
# 观察期：只出报告，不阻断
trivy image --severity CRITICAL,HIGH --ignore-unfixed \
--format table --exit-code 0 my-registry/my-app:$CI_COMMIT_SHA
# 正式门禁：CRITICAL 且可修复的，直接挡下
trivy image --severity CRITICAL --ignore-unfixed \
--exit-code 1 --format table my-registry/my-app:$CI_COMMIT_SHA如果同时想把结果传进代码扫描面板，加一份 SARIF 输出即可：
trivy image --format sarif --output trivy-results.sarif \
--severity HIGH,CRITICAL my-registry/my-app:$CI_COMMIT_SHA示例二：生成 CycloneDX SBOM 并交给下游复用
SBOM 的价值在于「一次解包，多处比对」。镜像构建时生成一份 SBOM 存档，后续合规审查、事故追溯、或换扫描器时都可以直接拿它比对漏洞，不需要重新拉镜像。
# 生成 SBOM 并存档
trivy image --format cyclonedx --output my-app.cdx.json \
my-registry/my-app:$CI_COMMIT_SHA
# 下游直接拿这份 SBOM 扫漏洞
trivy sbom --severity CRITICAL,HIGH --ignore-unfixed my-app.cdx.json
# 需要 SPDX 格式（部分合规流程要求）
trivy image --format spdx-json --output my-app.spdx.json \
my-registry/my-app:$CI_COMMIT_SHA示例三：.trivyignore 写 CVE 编号 + 到期日 + 责任人
忽略文件是最容易被滥用的功能。没有到期日的忽略文件，一年后就是一份没人记得为什么存在的永久白名单。正确的写法是每条都带到期日，注释里写清楚责任人和理由，并且在到期前必须有人重新评审。
# .trivyignore
# 格式：CVE 编号 + exp: 到期日（较新版本支持，具体语法以官方文档为准）
# 定期复核：每季度一次，到期项必须重新评估或修复
# 该组件在运行时路径不可达，暂无法升级，责任人：张三
CVE-2023-12345 exp:2026-06-30
# 上游已确认不修复，等下一版大版本，责任人：李四
CVE-2023-67890 exp:2026-09-30使用时显式指定文件，避免有人误改默认文件：
trivy image --ignorefile ./.trivyignore --severity HIGH,CRITICAL my-app:ci示例四：源码目录顺带查密钥与配置
密钥扫描是唯一一个「顺手做、收益极大」的功能。它不需要漏洞库，因此在离线环境里也能跑，非常适合放进 pre-commit 或 MR 流水线。
# 扫源码目录：依赖漏洞 + 写死的密钥
trivy fs --scanners vuln,secret .
# 只查密钥，并只输出 HIGH 以上
trivy fs --scanners secret --severity HIGH,CRITICAL .
# 检查 IaC 配置（Terraform / K8s YAML / Dockerfile）
trivy config ./deploy
trivy config --severity HIGH,CRITICAL ./terraform适合与不适合的场景
适合：CI 门禁、镜像发布前体检、IaC 配置检查、密钥兜底扫描、SBOM 生成与合规留档、离线内网的周期性扫描。这些场景的共同点是目标明确、只需一次执行、结论用退出码表达。
不适合：需要实时拦截运行时行为（那是运行时安全工具的事）；需要给出代码级修复补丁（Trivy 只告诉你哪个包要升到哪个版本）；需要长期集中式策略中心与多租户看板（那是平台化产品的领域）。另外，Trivy 不做动态分析，它能发现「这个版本的库有已知漏洞」，但发现不了「这个漏洞在你的业务逻辑里能不能真的被打通」，这一层要靠人工或 VEX 判断。
