项目地址：https://github.com/aquasecurity/trivy 定位：开源全栈安全扫描器——容器镜像、文件系统、Git 仓库、IaC、SBOM 一把抓，CNCF 沙箱项目（Aqua Security 出品）。
| 元信息 | 说明 |
|---|---|
| 语言 | Go（单二进制，零依赖） |
| 星标 | 20k+ ⭐ |
| 协议 | Apache 2.0 |
| 扫描对象 | 镜像 / 文件系统 / SBOM / IaC(Terraform/CF/K8s) / 秘密(密钥泄漏) |
1、背景：软件供应链安全全景
一次"从代码到生产"的旅程中，风险埋在每一层：
代码 ──> 依赖包 ──> 构建 ──> 镜像 ──> 部署清单 ──> 运行
│ │ │ │ │
秘密泄漏 CVE 漏洞 构建环境 系统包漏洞 IaC 配置错误
硬编码密钥 供应链投毒 不可信源 配置不当 过宽权限/明文Secret
Trivy 的野心：用同一个工具覆盖上面每一格。它没有把每类问题做成独立产品，而是共享"扫描器内核 + 数据库"的统一架构——这在开源安全工具里是工程克制的好例子。
2、核心能力与原理
2.1、镜像扫描：漏洞检测的流水线
trivy image nginx:1.27
内部分四步：
① 解包镜像层：镜像 = OCI 层压缩包 + 配置 manifest
（不 pull 全量，按需解压到临时目录）
② 提取"软件资产清单"：识别各发行版的包管理数据库
dpkg(Debian) / rpm(RedHat) / apk(Alpine)
+ 语言生态：pip/gem/npm/cargo/go modules…
③ 生成 SBOM（CycloneDX/SPDX 格式）
④ 匹配漏洞数据库：包名+版本 → CVE/NVD/GHSA/OSV 元数据
输出：CVE ID、严重级、修复版本、有无 exploit（KEV）
数据库更新机制：内置 vuln DB 首次使用自动下载（trivy image --download-db-only 可预热），之后增量更新——CI 环境建议挂缓存卷或用 OCI registry 分发 DB（--db-repository）。
2.2、不止 CVE：四类扫描器
| 子命令 | 扫什么 | 数据源 |
|---|---|---|
trivy image |
镜像内 OS 包 + 语言依赖 CVE | NVD/GHSA/OSV/RHEL/Debian advisories |
trivy fs --scanners secret |
Git 仓库里的密钥泄漏 | 内置 40+ 规则（AWS key/私钥/token） |
trivy config |
IaC 配置错误 | 内置策略库（等价 checkov/tfsec 融合） |
trivy kubernetes |
集群内工作负载+镜像+IaC 三合一 | API Server 观测 |
统一输出：--format json/table/sarif/cyclonedx，SARIF 直接对接 GitHub Code Scanning——扫描结果的"格式标准化"是能进 CI 的前提。
2.3、SBOM：供应链的"配料表"
trivy image --format cyclonedx --output sbom.json myapp:latest
trivy sbom sbom.json # 用 SBOM 复扫，不用再碰镜像
SBOM 的战略价值：当 log4shell（CVE-2021-44228）这类"依赖海啸"爆发时，有 SBOM 的团队 5 分钟列出受影响资产清单，没有的团队翻三天代码仓库。美国行政令 14028 后，SBOM 已是采购合规硬指标，格式标准（SPDX/CycloneDX）值得每个架构师认识。
3、快速上手：接入 CI/CD
# .github/workflows/security.yml —— 镜像构建即扫描
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build
run: docker build -t myapp:ci .
- name: Trivy scan
uses: aquasecurity/trivy-action@master
with:
image-ref: myapp:ci
format: sarif
output: trivy.sarif
exit-code: 1 # 有高危即失败
severity: CRITICAL,HIGH
ignore-unfixed: true # 只看有修复版本的
- uses: github/codeql-action/upload-sarif@v3
if: always()
with: { sarif_file: trivy.sarif }
本地开发常用组合：
trivy fs --scanners vuln,secret,config . # 一次扫全项目
trivy image --severity HIGH,CRITICAL --ignore-unfixed app:tag
trivy kubernetes --report summary cluster # 扫线上负载
4、生产实践清单
- 策略分级，而非一刀切：CI 阻断只卡 CRITICAL+有修复版本（
ignore-unfixed），HIGH 进周报跟踪，MEDIUM 以下忽略——否则 CVE 噪声会让团队麻木，扫描沦为形式； - 基线管理：
.trivyignore文件收录"评估后接受"的漏洞（带理由注释），随代码评审——豁免也是资产，要审计； - 缓存加速 CI：DB 缓存卷挂载或
--skip-db-update+ 定时任务预热；大仓库用--offline-scan配离线 DB； - 镜像瘦身是最好的加固：distroless/scratch 基础镜像直接消灭整类 OS CVE；多阶段构建让"构建工具链"不进产物——扫描是兜底，减少攻击面才是上游；
- 运行时扫描别忘：
trivy kubernetes（或 K8s admission 集成）扫"已经跑着的"镜像——CI 只管增量，存量资产靠定期巡检； - 密钥泄漏是最高优先级：vulnerability 有窗口期，泄漏的 AWS key 是分钟级被扫走——secret 扫描设为 PR 必检。
5、横向对比
| 工具 | 定位 | 优势 | 局限 |
|---|---|---|---|
| Trivy | 全栈扫描 | 单二进制、覆盖广、SBOM、CI 友好 | 深度策略弱于专业工具 |
| Grype | 镜像/SBOM 漏洞 | 与 Syft 生态协同 | 无 IaC/secret |
| Snyk | 商业全家桶 | 修复建议/PR 自动化 | 收费、数据闭源 |
| Clair | 镜像仓库侧 | 集成 Harbor 体验好 | 只做镜像 |
| checkov | IaC 深度策略 | 策略库丰富 | 单一场景 |
Trivy 的策略是"80 分的全能"——对绝大多数团队，一个工具进 CI 的执行率，远胜五个专家工具躺在选型文档里。
6、深挖：CVE 数据从哪来（扫描器的天花板）
漏洞情报链路：上游（NVD/CVE 编号机构/GHSA/发行版安全公告）→ 聚合商（OSV/Trivy DB）→ 扫描器匹配。两个现实：
- 误报与漏报并存：包改名（Debian backport）、版本号歧义（Go module 伪版本）会造成误报；仓库未收录的新漏洞是漏报——扫描结果是概率性情报，不是真理；
- 有 CVE ≠ 有风险：要看"路径可达性"（依赖在不在运行时 classpath）与"exploit 可用性"（KEV 列表）。成熟团队的处理流程：扫描 → 分诊（利用可能性/暴露面）→ 修复排期，而不是见红就救火。
7、常见问题
- Q：扫出 500 个漏洞怎么下手？ A：先按
--ignore-unfixed+--severity CRITICAL收敛到个位数；再看 KEV（已知被利用）优先；最后评估修复成本（升版本 vs 升基础镜像）。分诊能力比扫描能力重要。 - Q：SBOM 该在哪生成、存哪里？ A：构建时生成（CI 里
trivy image --format cyclonedx），随制品归档到制品库（Harbor attach 或对象存储），并记录"镜像 digest ↔ SBOM"映射——事件响应时的检索键是 digest。 - Q：和 Falco/Wazuh 什么关系？ A：时间轴不同——Trivy 管"部署前的静态风险"，Falco 管"运行时行为异常"（进程逃逸、文件篡改），Wazuh 管主机层（HIDS）。完整方案三层都要，Trivy 只负责左移。
8、总结
Trivy 把供应链安全从"安全团队的专业活"变成"每个工程师流水线里的一步"。它的产品哲学值得学习：统一内核、标准输出、零依赖分发。落地路线建议：CI 镜像扫描（一周）→ 秘密与 IaC 扫描（两周）→ SBOM 归档（一个月）→ 运行时巡检常态化。安全左移不是口号，是每次 push 多跑 30 秒。
