应显式指定带语义化版本号的FROM镜像（如alpine:3.18），优先选用官方最小化镜像，配合docker scout cves扫描、SBOM生成与CI/CD自动阻断机制，杜绝latest等易变标签。
评估 FROM 指令所指定的基础镜像是否含安全漏洞，不能只看标签名，而要结合来源可信度、版本稳定性、已知漏洞状态和构建上下文综合判断。
确认基础镜像的来源与维护状态
优先选用官方镜像仓库（如 docker.io/library/alpine、docker.io/library/nginx）中明确标注“Official Image”的镜像。避免使用社区上传、无签名、无人长期维护的镜像。可通过以下方式验证：
- 运行
docker pull <image>:tag后，检查输出中是否有Verified Publisher或Official Image标识 - 访问 Docker Hub 页面，查看镜像详情页的 “Official Image”徽章 和最近更新时间
- 对私有仓库（如 Harbor），确认是否启用内容信任（
DOCKER_CONTENT_TRUST=1）
固定标签并核查具体版本的 CVE 状态
FROM node:latest 或 FROM ubuntu:22.04 这类写法看似简洁，实则隐藏风险。应改用带精确补丁号的标签，例如 FROM node:20.15.1-alpine3.20，然后立即扫描：
- 执行
docker scout cves <image>:tag，重点关注 CVSS ≥ 7.0 的高危漏洞 - 对比同一基础镜像不同 tag 的扫描结果，例如
alpine:3.20vsalpine:3.21，选择漏洞更少、更新更及时的版本 - 注意：某些“精简版”镜像（如
distroless）虽无包管理器，但若内核或静态链接库存在漏洞，仍会被识别
结合 docker history 追溯底层依赖
FROM 指令引入的是整个基础镜像的全部层，其历史可能包含已被修复但未同步到当前 tag 的旧问题。用命令深入查看：
-
docker history --no-trunc <image>:tag，重点观察最底层（即基础镜像第一层）的CREATED BY - 若底层显示
/bin/sh -c #(nop) FROM ubuntu:20.04@sha256:...，需进一步查该sha256对应的具体构建时间与已知漏洞披露时间是否重叠 - 发现基础层使用了已 EOL（End-of-Life）系统（如
debian:9、ubuntu:18.04），应直接弃用
借助 SBOM 与自动化策略卡点
单次扫描不够，需将评估纳入流程。Docker Scout 支持生成软件物料清单（SBOM）并导出为标准格式：
- 运行
docker scout sbom <image>:tag --format json > sbom.json，可解析其中所有 OS 包与语言依赖 - 在 CI 流水线中加入策略：若
docker scout cves报告中存在CRITICAL级别漏洞且无已知修复版本，则自动失败构建 - 对金融、政务等强合规场景，要求基础镜像必须提供由 CNAS 认证机构出具的《镜像安全检测报告》
