cyclonedx.net 是 c# 项目生成合规 sbom 最稳选择，原生支持 .net 生态，推荐 cli 或 msbuild 集成；spdx 应通过 syft 转换生成；验证需覆盖语法、模式、语义三层。
用 CycloneDX.NET 生成 SBOM 文件最稳
直接上结论：C# 项目现阶段生成合规 SBOM，CycloneDX.NET 是最省心的选择。它原生支持 .NET 生态（包括 csproj 解析、NuGet 依赖提取、.NET SDK 版本识别），不用自己扒 obj/project.assets.json 或硬解析 packages.lock.json。
常见错误是试图手写 CycloneDX JSON/XML 结构——字段嵌套深、必填项多（比如 bomFormat、specVersion、serialNumber 必须严格匹配规范），稍错一个就导致下游工具（Syft、Dependency-Track）拒收。
- 安装
CycloneDX.DotNetCLI 工具：dotnet tool install --global CycloneDX.DotNet.Cli - 在项目根目录运行：
cyclonedx . -o bom.json --include-bom-serial-number --include-os-packages（--include-os-packages仅当项目含native依赖时才需） - 若需嵌入到构建流程，改用 MSBuild 集成：
dotnet add package CycloneDX.MsBuild，它会在dotnet build后自动生成bom.json
SPDX 在 C# 里基本不现实
别费劲用 C# 直接生成 SPDX 文档。官方 spdx-tools 是 Python 写的，.NET 生态里没有成熟、持续维护的 SPDX 生成库。有人试过用 Newtonsoft.Json 手拼 SPDX JSON-LD，结果卡在 creationInfo 的 created 时间格式（ISO 8601 带时区）、documentNamespace 的 URI 规则（必须含唯一 UUID）、许可证表达式语法（如 Apache-2.0 OR MIT）校验失败。
真实场景中，C# 项目若被要求交付 SPDX，通用做法是：先用 CycloneDX.NET 生成 bom.json，再用 syft（CLI）转成 SPDX：syft . -o spdx-json > spdx.json。Syft 底层用 Go 实现，对 .NET 依赖识别足够准，且输出通过 SPDX 3.0 官方验证器测试。
验证 SBOM 不是“打开看看”
生成完文件，不能只靠眼睛扫一眼 components 数量对不对。真正有效的验证分三层：
- 语法层：用
jq '.' bom.json 2>/dev/null || echo "invalid json"确保是合法 JSON；对 XML 格式用xmllint --noout bom.xml - 模式层：下载对应 CycloneDX XSD 或 JSON Schema（如
https://cyclonedx.org/schema/bom-1.5.schema.json），用ajv或Newtonsoft.Json.Schema加载验证——注意$schema字段必须和实际 schema 版本一致，否则验证永远通过 - 语义层：检查关键字段是否合理，例如所有
component的type是否为library/framework（不是application），version是否非空，licenses下是否有expression或license至少其一
CI 中生成 SBOM 容易漏掉的点
本地能跑通，放到 GitHub Actions 或 Azure Pipelines 就失效，多数因为路径和权限错位：
-
cyclonedxCLI 默认从当前目录找.csproj，但 CI 中工作目录可能是 repo 根，而项目在src/MyApp/子目录——必须显式指定路径：cyclonedx src/MyApp/ -o bom.json - 若项目用了
Directory.Packages.props全局包版本控制，CycloneDX.DotNet旧版本（ - 生成的
bom.json默认不含构建环境信息（如tool名称、版本），加--include-tool-info参数才能让tool节点出现，否则某些合规扫描平台报“元数据不完整”
SBOM 不是打包附属品，它是依赖关系的权威快照。时间戳、序列号、组件哈希值任何一个出错，整个文件的可信度就归零。生成脚本里别图省事省掉 --include-bom-serial-number 或硬编码时间字符串。
