4. 医疗容器镜像治理

医疗容器镜像治理的目标不是“把镜像做小”，而是让每一个进入生产环境的镜像都具备可追溯、可验证、可复现、可审计的属性。在医疗场景中，镜像往往承载 HIS、LIS、PACS、EMR 等核心业务组件，一旦镜像来源不明、层内容被篡改或存在高危漏洞，影响的不只是服务可用性，还可能触及患者数据安全与合规审计。因此，镜像治理需要从基础镜像选择开始，贯穿分层构建、签名验证、漏洞扫描，最终落到医疗软件物料清单（HBOM，Healthcare Bill of Materials）的持续管理。

基础镜像选择：从“能用”到“可控”

基础镜像决定了镜像的起点安全性与后续维护成本。医疗环境通常有三类可选基础镜像：官方通用镜像（如 debian:12-slim、alpine:3.19）、厂商/社区加固镜像（如 Red Hat UBI、Chainguard Images）、院内自建基线镜像。选择时不能只看体积，应同时评估：CVE 修复响应周期、是否提供 SBOM、是否支持长期维护标签、是否包含非必要包管理器与 shell。

一个可落地的做法是建立“基础镜像准入清单”。例如，某三甲医院云原生平台规定：Java 服务统一使用 eclipse-temurin:17-jre-jammy 作为运行时基础镜像，禁止使用 latest 标签；前端静态资源使用 nginx:1.25-alpine；数据库客户端工具类镜像必须来自院内 Harbor 的 base/ 项目，且每周同步一次上游安全补丁。准入清单中应记录镜像 digest，而不是仅记录 tag，因为 tag 可被覆盖，digest 才是不可变标识。

镜像分层优化：让缓存与安全同时受益

Dockerfile 的每一层都会进入最终镜像，层数越多、层内文件越大，镜像体积和攻击面就越大。医疗镜像分层优化通常遵循三条原则：合并无关层、稳定层前置、敏感层后置。以 Java 服务为例，依赖下载层应放在源码复制之前，这样源码变更不会导致依赖重新下载；而配置文件、密钥、证书等敏感内容应放在最后一层，避免在中间层残留。

下面是一个优化前后的对比示例。优化前，COPY . . 放在 mvn dependency:go-offline 之前，导致每次代码变更都重新下载依赖；优化后，先复制 pom.xml 并下载依赖，再复制源码，构建缓存命中率显著提升。

# 优化前：依赖与源码耦合，缓存易失效
FROM maven:3.9-eclipse-temurin-17 AS build
COPY . /app
RUN mvn -f /app/pom.xml clean package -DskipTests

# 优化后：依赖层前置，源码层后置
FROM maven:3.9-eclipse-temurin-17 AS build
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline -B
COPY src ./src
RUN mvn clean package -DskipTests -B

此外，多阶段构建是医疗镜像分层优化的关键手段。构建阶段使用完整 JDK 与 Maven，运行阶段仅复制 JRE 与 jar 包，最终镜像可从 800MB 降至 180MB 左右。对于需要 native 库的 PACS 影像处理服务，运行阶段仍需保留必要的 libjpeg、libpng 等动态库，但应删除编译工具链与包管理器缓存。

镜像签名与扫描：构建可信链路

镜像签名解决“镜像是否来自可信构建者、是否被篡改”的问题。当前医疗平台常用 Cosign 配合 OCI 仓库实现签名与验证。构建流水线在推送镜像后，使用 Cosign 私钥对镜像 digest 签名，并将签名作为 OCI artifact 推送到同一仓库；Kubernetes 准入控制器（如 Kyverno 或 OPA Gatekeeper）在 Pod 创建前调用 Cosign 验证签名，未签名或签名不匹配的镜像直接拒绝部署。

镜像扫描则解决“镜像里有什么漏洞”的问题。推荐在 CI 阶段使用 Trivy 或 Grype 对镜像进行扫描，并将结果按严重级别阻断：Critical 与 High 必须修复后才能推送生产仓库；Medium 可记录并限期修复；Low 仅记录。扫描对象应包括 OS 包与语言依赖包，例如 Java 的 pom.xml 依赖、Node.js 的 package-lock.json。扫描结果应写入镜像元数据，供后续审计查询。

医疗软件物料清单管理：从 SBOM 到 HBOM

SBOM（Software Bill of Materials）描述镜像中包含的软件组件、版本与依赖关系。医疗场景下，SBOM 需要进一步扩展为 HBOM，即在 SBOM 基础上增加：组件对应的医疗器械注册证信息、数据分类分级标签、许可证合规状态、已知漏洞与修复状态、以及组件与临床业务模块的映射关系。HBOM 的价值在于，当某个开源组件爆出高危漏洞时，平台团队可以快速回答“哪些镜像受影响、对应哪些业务系统、是否需要停机修复”。

HBOM 的生成应与构建流水线绑定。推荐使用 Syft 生成 SPDX 或 CycloneDX 格式的 SBOM，再由平台侧补充医疗元数据，最终存入镜像仓库的 artifact 或独立 HBOM 数据库。每次镜像重新构建，HBOM 必须同步更新，并与镜像 digest 一一对应。审计时，通过 digest 即可回溯到完整的组件清单与漏洞历史。

落地时，建议将上述治理动作全部嵌入 CI/CD 流水线：构建阶段完成分层优化与 SBOM 生成，推送阶段完成 Cosign 签名与 Trivy 扫描，部署阶段由 Kyverno 验证签名与扫描结果，运行阶段定期重新扫描已部署镜像并更新 HBOM。这样，医疗容器镜像治理就不再是一次性的检查，而是一条持续运转的可信链路。