FROM指令不修复漏洞，但决定后续安全修复的起点和上限；选错基础镜像会继承其CVE漏洞，官方slim或hardened镜像、固定标签、SBOM追溯及年龄限制是关键实践。
FROM 指令本身不修复漏洞，但它决定了后续所有安全修复的起点和上限。 选错基础镜像，就像在地基不牢的房子上装修——再精细的补丁也难抵根本性风险。
基础镜像直接承载已知漏洞
FROM 指定的镜像（如 ubuntu:20.04、node:16）是构建链的源头。如果它本身包含未修复的 CVE（例如 OpenSSL 1.1.1f 中的 CVE-2021-3711），那么所有基于它的镜像默认继承这些漏洞，除非后续显式升级或替换相关组件。
- 官方镜像（如 debian:bookworm-slim、alpine:3.20）通常比旧版更少高危漏洞，因维护方已合并上游安全更新
- 使用 :latest 标签存在不确定性——它可能指向过时版本；应固定为带具体补丁号的标签（如 python:3.11.9-slim-bookworm）
- Docker Hub 上非官方镜像若未及时同步上游修复，FROM 它等于主动引入已知风险
影响后续修复的有效性与成本
从含漏洞的基础镜像出发，修复手段受限且易遗漏：
- 若基础镜像中 apt 源陈旧，RUN apt-get update && apt-get install -y ... 可能仍装入旧版有漏洞包
- 手动编译替换二进制（如替掉 libssl.so）极易破坏兼容性，且难以持续维护
- 扫描工具（如 Trivy、Clair）报告的绝大多数中高危漏洞，根源就在 FROM 镜像层，而非你的应用代码
最佳实践：用“安全就绪”的基础镜像
优先选择明确声明安全策略、定期重建、提供 SBOM 的镜像：
- 使用发行版官方 slim 或 security-hardened 变体（如 registry.access.redhat.com/ubi8/python-39:1-195、cgr.dev/chainguard/python:3.11）
- 启用 Docker BuildKit 的 --sbom 和 --provenance，确保 FROM 镜像来源可追溯
- 在 CI 中强制检查基础镜像年龄（如限制构建时间距其上次更新 ≤30 天）
不复杂但容易忽略：修复漏洞不是靠写更多 RUN 指令，而是从第一行 FROM 就选对人。
