供应链安全新标准：Docker镜像SBOM生成与合规性检查

刘学敏 2026-04-15 09:28:00
摘要： 当 Log4j 漏洞爆发时，你是否曾为了快速确定公司内哪些应用受到了影响而焦头烂额？在复杂的微服务架构中，一个容器镜像可能层层嵌套了来自不同源的依赖，使其内部构成如同一个难以探查的“黑盒”。这种不确定性，正是现代软件供应链中的重大风险。解决这一困境的基石，正是软件物料清单，即 SBOM（Software Bill of Materials）。它为我们提供了一份关于软件资产的精确清单，让未知变为可知。本文将引导你完成从认知到实践的完整闭环，掌握如何为 Docker 镜像生成 SBOM，并以此为基础进行有效的合规性检查。

为什么说 SBOM 是软件供应链安全的基石

在深入探讨如何生成和使用 SBOM 之前，我们首先需要理解它为何如此重要。对于依赖容器化交付的团队而言，SBOM 不仅仅是一个技术名词，它直接关系到团队对安全风险的响应速度和管理能力。

揭开容器镜像的“黑盒”

一个典型的 Docker 镜像，除了我们自己编写的应用程序代码外，还包含了基础操作系统、系统库、运行时环境以及大量的第三方开源组件。这些组件之间又存在着复杂的依赖关系。当一个新的高危漏洞（CVE）被披露时，如果没有一份清晰的资产清单，安全团队或 DevOps 工程师将面临艰巨的挑战：

  • 定位困难：无法快速确定哪个镜像、哪个版本的服务中包含了存在漏洞的特定组件。
  • 评估滞后：难以评估漏洞的实际影响范围，导致响应时间被大大拉长。
  • 修复盲目：可能需要对大量镜像进行不必要的重建和扫描，浪费计算资源和人力。

这种对内部组件的“无知”，使得容器镜像成为了一个潜在的安全风险“黑盒”。

SBOM：一份详尽的软件“配料表”

SBOM 的核心价值就在于打破这个“黑盒”。你可以把它理解为一份软件的“配料表”，它以标准化的格式，详细列出了构成一个软件制品的所有组件信息。

这份清单通常包括：

  • 组件名称（如 log4j-core）
  • 组件版本号（如 2.14.1）
  • 供应商信息
  • 许可证信息
  • 以及其他元数据

目前，业界主流的 SBOM 格式有 SPDX (Software Package Data Exchange) 和 CycloneDX，它们都提供了机器可读的标准化规范，便于自动化工具进行处理和分析。

它不只是清单，更是风险治理的起点

需要明确一点：SBOM 本身并不是一份漏洞报告。它是一份中立的资产清单。然而，正是这份精确的清单，构成了后续所有安全治理活动的数据基础。

拥有了 SBOM，我们就能实现：

  • 快速漏洞响应：当新漏洞出现时，通过查询 SBOM 数据，可以立即定位所有受影响的软件资产。
  • 持续合规监控：自动化地将 SBOM 中的组件与已知的漏洞数据库进行比对，实现持续的风险监控。
  • 开源许可证治理：分析 SBOM 中的许可证信息，确保所有组件的许可证都符合公司的法务合规要求。

可以说，生成 SBOM 是实现 DevSecOps 和加强软件供应链安全的第一步，也是最关键的一步。

实战演练：为 Docker 镜像生成 SBOM

理解了 SBOM 的重要性后，我们来看如何为实际的 Docker 镜像生成一份 SBOM。社区中有许多优秀的开源工具可以完成这项工作，其中 Syft 因其易用性、准确性和输出格式的灵活性而备受青睐。

选择合适的生成工具

Syft 是由 Anchore 公司开发的一款 CLI 工具，它能够快速扫描容器镜像或文件系统，并以多种标准格式（包括 SPDX 和 CycloneDX）生成 SBOM。它的主要优点是专注于“生成”这一件事，并且做得非常出色，能够识别出非常细致的依赖关系。

使用 Syft 生成 SBOM

为 Docker 镜像生成 SBOM 的过程非常直接。首先，请确保你已经安装了 Docker 和 Syft。

接下来，打开你的终端，使用以下命令即可为一个镜像生成 SBOM。这里我们以官方的 python:3.9-slim 镜像为例，并指定输出为 SPDX JSON 格式： 

syft python:3.9-slim -o spdx-json=python-sbom.spdx.json

命令执行后，Syft 会自动拉取（如果本地不存在）并分析该镜像的每一层，最终在当前目录下生成一个名为 python-sbom.spdx.json 的文件。

这个 JSON 文件就是 python:3.9-slim 镜像的软件物料清单。它包含了镜像中安装的所有操作系统软件包、Python 库等详细信息，为我们后续的分析提供了精确的数据源。

至此，我们已经成功地为 Docker 镜像创建了一份 SBOM。但这仅仅是第一步，真正的价值在于如何利用这份清单来发现和管理风险。

从 SBOM 到合规：自动化漏洞与风险检查

获取 SBOM 只是手段，不是目的。我们的最终目标是利用这份清单来保障软件供应链的安全与合规。这就需要引入能够消费 SBOM 或直接分析镜像，并与漏洞数据库进行比对的工具。在这方面，Trivy 是一个非常优秀的选择。

SBOM 不是终点，分析才是关键

一份静态的 SBOM 文件并不能直接告诉我们哪些组件是脆弱的。我们需要一个“分析引擎”，它能够读取这份清单，并将其中的每一个组件与实时更新的漏洞数据库（如 NVD、GHSA 等）进行交叉比对，从而识别出已知的安全漏洞。

使用 Trivy 进行漏洞扫描

Trivy 同样是一款功能强大的开源安全扫描器。它不仅可以独立生成 SBOM，更擅长的是对容器镜像、文件系统等进行快速、全面的漏洞扫描。

我们可以直接使用 Trivy 扫描之前分析的那个镜像，来发现其中存在的漏洞： 

trivy image python:3.9-slim

Trivy 会输出一个清晰的报告，列出所有发现的漏洞、它们的严重等级（如 CRITICAL, HIGH）、受影响的组件版本以及修复建议（通常是升级到某个修复版本）。 

┌──────────────────┬────────────────┬──────────┬───────────────────┬───────────────┬───────────────────────────────────────────────────┐
│     Library      │ Vulnerability  │ Severity │ Installed Version │ Fixed Version │                       Title                       │
├──────────────────┼────────────────┼──────────┼───────────────────┼───────────────┼───────────────────────────────────────────────────┤
│ libexpat1        │ CVE-2022-43680 │ CRITICAL │ 2.2.7-1+deb11u5   │ 2.2.7-1+deb11u6 │ expat: a use-after-free in the parsing of XML     │
│                  │                │          │                   │               │ documents...                                      │
├──────────────────┼────────────────┼──────────┼───────────────────┼───────────────┼───────────────────────────────────────────────────┤
│ openssl          │ CVE-2023-3446  │ HIGH     │ 1.1.1n-0+deb11u4  │ 1.1.1n-0+deb11u5│ Excessive time spent checking DH keys and         │
│                  │                │          │                   │               │ parameters                                        │
└──────────────────┴────────────────┴──────────┴───────────────────┴───────────────┴───────────────────────────────────────────────────┘

这份报告为开发和安全团队提供了直接、可操作的修复依据。

通过结合 Syft 生成精确的 SBOM 和 Trivy 进行高效的漏洞扫描，我们就构建了一个发现软件供应链风险的最小化工作流。

将 SBOM 集成到 CI/CD 流程

手动执行扫描对于单次检查是可行的，但在现代化的软件开发流程中，我们追求的是自动化和“左移”（Shift Left），即尽可能早地发现并修复问题。因此，将 SBOM 的生成和检查集成到 CI/CD 流水线中是必不可少的一步。

在构建时自动生成

最佳实践是在 CI 流水线的镜像构建（docker build）步骤成功之后，立即触发 SBOM 的生成。

例如，在 GitLab CI 的 .gitlab-ci.yml 文件中，可以增加一个专门的阶段： 

stages:
  - build
  - security_scan
build_image:
  stage: build
  script:
    - docker build -t myapp:latest .
    # ... push image to registry
generate_sbom:
  stage: security_scan
  script:
    - syft myapp:latest -o spdx-json=sbom.spdx.json
    - # 将 sbom.spdx.json 作为产物归档

这样，每次代码变更触发的构建都会自动生成一份最新的 SBOM，并将其作为构建产物保存下来，以备审计和后续分析。

设立质量门禁

更进一步，我们可以在流水线中设立“质量门禁”（Quality Gate）。利用 Trivy 扫描结果的退出码（exit code），我们可以设定一个规则：如果扫描发现了指定严重等级（如 CRITICAL 或 HIGH）的漏洞，就让流水线执行失败，从而阻止有问题的镜像被部署到后续环境。

Trivy 提供了方便的参数来实现这一点： 

# 如果发现任何 CRITICAL 级别的漏洞，命令将以非零状态退出，导致 CI 任务失败
trivy image --exit-code 1 --severity CRITICAL myapp:latest

通过在 CI/CD 流程中自动化执行 SBOM 生成和漏洞扫描，团队可以确保每个部署到生产环境的应用都经过了基本的安全基线检查，将 DevSecOps 理念真正落到实-处。

超越基础：企业级的 SBOM 治理挑战

当组织规模扩大，需要管理的应用程序和镜像数量从几十个增长到成百上千个时，单纯依靠开源 CLI 工具的模式会遇到新的挑战。

开源工具的局限性

虽然 Syft 和 Trivy 在单个任务上表现出色，但在企业级规模化治理场景下，它们存在一些天然的局限性：

  • 缺乏统一视图：生成的 SBOM 和扫描报告散落在各个项目的 CI/CD 流水线中，无法集中存储、查询和管理。
  • 策略难以协同：安全团队难以在全公司范围内统一和强制执行安全策略，例如“禁止使用含指定漏洞的组件”或“禁止使用特定非合规许可证”。
  • 缺乏历史追溯：无法方便地追踪一个组件在不同时间点的漏洞变化趋势，或是一个漏洞在整个组织内的影响范围演变。
  • 告警疲劳：大量的扫描结果需要人工筛选和跟进，容易导致告警疲劳和关键风险被忽略。

实现规模化治理的进阶方案

为了解决这些问题，企业需要一个能够集中管理软件供应链安全的平台。一个优秀的企业级安全平台，通常会在开源工具的基础上，提供更强大的治理能力。它能够将分散的 SBOM 和安全数据汇集起来，形成一个统一的、可查询的“软件资产中心”。

基于这个中心，平台可以提供更高级的功能，例如：

  • 全局策略引擎：允许安全团队定义全局性的合规策略，并自动应用到所有接入的 CI/CD 流程中。
  • 可视化风险仪表盘：提供组织范围内的风险态势概览，帮助管理者快速识别高风险项目和团队。
  • 自动化事件响应：当出现新的“Log4j”式漏洞时，平台能够自动分析其影响范围，并向相关负责人派发修复任务。

这些能力将 SBOM 的价值从单个项目的“检查”提升到了整个企业的“治理”层面。

结语

软件物料清单（SBOM）正迅速从一个行业倡议，演变为现代软件开发不可或缺的一环。它为我们提供了前所未有的透明度，让我们能够看清并管理构成软件的每一个“零件”。

通过本文的介绍，我们了解了从使用 Syft 生成 Docker 镜像的 SBOM，到利用 Trivy 进行自动化漏洞扫描，再到将其集成至 CI/CD 流水线以建立质量门禁的完整流程。这套实践不仅能够有效提升软件供应链的安全性，也是向 DevSecOps 成熟模式迈进的关键一步。

对于任何希望严肃对待软件安全的团队来说，现在就是开始采纳和实践 SBOM 的最佳时机。不妨从你的下一个项目开始，尝试为它生成第一份 SBOM 吧。

© docker中文社区站