镜像扫描须前置嵌入CI/CD构建链，在docker build完成后立即执行阻断式扫描，锁定digest确保对象确定性，输出SBOM与元数据并联动审计平台，辅以history分析和.dockerignore校验实现全链路安全管控。
在CI/CD中做镜像扫描，不是等镜像构建完再“补一刀”，而是把扫描嵌进构建链条里，让问题在源头就卡住——高危漏洞、可疑命令、非可信源基础镜像，一律不许进入下一环节。
扫描必须前置到构建完成后的第一秒
镜像一旦构建成功（docker build -t myapp:latest .），立刻触发扫描，不等待推送、不跳过本地测试。推荐在Pipeline脚本中紧接build步骤后执行：
- 用
trivy image --severity CRITICAL,HIGH --exit-code 1 myapp:latest实现阻断式扫描：发现高危或严重漏洞即退出并失败流水线 - 避免只做报告不拦截，例如
trivy image myapp:latest > report.txt这类写法无法阻止带毒镜像流转 - 若使用BuildKit，可结合
--provenance生成SLSA 3级溯源信息，供后续审计系统自动关联扫描结果与构建上下文
扫描对象要锁定真实构建产物，而非标签别名
用镜像ID或带digest的引用代替模糊标签，防止因标签被覆盖导致扫描对象错位：
- 构建时导出完整digest：
docker buildx build --output type=docker,name=myapp@sha256:abc123 . - 扫描时直接指定digest：
trivy image myapp@sha256:abc123，确保扫的是这一确切版本 - 禁用
:latest或未加哈希的语义版本（如python:3.11）作为扫描目标，它们不具备确定性
扫描结果需结构化输出并注入元数据链
扫描不能只停留在控制台日志里，要让结果可追溯、可归档、可联动：
- 生成SBOM（软件物料清单）：
syft myapp@sha256:abc123 -o spdx-json > sbom.spdx.json，与Trivy扫描结果交叉验证组件清单 - 将扫描摘要写入镜像LABEL：
LABEL org.opencontainers.image.scan.critical=3 org.opencontainers.image.scan.high=12，供K8s admission controller或Harbor策略引擎读取 - 上传扫描报告至统一审计平台（如Sigstore Cosign + Rekor），形成“构建→扫描→签名→存证”闭环
结合history分析识别构建层风险
Trivy擅长查CVE，但有些风险藏在构建逻辑里——比如某一层偷偷执行了 wget | sh 或保留了 git 工具。这时要用 docker history 辅助筛查：
- 在Pipeline中加检查：
docker history --format '{{.Command}}' myapp@sha256:abc123 | grep -E '(curl|wget).*sh$|chmod.*777' - 对含敏感指令的层，自动标记为“需人工复核”，暂停自动推送
- 配合
.dockerignore审计（检查是否漏掉.env或secrets/），构成构建环境可信双校验
