给镜像和 IaC 加安全闸时，我会先用 Trivy 把扫描结果分层

很多团队把安全扫描接进 CI 时，容易只留一个 trivy image 命令。短期能挡住明显漏洞，时间一长就会出现三个问题：源码依赖、容器镜像和基础设施配置各扫各的，报告格式不统一，修复优先级靠临场判断。Trivy 值得放进这个位置评估，因为它把漏洞、配置错误、secrets、license 和 SBOM 等扫描能力收在同一个开源 CLI 里，目标也覆盖 container image、filesystem、git repository、Kubernetes 与 IaC 配置。对小团队来说，先统一入口，再分层治理，收益会比堆更多单点工具更直接。

仓库源码、容器镜像、IaC 配置进入 Trivy 扫描并沉淀为修复队列的流程示意。 来源：Codex image generation

先把目标分成三条线

第一条线是仓库源码。用 filesystem 或 repository 扫描 package lock、配置文件和脚本目录，可以在构建镜像前发现依赖漏洞、误提交的 secrets 和 IaC 配置问题。它适合放在 pull request 阶段，反馈要快，输出要能指向文件和规则。

第二条线是容器镜像。镜像扫描关注基础镜像、系统包、语言包和最终运行层。这里不要只看漏洞数量，还要看严重级别、是否有修复版本、是否来自运行时真正会带上的层。把镜像扫描放在构建后、推送前，可以避免问题进入 registry 后再返工。

第三条线是 IaC 和 Kubernetes 配置。Trivy 的 misconfiguration 扫描能检查 Terraform、Dockerfile、Kubernetes 等配置风险。这个阶段更像架构审查的自动化前置项，重点是把高风险端口、特权容器、过宽权限和缺失限制提前拦住。

阈值要写成治理规则

扫描工具最大的落地难点是噪音。我的做法是把阈值写进 CI 规则：先让 critical 和 high 阻断合并，把 medium 进入修复队列，把 low 留给周期性清理。对于历史项目，可以先生成 baseline 或忽略清单，但每条忽略都要有到期时间、负责人和理由。这样团队不会被老问题拖住，也不会让新问题混进旧债里。

输出格式也要提前定好。PR 阶段适合简洁表格或 SARIF，便于代码托管平台展示。发布阶段适合保留 JSON 或 CycloneDX SBOM，方便后续审计、镜像追踪和依赖盘点。Trivy 支持多种 report format，正好可以让同一次扫描服务不同读者。

CI 执行成本也要纳入设计。漏洞数据库下载、镜像拉取和多平台构建都会拉长反馈链路，所以我会把快速扫描放在 PR，把完整扫描放在夜间或发布前。缓存目录、扫描目标和失败阈值都写清楚，后续排查才知道慢在哪里、该删哪一步、该保留哪份报告。

报告要服务修复队列

安全报告不能只停在 CI 红叉。每次失败至少要留下四类信息：目标来源、扫描命令、命中的规则或 CVE、建议修复路径。依赖漏洞优先看升级版本，镜像漏洞优先看基础镜像更新，配置错误优先回到模块模板修。把这些信息写进 issue 或修复队列后，安全扫描才会变成持续治理动作。

适合怎样落地

第一周我会只接只读扫描。先对仓库跑 filesystem 扫描，再对主镜像跑 image 扫描，最后把 Dockerfile 或 Terraform 放进 misconfiguration 扫描。第二周再接 GitHub Action 或现有 CI，把阻断阈值限定在 critical 和 high。等修复队列稳定后，再加入 secrets、license 和 SBOM 输出。这个顺序足够保守，也能让团队清楚看到 Trivy 在代码、镜像和配置三层各自承担什么责任。

主要来源

Trivy 官方文档: https://trivy.dev/latest/docs/

Trivy GitHub 仓库: https://github.com/aquasecurity/trivy

Trivy Releases: https://github.com/aquasecurity/trivy/releases

Trivy GitHub Action: https://github.com/aquasecurity/trivy-action