制品漏洞扫描是什么
制品漏洞扫描对镜像、依赖包等内容比对已知漏洞库，输出结构化结果（漏洞、严重级、修复版本）。有效做法是「多点位配合」：构建后扫描做快速反馈、仓库入库扫描控存量、部署准入做最后防线；再加一个周期性重扫——漏洞库每日更新，历史制品不能只信构建那天的结果。阻断策略按严重级与「是否存在修复版本」分级：有修复版本的高危必须阻断，无修复版本的要进跟踪与缓解流程，而不是无限期卡住发布。
基本信息
| 工具 | Trivy、Grype、Clair、云仓库自带扫描 |
|---|---|
| 阈值 | 按严重级与「是否存在修复版本」定阻断策略 |
| 重扫 | 漏洞库每日更新：历史制品需定期重扫，不能只信构建时结果 |
| 点位 | 构建后 / 仓库入库 / 部署准入 三层配合 |
典型使用场景
- 构建门禁：高危且可修复的漏洞直接让流水线失败，缺陷在合入前暴露。
- 仓库侧扫描：镜像推送时自动扫描，存量资产定期刷新风险视图。
- 部署准入：集群侧拦截含高危漏洞的镜像，作为最后一道防线。
- 新漏洞响应：披露后重扫全部在用制品，定位受影响版本范围。
- SBOM 联动：保留扫描结果与物料清单，快速回答「这个 CVE 影响哪些服务」。
Trivy 示例
Trivy 示例
# 构建后扫描, 高危直接失败
trivy image --severity HIGH,CRITICAL --exit-code 1 registry.example.com/app:1.8.0
# 产出 SBOM 供后续定位
trivy image --format spdx-json -o app.spdx.json registry.example.com/app:1.8.0扫描点位对比
| 点位 | 时机 | 作用 |
|---|---|---|
| 构建后 | 流水线内 | 最快反馈，阻断新问题 |
| 仓库入库 | 推送时 | 控制存量与历史版本 |
| 部署准入 | 部署前 | 最后防线，兜底 |
| 定期重扫 | 周期性 | 应对新披露漏洞 |
把扫描结果（与 SBOM 对应）纳入制品元数据：新漏洞披露时可快速定位受影响版本。
维护豁免清单：正在修复或经评估不受影响的漏洞要登记原因与到期时间，否则阻断规则被无视、扫描结果被整体忽略。