从 PBM 2.15.0 和 PCSM 0.9.0 开始，二进制压缩包、RPM、DEB 和 Docker 镜像等发布制品都会附带 CycloneDX 1.6 JSON 格式的软件物料清单（SBOM）。这意味着团队不必等到软件部署后再猜测其中包含哪些依赖，可以在下载、构建或准入阶段立即扫描已知 CVE。
SBOM 改变了扫描的输入
传统漏洞扫描通常直接检查文件系统、软件包数据库或容器层。SBOM 提供了另一种稳定输入：它记录制品中识别出的组件及其版本，Trivy、Grype 和其他兼容 CycloneDX 的工具可以据此查询漏洞数据库。
这项变化覆盖 PBM 2.15.0、PCSM 0.9.0 及其后续版本的多种发布形态：
- binary tarball
- RPM 软件包
- DEB 软件包
- Docker 镜像
统一采用 CycloneDX 1.6 JSON 还有一个实际价值：安全流程不必绑定某一种包管理器。无论交付物是容器镜像还是传统安装包，都可以把 SBOM 交给同一类策略引擎处理。
不过，SBOM 不是漏洞数据库，也不是“无漏洞证明”。扫描结果仍取决于漏洞数据库的新鲜度、组件识别质量和版本匹配规则。当天没有命中的组件，可能在数周后出现新披露的 CVE，因此需要持续重扫已归档的 SBOM。
Docker 镜像的最短扫描路径
对于 Docker 镜像，可以直接让 Trivy 从 OCI 制品中读取 SBOM。运行前需要安装 Trivy，并将示例镜像替换为团队实际使用的 PBM 或 PCSM 镜像及固定标签：
IMAGE="your-registry.example/percona-tool:fixed-version"
trivy image \
--sbom-sources oci \
--severity HIGH,CRITICAL \
--ignore-unfixed \
--exit-code 1 \
"$IMAGE"
这里有三个适合 CI 的关键选项：
--sbom-sources oci优先使用镜像随附的 OCI SBOM。--severity HIGH,CRITICAL将准入范围收敛到高危和严重漏洞。--exit-code 1在发现匹配漏洞时让流水线失败。
--ignore-unfixed 是否启用需要由团队决定。启用后告警更容易转化为可执行升级任务，但也可能隐藏尚无修复版本的高风险问题。生产环境通常应同时保留一份不忽略未修复漏洞的审计报告。
扫描 RPM、DEB 和压缩包附带的 JSON
非容器制品可以直接扫描随发布物提供的 CycloneDX JSON。由于具体文件名和解压位置可能随制品布局变化，下面的做法先定位 JSON，再显式传给扫描器；运行时请把 ./release 改为实际解压目录：
set -euo pipefail
SBOM_FILE="$(find ./release -type f \
\( -iname '*sbom*.json' -o -iname '*bom*.json' \) \
-print -quit)"
if [ -z "$SBOM_FILE" ]; then
echo "CycloneDX SBOM not found" >&2
exit 2
fi
trivy sbom \
--severity HIGH,CRITICAL \
--exit-code 1 \
"$SBOM_FILE"
也可以用 Grype 扫描同一份文件：
SBOM_FILE="./release/path/to/sbom.json"
grype "sbom:$SBOM_FILE" --fail-on high
建议在流水线中保留原始 SBOM、扫描工具版本、漏洞数据库更新时间和扫描报告。这样即使未来漏洞数据库发生变化，团队仍能回答“某个版本在某一天按什么规则扫描过”。
可以这样接入 CI 准入
以下 GitHub Actions 示例属于一种可改造的实践，并非发布方规定的固定集成方式。它从仓库变量读取镜像地址，在拉取或部署前执行扫描：
name: container-vulnerability-gate
on:
workflow_dispatch:
pull_request:
paths:
- "deploy/**"
jobs:
scan:
runs-on: ubuntu-latest
steps:
- name: Install Trivy
uses: aquasecurity/setup-trivy@v0.2.3
with:
version: latest
- name: Scan embedded OCI SBOM
env:
IMAGE: ${{ vars.PERCONA_TOOL_IMAGE }}
run: |
test -n "$IMAGE"
trivy image \
--sbom-sources oci \
--severity HIGH,CRITICAL \
--exit-code 1 \
"$IMAGE"
实际生产环境还应固定 Action 和 Trivy 的版本或提交摘要，避免扫描基础设施本身在未审查的情况下变化。若镜像位于私有仓库，还需要在扫描步骤之前完成最小权限登录。
上线前要定清楚的规则
将 SBOM 扫描加入发布流程时，至少需要明确以下事项：
- 使用固定版本或镜像摘要，不要扫描会漂移的
latest标签。 - 定义哪些严重等级会阻断发布，哪些进入限期修复队列。
- 为误报和无修复版本设置有负责人、原因和到期时间的例外。
- 缓存并定期更新漏洞数据库，避免离线环境长期使用过期资料。
- 保存每个已部署版本的 SBOM，并在新 CVE 披露后重新扫描。
- 不要把 SBOM 扫描当成唯一防线；配置错误、运行时暴露和业务逻辑漏洞不一定出现在物料清单中。
PBM 2.15.0 和 PCSM 0.9.0 将 CycloneDX 1.6 SBOM 放进每类发布制品，解决的是“扫描输入从哪里来”的问题。团队下一步应把这份输入接进明确、可审计且能够持续重跑的漏洞响应流程，而不是只在首次下载时执行一次命令。