Docker Clair 已于 2023 年归档停更，Clair v4 是最后版本，不再更新 CVE 数据或支持新特性；推荐改用 Docker Scout、Trivy 等现代方案实现镜像安全阻断。
注意：Docker Clair 已于 2023 年正式归档（deprecated），官方停止维护，Clair v4 是最后一个主要版本，后续不再提供 CVE 数据更新、镜像解析支持或安全策略扩展能力。当前企业级镜像安全阻断流水线应使用现代替代方案——Docker Scout（官方推荐）、Trivy（CNCF 毕业项目）、Snyk Container 或 Anchore Engine。
如果你在现有系统中仍需兼容 Clair（如遗留审计要求），以下内容基于 Clair v4 + PostgreSQL + HTTP API 的典型部署逻辑展开，但不建议用于新建设施；文末会明确给出更安全、可落地的现代替代路径。
一、Clair v4 核心组件与阻断逻辑原理
Clair v4 不再是单体服务，而是由三个解耦组件构成： - clairctl：命令行工具，用于本地扫描镜像并提交报告 - claircore：数据层，负责从 NVD、Red Hat、Ubuntu 等源同步漏洞元数据（需定期 cron 更新） - clairv4 API server：接收镜像上传（以 OCI tar 形式）、触发分析、返回 JSON 报告（含 CVE ID、CVSS 分数、影响包、修复建议）阻断不是 Clair 自带能力，而是通过 CI/CD 流水线调用其 API 后，由脚本解析响应结果实现：
- 若返回 critical/high 漏洞数量 > 0 →
exit 1→ 中断构建或推送 - 若所有漏洞 CVSS ≤ 4.0 → 允许进入下一阶段
关键限制：Clair v4 无法扫描多阶段构建中的 builder 阶段层；不支持 SBOM 导出；不识别 Go/Rust 二进制依赖中的漏洞。
二、最小可行阻断流水线配置（Clair v4 兼容版）
假设你已部署好 Clair v4（含 PostgreSQL 和 updater 定时任务），CI 流程中加入如下检查环节：# 1. 构建镜像并保存为 tar（避免推送到仓库后再扫描，节省时间） docker build -t myapp:ci . && docker save myapp:ci > myapp-ci.tar # 2. 使用 clairctl 提交扫描（需提前配置 CLAIR_ADDR 和 TLS 证书） clairctl --insecure --local myapp-ci.tar # 3. 解析结果，阻断高危镜像 if clairctl report --format json myapp:ci | jq -r '.Vulnerabilities[] | select(.Severity == "Critical" or .Severity == "High")' | head -1; then echo "❌ 阻断：发现 Critical/High 漏洞，终止部署" exit 1 else echo "✅ 通过：无高危漏洞" fi
说明：该流程必须在构建节点安装 clairctl、jq，并确保 Clair API 可达；不适用于 GitHub Actions 默认 runner（无 Docker daemon）；需自行维护 updater 服务同步漏洞库（否则扫描结果严重过时）。
三、推荐替代方案：Docker Scout 原生阻断流水线（2026 年生产首选）
Docker Scout 已深度集成至 Docker CLI 和主流 CI 工具，无需自建服务，自动同步 NVD/CISA/OSV 数据，支持 SBOM、策略即代码（Policy as Code）和 PR 级别门禁：-
在 GitHub Actions 中启用自动阻断（关键漏洞直接失败）：
name: Build and push image uses: docker/build-push-action@v5 with: context: . push: true tags: ${{ secrets.REGISTRY }}/myapp:${{ github.sha }}
-
name: Scan image with Docker Scout uses: docker/scout-action@v1 with: command: scan image: ${{ secrets.REGISTRY }}/myapp:${{ github.sha }} fail-on-critical: true # ← 关键漏洞导致 workflow 失败 format: github-alerts # ← 直接在 PR 中显示漏洞卡片
优势：零运维、实时漏洞库、支持多架构镜像、输出可审计的 SARIF 报告、与 Docker Hub 组织策略联动（例如禁止含 log4j 的基础镜像）。
四、企业级增强建议（无论选 Scout 还是 Trivy）
- 分阶段策略：开发分支允许 medium 漏洞，release 分支只允许 low/none，prod tag 强制 zero critical/high - 基线锁定：用 `docker scout cves --only-fixed` 确认补丁是否已发布，避免“扫描有洞但无解” - 镜像签名验证：配合 Notary v2 或 Cosign，在阻断后增加 `cosign verify` 步骤，防止中间人篡改 - SBOM 联动审计：导出 SPDX 或 CycloneDX 格式，接入企业 CMDB 或 GRC 平台（如 ServiceNow VRM）不复杂但容易忽略：阻断动作本身没有价值，真正重要的是漏洞修复闭环——建议在失败日志中自动附上 `docker scout quickfix` 推荐的升级命令（如 `FROM ubuntu:22.04` → `ubuntu:24.04`）。
