Trivy 容器扫描器

容器镜像里的漏洞是怎么漏进生产环境的

CI 里常见的做法是构建、推镜像、上线。如果安全检查没有明确插在某个阶段，很容易出现三类问题：

• 基础镜像里的 OS 包已发布高危公告，但流水线没有阻断。
• 依赖层存在已知 CVE，团队却缺少可机读的报告来定位是哪一个层级引入的。
• 即使本地扫过，也没有可追溯的证据说明这个镜像 tag 对应哪次扫描结果，或是由哪个作业生成的。

对需要过审计的团队来说，靠截图或零散日志并不够用。

这个技能怎么工作

@user_3c6cb52e/trivy-container-scanner-2 把 Trivy CLI 封装成可调用的扫描动作，核心链路是：

• 针对容器镜像执行漏洞扫描。
• 生成 SARIF 格式结果，方便接 GitHub Code Scanning API。
• 生成 OCI artifact attestation，让“某个镜像对应某次扫描结果”可以被验证和追溯。

适合的场景包括：

• PR 或主干流水线中的安全门禁，利用 SARIF 在 GitHub 侧展示问题。
• 构建后为镜像生成证明，作为供应链审计的一部分。
• 排查问题时快速拿到结构化清单，而不是人工翻包。

适用边界与注意点

• 上游能力来自 Trivy CLI；实际覆盖范围取决于上游扫描器和漏洞库。
• 集成前先确认运行环境能否访问镜像仓库、漏洞数据源和目标 artifact registry。
• SARIF 和 Code Scanning 的配置属于流水线工程细节，需要按仓库权限和 workflow 边界调整。
• OCI attestation 要配合支持该机制的运行时或注册表使用，否则证明本身只是文件。