就开始了对第二个工具CycloneDX的研究，这个工具生成的是符合CycloneDX标准的SBOM，这里我也是将其作为dotnet工具进行全局安装的（安装命令：dotnet tool install --global CycloneDX），需要注意的是不要使用旧的项目，如.NET Framework的项目来使用此工具，我这边就是在NET Framework中使用了此工具进行生成，怎么走都没通，之前就是忽略了网上AI资料所提的，SycloneDX for .NET目前不支持早期的版本，.NET Framework，.NET Core的早期版本(如NET Core 2.1，NET Core 3.1，NET Core 5.0)，后来拿公司的一个.NET 8项目来尝试使用此CycloneDX，立马就能走通了。但在C#项目下，CycloneDX 默认情况下它会分析项目的 NuGet 包依赖（包括直接和传递依赖），但不会自动包含项目引用（Project References）所生成的 DLL 文件，因为这些 DLL 被视为"内部组件"而非外部第三方依赖。作为解决办法，从 CycloneDX .NET 工具 v2.0+ 开始，官方支持通过命令行参数显式包含项目引用。使用 --include-project-references 参数，注意，此时就需要使用工程目录，而不能使用解决方案目录,即.csproj文件，而非.sln文件。在只有.dll文件，即随便拷贝一个外部无用的.DLL文件放在编译后的输出目录中，CycloneDX .NET不会自动识别其组成，即SBOM中没有此项。若需要的话可以将其作为一个NuGet私有源进行引入。
使用CycloneDX生成SBOM的参考命令：
命令示例：dotnet cyclonedx ..\CSharp_Sbom.sln --output-format json --exclude-dev --exclude-test-projects -sn YourCompany -sv 1.0.0 -o ..\SbomScript\CycloneDX_sbom -fn sbom.json
在C#项目中使用CycloneDX工具时，也是顺利的生成了需要的SBOM，但是当在C++项目上生成时，这里先说下，使用的C++项目时临时创建的，无标准的包管理器，也没有用CMake，Conan或vcpkg管理依赖。最终生成出来的sbom文件中确没有任何组件或者说没有任何依赖，也就是json文件中的dependencies元素里面没有包含任何东西。也就是无法直接使用这个工具来生成C++项目的SBOM,这就尴尬了。后来查资料大概意思是说：因为C++缺乏统一的依赖管理机制（如 Java 的 Maven 或 Node.js 的 npm , C#的NuGet），不能直接解析依赖信息。
Syft
然后就开始了我的第三个工具Syft的研究，Syft会自动扫描，检测构建产物中的二进制文件和动态链接库来识别第三方组件，自动识别提取生成依赖包，并输出SBOM。支持格式：CycloneDX、SPDX、Syft JSON 等，是由 Anchore 开发的开源 CLI 工具，是Go语言编写。
Syft生成SBOM参考命令： syft . -o cyclonedx-json=../../sbom/syft/syft.cdx.json -vv
-v 输出警告信息
-vv 输出调试信息
使用Syft确实能做到自动识别C++的项目生成SBOM，但也仅仅是有限的支持，即仅能识别已知特征的库，无法还原完整依赖树（尤其静态链接、动态加载的以及自定义编译的库），只因C++项目无包管理器或者说有些C++项目没有使用统一的一套包管理流程，纯 CMake/Makefile + 静态链接情况下，只有Syft可行。能从二进制中识别 OpenSSL、zlib、libpng、glibc 等常见库（即使静态链接），经过一番折腾，这里又看到了另外一个工具OSS Review Toolkit (ORT) ，但经过了解下来说这是一个全流程的合规审计工具，因为目前只需要一个SBOM快速生成工具，貌似学习使用曲线更高，一下子就吓到了我这种懒人，也就懒得研究了。
最后附上一个简单的总结对比说明：
