组织应如何实施 CBOM，并集成 CI/CD 与依赖管理流程？
建议采用怎样的实施方式？
建议将 CBOM 纳入现有的软件供应链和 CI/CD 流程：应用团队随构建生成或更新数据，平台团队提供公共工具和存储能力，安全团队制定密码使用策略。是否单独输出 CBOM 文件，可以根据工具兼容性、访问权限和更新周期决定。具体岗位划分和流水线门禁需要按组织情况确定。
CycloneDX 支持 CBOM，但密码资产不一定要放在独立文件中。它们可以与软件组件出现在同一个 BOM 中，也可以拆成独立 CBOM。CycloneDX SBOM 指南介绍了这两种方式。
如何建立和维护 CBOM？
可以先选一个应用试点，明确清单覆盖源码、构建产物还是部署环境，再确定需要回答的问题。例如，哪些服务使用了某种算法？相关证书由谁维护？更换密码组件会影响哪些应用？
采集时应关注算法及参数、协议、证书、相关密码材料的元数据，以及它们与应用和软件组件的关系。只列出密码库名称通常不够，因为库支持某种算法，不能证明应用实际使用了它。CycloneDX 的 CBOM 模型支持表达这类资产及其关系，详见 CBOM 指南。
实施可以分三步：
- 采集构建信息。从源码、依赖、配置和构建产物中发现密码资产，记录扫描工具、时间、范围和证据位置。
- 补充部署信息。对于 TLS 终止设备、证书存储、KMS、HSM 等构建阶段难以覆盖的部分，由相应团队提供配置或运行环境中的发现结果。
- 关联业务上下文。将清单关联到应用、负责人、发布版本和制品摘要，使发现的问题能够分派到具体团队。
这些上下文可以存放在 BOM 中，也可以由关联的资产管理系统维护。应明确区分“已发现”“未发现”和“尚未覆盖”，避免把扫描盲区当作没有使用密码技术。
单独生成 CBOM，还是与 SBOM 合并？
两种方式都可以接入同一条流水线。选择文件形式时，主要考虑消费端和权限要求。
| 方式 | 适用条件 | 实施重点 |
|---|---|---|
| 在同一个 CycloneDX BOM 中包含软件组件与密码资产 | 生成和消费工具均能保留、解析密码资产字段，访问权限也一致 | 验证导入、导出和转换过程中不会丢失密码资产及关系 |
| 分别生成 SBOM 与 CBOM | 工具来源、更新周期、交付对象或权限不同 | 保留清单间的关联，并绑定相同的应用与制品身份 |
如果选择拆分，可以使用 CycloneDX 的 BOM-Link 连接不同 BOM 中的信息，相关用法见 CBOM 指南的解耦章节。使用前需要确认消费工具支持这些关联。
无论采用哪种方式，都应保留机器可读数据。审计或人工阅读所需的报告可以从这些数据生成，避免团队另行维护一份容易过期的清单。
CI/CD 应如何集成？
建议在 Pull Request 阶段检查新增和变更的密码使用，在发布阶段保存与实际制品对应的清单。证书轮换和部署配置变更可能不触发应用构建，因此需要额外安排更新机制。
以下伪代码说明任务顺序，不能直接作为 CI 配置运行，也不是 CycloneDX 数据格式：
workflow:
- build_artifact
- generate_sbom
- discover_crypto_assets
- generate_cbom
- validate_bom_schema
- check_references_and_coverage
- evaluate_crypto_policy
- publish_boms_with_artifact_digest应分别验证三件事：
- 格式有效性：是否符合所选版本的 CycloneDX schema。
- 数据质量：资产引用是否完整，扫描范围是否清楚，清单是否对应当前制品。
- 策略符合性：已识别的实际用途是否违反组织批准的密码策略。
通过 schema 校验只能说明结构符合要求，不能证明资产发现完整或密码配置安全。
推广初期可以先建立基线、收集告警并校正误报，再对证据充分、规则明确的问题设置阻断。例外应有负责人、原因和到期时间，避免长期失去跟踪。
谁负责生成、维护和整改？
可以采用以下分工：
| 角色 | 建议职责 |
|---|---|
| 应用团队 | 维护应用侧采集配置，确认使用场景，处理代码和依赖中的问题 |
| 平台或 DevOps 团队 | 提供 CI 模板、工具版本管理、制品绑定、存储和查询能力 |
| 安全或密码专家团队 | 制定采集要求与密码策略，评估风险，审批例外 |
| 运维或基础设施团队 | 维护部署侧证书、TLS、KMS、HSM 等信息，并跟踪运行环境变化 |
每个应用都应有一个明确的责任团队，负责确认其密码资产信息。集中平台负责汇总和追踪，整改任务分派给实际控制代码、配置或基础设施的团队。
实施时还要注意什么？
CBOM 应记录管理和判断风险所需的元数据，不应收录私钥、密码、访问令牌或其他秘密值。采集日志也应遵守这一要求。
选择工具时，应验证它对目标语言、产物和配置的实际覆盖能力，以及消费端对密码资产字段的支持。现有依赖扫描器能生成 SBOM，并不意味着它一定能识别应用的密码使用。
备注：内容仅供参考。