如何选择可接入 DevSecOps 的 AI BOM 工具

是希望确认模型许可证、追踪存在漏洞的依赖项，还是掌握正在使用的模型是否发生变化？目的不同，所需字段和工具也会不同。首先，将模型ID与版本、提供方、依赖软件、使用位置和负责人纳入盘点范围，并按需纳入数据集和许可证。

CycloneDX的ML-BOM是一种能够描述模型、数据集等内容的格式。但格式中存在某个字段，与工具能够从自身环境中获取该字段的值，是两回事。

cdxgen是可从源代码等内容生成BOM的候选工具。Dependency-Track可接收CycloneDX BOM，用于从CI/CD提交BOM以及分析组件。前者负责生成，后者负责接收与管理，角色不同，因此评估时也应考虑组合使用。

各生成工具的检查对象也有所不同。AIBoMGen CLI 针对代码仓库中 Hugging Face 模型的使用情况生成 CycloneDX AI BOM，并提供 GitHub Action。xgrep 离线检查代码中 AI SDK 和模型的使用情况，并以 CycloneDX 1.6 格式输出。不过，xgrep 面向 AI 的输出不包含一般软件依赖关系，因此需要另行生成 SBOM。

即使已经使用SBOM生成器，也不一定能获取模型特有的信息。可通过CycloneDX Tool Center寻找其他候选工具，除了支持的格式，还应检查模型信息的输出字段、CLI或API、身份认证，以及现有的工单处理流程。

以下是cdxgen v13.6.0的官方示例。请针对不含机密信息的对象生成BOM，并将模型ID、版本和许可证与原始配置进行核对。这是命令示例，并非在此环境中执行所得的结果。

模型卡中列出的数据集和基础模型，属于提供方的声明。不应将其视为实际用于训练的证明，而应分别核实模型卡中的记载、观测到的依赖关系，以及训练作业的证据。

cdxgen -r --include-formulation -o aibom.json --bom-audit --bom-audit-categories ai-bom .

对于运行时通过环境变量或外部 API 选定的模型，仅对代码仓库进行静态分析可能会有所遗漏。如果我们处于审查代码的角色，就会将生成的清单与应用配置和使用记录进行核对，排查未被列入清单的引用。仅靠代码分析，不一定能了解外部模型使用情况的全貌。

接入CI后，应更改模型版本，确认下一份产物中是否体现差异，以及接收端是否保留了所需字段。生成命令成功，并不意味着发现问题时CI就一定会失败。需要另外设置失败条件和退出码的处理方式，并建立不会将等待人工确认的状态视为通过的流程。