数据库供应链的风险并不只来自数据库本身。一个发行包还可能包含操作系统库、编译时依赖、运行时组件以及这些组件继续引入的传递依赖。软件物料清单（Software Bill of Materials，SBOM）把这些关系整理成机器可读的清单，让团队能够回答两个实际问题：当前运行的版本到底包含什么，以及某个组件出现漏洞时哪些实例需要处理。
SBOM 为什么值得纳入数据库运维
SBOM 的核心不是一份给人浏览的产品说明，而是对组件组成的结构化描述。对于 Percona Server for MongoDB 这样的数据库发行版，清单可以覆盖直接依赖和传递依赖，包括：
- 数据库发行包及其精确版本；
- 操作系统或容器镜像中的系统库；
- 编译工具链和构建阶段使用的组件；
- 运行时加载的库及其许可证信息；
- 用于定位组件的包名、版本、校验和或 PURL。
这类数据首先服务于漏洞响应。安全团队收到某个 OpenSSL、zlib 或其他底层组件的漏洞通告后，可以根据 SBOM 查询受影响的数据库镜像和主机，而不必等待人工逐台确认。
它也有助于许可证合规。组件名称和版本被标准化记录后，法务和工程团队可以更快识别许可证义务，减少依赖升级或发布审核时的猜测。
一份 SBOM 需要回答哪些问题
有效的清单至少应该包含四类信息。
- 对象是谁：产品、发行包、容器镜像或构建产物的名称和版本。
- 里面有什么：直接依赖和传递依赖的完整列表。
- 如何确认它没有被替换：组件校验和、镜像摘要或其他唯一标识。
- 清单对应哪个交付物：生成时间、构建版本、目标架构和发布上下文。
格式可以选择 SPDX 或 CycloneDX。关键不在于格式名称，而在于清单能够被工具解析、进入制品库，并与实际部署的制品建立稳定关联。只保存一份手工编辑的表格，无法可靠支持漏洞查询。
可以这样生成并检查容器镜像 SBOM
如果 Percona Server for MongoDB 以容器镜像方式交付，可以在构建或发布阶段使用 Syft 生成 CycloneDX JSON。下面的命令假设本地已经安装 Syft，并且镜像标签已经替换为团队实际使用的版本。
# 替换为实际的 Percona Server for MongoDB 镜像和版本
IMAGE='percona/percona-server-mongodb:8.0'
# 生成机器可读的 CycloneDX SBOM
syft "docker:${IMAGE}" -o cyclonedx-json=percona-mongodb-sbom.json
# 快速查看清单中的组件数量和前几条记录
jq '.components | length' percona-mongodb-sbom.json
jq -r '.components[:10][] | [.name, .version, .purl] | @tsv' percona-mongodb-sbom.json
# 用镜像摘要把 SBOM 与不可变制品关联起来
docker image inspect "${IMAGE}" --format '{{index .RepoDigests 0}}'
sha256sum percona-mongodb-sbom.json
实际流水线中，应把 SBOM 与镜像一起上传到制品库，并记录镜像 digest，而不是只依赖可变的 latest 标签。发布系统还可以在推送前运行漏洞扫描器：
# 示例：对同一个镜像执行漏洞扫描
trivy image --severity HIGH,CRITICAL --ignore-unfixed "${IMAGE}"
这些命令是通用实践示例，具体镜像标签、扫描策略和输出格式应按组织的构建系统调整。若数据库直接安装在虚拟机或物理机上，则应在目标系统的软件包清单基础上生成 SBOM，并将主机标识、架构和安装来源一并保存。
把 SBOM 接入日常流程
SBOM 只有进入流程才会产生价值。可以从以下几个检查点开始：
- 构建时生成：每次发布都生成与制品版本对应的清单。
- 发布时校验：拒绝缺少 SBOM、镜像 digest 或关键许可证信息的制品。
- 部署时登记：把 SBOM、实例、环境和部署时间关联起来。
- 漏洞事件中查询：收到漏洞通告后，按组件标识反查受影响数据库实例。
- 升级后重新生成：补丁版本或基础镜像变化都可能改变依赖集合。
还要区分“清单发现了组件”和“组件一定存在可利用漏洞”。SBOM 解决的是组成和定位问题，漏洞是否可利用仍需要结合版本范围、编译选项、运行配置、网络暴露面和供应商公告判断。扫描器误报、未修复漏洞和操作系统回移植补丁也需要人工复核。
落地时的检查清单
开始在 Percona Server for MongoDB 交付链路中使用 SBOM 时，可以先确认：
- 每个生产制品都有唯一版本和不可变 digest；
- 清单包含直接依赖与传递依赖；
- 清单采用 SPDX 或 CycloneDX 等标准格式；
- 构建日志能追溯清单的生成工具和版本；
- 漏洞平台可以按名称、版本或 PURL 查询；
- 许可证审核和漏洞响应都有明确负责人；
- 数据库升级、基础镜像升级和紧急补丁会触发清单更新。
SBOM 不会自动消除供应链风险，但它能把“我们应该包含哪些依赖”变成可查询、可验证、可追溯的数据。对数据库平台而言，这一步会直接缩短漏洞响应时间，也会让版本升级和合规审查更可控。