Fedora作为Red Hat旗下技术激进的发行版，是很多开发者构建容器镜像时的首选基础镜像。它软件包新、工具链完整，但代价是镜像体积偏大、包含的RPM包数量多，随之带来的安全暴露面也更大。一个官方fedora:40镜像解压后大约有170MB，里面预装了bash、glibc、dnf等数百个组件，任何一个组件爆出CVE，你的业务容器都会被动中招。这篇文章就来聊聊如何对Fedora容器镜像做系统的安全扫描，以及扫描出漏洞之后该怎么处理。
为什么Fedora镜像需要专门做安全扫描
首先要理解容器镜像漏洞的来源。容器镜像本质上是文件系统的分层快照，Fedora镜像中的漏洞主要集中在三个地方：一是基础系统自带的RPM包，比如openssl、curl、zlib这类被广泛依赖的库；二是你在Dockerfile中通过dnf install额外安装的软件包；三是应用自身的依赖，例如Python的pip包、Node的npm包、Java的jar依赖。很多团队只扫描第一类，忽略了后两类，导致扫描结果看起来很干净，实际隐患并没有被覆盖。
其次，Fedora的更新节奏很快，官方仓库平均每周都会推送大量安全更新。如果基础镜像的构建时间超过一个月，里面几乎必然存在已知漏洞。而且Fedora每个版本的生命周期只有大约13个月，一旦版本到达EOL，官方不再提供安全补丁，扫描报告里的漏洞将无法通过升级修复，只能整体更换基础镜像版本。所以扫描不只是技术动作，更是镜像生命周期管理的一部分。
最后从合规角度看，如果企业要做等保测评或者对接甲方安全审计，镜像扫描报告通常是必备材料。扫描工具能输出标准化的CVE编号、严重等级、修复建议，这些内容人工整理几乎不现实，必须依赖自动化工具。
主流扫描工具对比：Trivy、Grype与OpenSCAP
目前对Fedora镜像支持较好的扫描工具主要有三款，它们各有侧重，适合不同的使用场景。
Trivy是Aqua Security开源的扫描器，对Fedora的支持非常完善。它内置了Red Hat Security Data的CVE数据库，能准确识别RPM包的版本和对应的漏洞等级，同时还能扫描语言依赖（pip、npm、go mod等）和镜像内嵌的密钥凭证。Trivy最大的优点是零配置，一条命令就能出结果，而且提供官方容器镜像，不需要在宿主机安装任何东西。它输出格式丰富，JSON、SARIF、HTML报告都支持，方便接入CI/CD流水线。
Grype是Anchore公司的产品，和镜像构建工具syft是黄金搭档。syft负责生成SBOM（软件物料清单），grype基于SBOM做漏洞匹配。这种解耦设计的好处是SBOM可以存档复用，供应链审计时不用重新解压镜像。Grype对RPM系发行版的匹配准确率不错，但在漏洞数据库的更新频率上略慢于Trivy。
OpenSCAP则走的是另一条路线，它基于SCAP标准做合规扫描，可以按照CIS基准检查Fedora镜像的系统配置，比如是否存在空密码账户、SSH配置是否安全。它更适合做合规基线检查，单纯找CVE时不如前两者方便。
| 工具 | 扫描对象 | 优势 | 适用场景 |
|---|---|---|---|
| Trivy | RPM包、语言依赖、密钥 | 零配置、数据库更新快 | 日常开发、CI集成 |
| Grype | SBOM驱动的全量组件 | SBOM可存档、供应链审计友好 | 合规存档、依赖溯源 |
| OpenSCAP | 系统配置与CVE | 支持CIS合规基线 | 等保测评、配置审计 |
用Trivy扫描Fedora镜像的完整实操
下面以Trivy为例演示完整流程。最简单的方式是直接用官方容器运行扫描，不需要本地安装：
# 拉取镜像 docker pull fedora:40 # 使用Trivy官方容器扫描，直接输出到终端 docker run --rm \ -v /var/run/docker.sock:/var/run/docker.sock \ -v $HOME/.cache/trivy:/root/.cache \ aquasec/trivy:latest image fedora:40
扫描结果会按严重程度分组，从CRITICAL到UNKNOWN依次列出。每个漏洞条目包含CVE编号、受影响的包名、当前安装版本、修复版本和漏洞标题。如果只关心高危以上问题，可以加过滤参数：
# 只显示HIGH和CRITICAL级别漏洞 trivy image --severity HIGH,CRITICAL fedora:40 # 输出JSON格式报告，便于程序处理 trivy image --format json --output report.json fedora:40 # 扫描时同时忽略无法修复的漏洞 trivy image --ignore-unfixed fedora:40
这里有几个实用技巧值得注意。第一，--ignore-unfixed参数很重要，Fedora仓库里有些包的漏洞上游还没有发布补丁，这类漏洞在报告里只会制造噪音，过滤掉可以让团队聚焦在真正能修复的问题上。第二，如果某些漏洞经过评估确认不影响你的使用场景，可以通过.trivyignore文件排除：
# .trivyignore 文件内容示例 CVE-2024-12345 CVE-2023-99999
第三，扫描结果的误报处理。Trivy判断漏洞依赖RPM包版本号比对，有时候Fedora会对老版本做backport补丁而不改版本号，这种情况下会出现误报，可以到Red Hat的CVE数据库核实后加入忽略列表。
把扫描嵌入CI流水线与镜像优化建议
手动扫描只适合临时排查，真正有效的做法是把扫描固化到CI流水线里。以GitLab CI为例，可以在镜像构建后自动执行扫描，发现高危漏洞直接让流水线失败：
stages:
- build
- scan
scan_image:
stage: scan
image:
name: aquasec/trivy:latest
entrypoint: [""]
script:
- trivy image --exit-code 1 --severity HIGH,CRITICAL
--ignore-unfixed $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
--exit-code 1是关键参数，它让Trivy在发现匹配条件的漏洞时返回非零退出码，从而触发流水线失败，阻止问题镜像进入制品库。GitHub Actions也有现成的trivy-action可以直接复用，配置思路完全一致。
除了扫描，降低漏洞面的根本手段是镜像瘦身。几个实践建议：优先使用fedora-minimal镜像作为基础，它用microdnf替代dnf，体积只有不到100MB，预装包数量大幅减少；在Dockerfile中安装软件包后记得清理缓存，执行dnf clean all并删除/var/cache/dnf目录；安装时精确指定需要的包，避免拉入 recommends 依赖链。实践下来，一个精简的Fedora业务镜像可以把高危漏洞数量从几十个降到个位数。
另外建议开启基础镜像的自动重建机制，比如配置定时任务每周重新拉取最新基础镜像并触发全量扫描，这样官方发布安全补丁后，你的镜像能在最短时间内完成更新闭环。配合镜像仓库的推送时间戳做版本管理，就能形成一套完整的镜像安全生命周期管理体系，让Fedora镜像在享受软件新的便利的同时，安全风险始终处于可控状态。
Fedora容器镜像镜像安全扫描Trivy漏洞检测修改时间：2026-09-05 01:20:37