结论：先在隔离流水线试点，优先于构建时生成 SBOM 并与构建产物一起归档。只有生成成功、内容可核验、清单能追溯到具体产物，才适合推广；若在构建后单独生成，还要额外确认依赖图没有变化。Swift 6.4 已确认提供 SPDX 与 CycloneDX 生成功能，但 SBOM 本身不等于完整的供应链安全证明。(Swift 6.4 发布说明)
谁该看这篇：企业安全或合规负责人，需要把物料清单落实到交付证据中。
CI 平台负责人，准备将 SwiftPM 的生成流程接入 macOS 流水线。
iOS/macOS 技术负责人，需要确认依赖清单是否对应实际构建产品。
最后更新于 2026 年 10 月 7 日；功能状态与命令行为核对自 Swift 6.4 发布说明、SE-0509 实现说明及 SwiftPM 文档。企业侧验收仍须以实际 CI 记录为准。
[ SECTION_01 ] 接入前：界定 SBOM 要证明什么
先确定清单对应的是整个 Swift 包还是某个交付产品，再选用 SPDX、CycloneDX，或按审计要求同时生成两种格式。不要把“仓库里生成了一个文件”当成验收结论：它只能作为某种范围内的组件与依赖记录，不能单独证明组件没有漏洞、许可证合规，也不能覆盖清单范围之外的所有构建输入。
对 Swift Package Manager SBOM，关键差异在于它依据什么依赖信息生成。包依赖图反映解析出的包关系；构建依赖图则可用于判断特定构建实际使用了哪些组件。SE-0509 说明构建时生成可结合 SwiftBuild 构建依赖图，单独生成命令则不会调用构建，也不使用该图。
这也划出了覆盖边界：SwiftPM 生成结果不应被表述为整个 iOS 应用的依赖全貌。项目若还包含非 SwiftPM 管理的 SDK、预编译二进制、系统组件或独立打包步骤，应由对应团队确认如何补充清单或关联证据。包清单和发布产品清单的范围不同，交付规则要明确写出。
[ SECTION_02 ] 试点前：盘点项目、工具链与责任人
先逐仓库记录实际发布目标、构建入口和依赖管理方式。确认流水线调用的是 SwiftPM 命令还是 Xcode 项目构建；核对 Package.swift、Package.resolved 的位置及其是否纳入版本控制。Apple 平台项目中的解析文件可能位于 .xcodeproj 或 .xcworkspace 内，不能只检查仓库根目录。(Swift PackageDescription 文档)
Package.resolved 记录依赖解析结果；流水线如果触发重新解析，就可能让本次 SBOM 描述的依赖状态偏离原构建输入。SwiftPM 文档也说明，包解析会在运行 swift build 等命令时自动发生。(SwiftPM 添加依赖文档) 因此，试点时要保存构建前后的锁定文件状态，并标记哪些模块、二进制或外部步骤不在该清单的覆盖范围内。
责任分工也要在接入前确定：应用团队维护产品范围与依赖锁定；CI 平台团队固定工具链、生成命令和归档位置；安全或合规团队定义格式、核验要求及失败处置。若只有平台团队负责“把命令跑通”，却无人确认清单内容与发布物之间的关系，流程仍未完成验收。
[ SECTION_03 ] 第一次试点：在隔离任务中固定输入
从非生产分支或独立 CI 任务开始，不要一开始就在全部发布流水线上切换。固定 Swift 6.4 工具链和提交标识，确保试点构建使用的 Package.resolved 与预期一致。每次运行都记录命令、退出状态、日志和输出目录；这样失败时才能区分是工具链不支持、依赖解析变化，还是清单归档环节出错。
构建时生成可先采用以下命令，在实际仓库确认产品范围和输出行为：
swift build --sbom-spec cyclonedx
若组织采用 SPDX，将格式参数替换为 spdx；需同时交付两种格式时，按官方命令说明分别指定格式。特定产品可用 --product 收窄目标；需要指定输出位置时，先按该工具链对应的 SwiftPM 文档核对可用参数，再在隔离任务中验证文件确实写入预期目录。SwiftPM 的包依赖由包清单和依赖关系共同定义，产品、目标的边界也需结合项目配置核对。(SwiftPM 包结构文档)
[ SECTION_04 ] 生成路径怎么选：按证据强度而不是方便程度
| 路径 | 适合的情况 | 核验重点 | 主要风险 |
|---|---|---|---|
swift build 构建时生成 |
能在正式构建命令中加入清单生成，且需要将结果绑定到该次构建 | 命令退出状态、实际产品范围、SBOM 与归档产物关联 | 构建范围设错，或项目其他依赖未纳入 SwiftPM 清单 |
swift package generate-sbom 单独生成 |
不便或不允许再次构建，但仍需生成包级清单 | 生成时的工具链、Package.resolved、生成前后依赖图与原构建记录 |
单独命令依据包依赖图，不使用构建依赖图，图变化时清单可能不对应原产物 |
两条路径的差别不是文件格式，而是证据与构建的距离。swift build 的 SBOM 生成可以利用构建依赖图；swift package generate-sbom 不会构建，也不使用 SwiftBuild 构建依赖图。后者还会提示清单可能不够准确；官方提案指出，若构建完成后依赖图发生变化，单独生成的清单就可能无法准确反映该构建。(SE-0509 提案)
SPDX 与 CycloneDX 是不同的清单格式，不是“完整”与“不完整”的等级划分。由安全或合规团队先确认消费系统、审计要求和归档约定，再让流水线按约定输出。若组织接受单独生成路径，应使用 --disable-automatic-resolution 检查解析状态；是否满足企业的依赖锁定要求，还必须以项目实际 CI 验证结果判断。
[ SECTION_05 ] 生成后：核验内容并绑定交付物
把同一提交的构建日志、工具链标识、SBOM 和最终归档制品放在一起检查。重点确认清单所指范围是包还是产品，预期依赖是否出现，产品与组件关系是否合理；不要只用“JSON 文件能解析”替代内容核验。SwiftPM 文档将产品、目标和依赖作为包结构的重要组成部分，验收时应据此对照实际构建入口。(SwiftPM 包结构文档)
| 验收项 | 通过时应留下的证据 | 不通过时的处理 |
|---|---|---|
| 输入一致 | 提交标识、Swift 工具链、依赖锁定文件状态 | 暂停该试点放量，检查是否发生重新解析 |
| 范围正确 | 产品名称、SBOM 格式、预期组件与依赖关系 | 回到包清单、产品配置和构建入口排查 |
| 产物可追溯 | SBOM 与构建记录、发布归档物之间的关联 | 不将该 SBOM 作为该产物的验收证据 |
| 失败可处置 | 生成日志、失败状态及责任团队处理记录 | 修复生成或归档流程后重新验收 |
发现预期依赖遗漏、生成失败，或清单与制品无法建立关联时，应暂停推广并回到构建路径排查。对构建后生成的清单，还要将生成前后的依赖图与原构建记录比对；不能证明一致，就不能把它标记为该产物的准确 SBOM。
[ SECTION_06 ] 灰度推广：按准入条件决定部署方式
决策条件：
- 若流水线可以在目标产品的构建命令中生成 SBOM，并能将其与构建产物一并归档，选构建时生成。
- 若构建后才有生成需求，且能固定解析状态、核对前后依赖图并关联原构建记录，可试点单独生成；缺少这些证据则回退到构建时生成。
- 若清单范围包含 SwiftPM 以外的 SDK、二进制或打包环节，先补齐范围说明与相应证据，再决定是否准入。
- 若生成失败、清单内容无法核验或产物关联缺失，暂停放量；不要把警告模式或“文件已生成”直接视作合规通过。
试点通过后，再决定逐仓库推广、由平台团队统一接入，还是暂缓部分项目。每个验收记录至少要能追溯工具链、提交、SBOM 文件、关联构建产物和失败处置结果。SwiftPM 文档已列出 SBOM 生成功能，并提供 CI 工作流相关主题；具体参数行为仍应按所用工具链和仓库验证。(SwiftPM 文档)
对于 Mac CI 承载方式，不必为了启用 SBOM 先假设需要新增机器；先检查现有节点是否能固定工具链、保存日志与归档物，并满足团队的权限和隔离要求。若团队要比较远程 Mac 的承载选择，可查看 NOVAKVM 的 Mac 服务入口及 Mac 配置选项，再用真实流水线验证工具链、产物留存和访问权限。它们不能替代项目自身的 SBOM 验收，也不构成性能或成本优势的证明。
最终选择应回到证据链：本地固定节点适合已有设备、维护能力充足且负载稳定的团队；临时试点或需要独立 macOS 环境时，远程 Mac 租赁可以减少先行购置设备的承诺，但仍需评估访问控制、环境隔离和交付留存。现有通用 CI 环境若缺少 macOS 执行条件，会增加环境切换与产物关联步骤；自购 Mac 则需要自行承担设备采购、维护和闲置管理。若团队当前缺的是可控的 macOS 试点环境，可将 NOVAKVM 纳入方案比较；先用真实流水线完成验收，再决定是否长期承载。
常见问题
Swift 6.4 的 CI 构建流程里怎样生成 SBOM？
在隔离任务中使用 Swift 6.4 工具链运行构建命令，并通过 --sbom-spec 指定 CycloneDX 或 SPDX；若企业要求两种格式，可分别生成并分别校验。先确认当前目录、产品范围和依赖锁定状态，再将命令日志、SBOM 与构建产物关联归档。发布前应在实际流水线验证命令退出状态和产物位置，不能只以文件存在作为验收结果。
SwiftPM 单独生成 SBOM 和构建时生成，差别在哪里？
构建时生成可使用构建依赖图帮助判断实际构建所用组件；单独运行 swift package generate-sbom 不会再次构建，也不使用 SwiftBuild 的构建依赖图，而是根据包依赖图生成。后者适用于不便重跑构建的场景，但必须确认 Package.resolved 未变化，并核对清单所描述的依赖与原构建记录一致。
如何判断 Swift 6.4 SBOM 对应的是实际发布产品？
将 SBOM、源代码提交标识、工具链版本、构建记录和归档产物放在同一条可追溯关系中。检查清单标识的是整个包还是指定产品，并对照依赖关系与实际构建记录；若采用构建后生成，还要确认生成前后解析图没有变化。无法建立对应关系的清单不能作为该发布产物的验收证据。
生成的 Swift SBOM 应该和 CI 构建产物一起保存吗？
应当将 SBOM 与对应构建产物及构建记录一起归档，而不是只留在临时工作目录。归档信息至少要能识别源提交、工具链、清单格式和产品范围；具体保留期限与访问权限由企业审计和合规要求确定。这样出现依赖告警或审计抽查时，才能判断清单描述的是哪次构建，而不是同一仓库的其他版本。