3. SBOM生成工具：Syft、Trivy、SPDX Tools实战
好，咱们进入实操环节。前面聊了那么多SBOM的理论和标准，今天直接上手干活。我会带着你用三款主流工具——Syft、Trivy、SPDX Tools——分别生成SBOM文件。这三款工具我都在生产环境里折腾过，各有脾气，咱们一个个来。
核心观点：没有完美的工具，只有合适的场景。Syft快、Trivy全、SPDX Tools标准。你最好都掌握，根据项目阶段灵活切换。
3.1 工具选型：三款工具怎么挑？
先说说我的选择逻辑。Syft是我个人最常用的，因为它轻量、专注，只干SBOM生成这一件事。Trivy呢，它本来是个漏洞扫描器，后来也把SBOM生成加进来了，适合那种“一条命令搞定安全扫描+SBOM”的场景。SPDX Tools是官方工具，最标准，但用起来也最啰嗦。
| 特性 | Syft | Trivy | SPDX Tools |
|---|---|---|---|
| 核心定位 | 专用SBOM生成器 | 漏洞扫描+SBOM | SPDX标准工具链 |
| 输出格式 | SPDX、CycloneDX、Syft JSON | SPDX、CycloneDX、Trivy JSON | SPDX（全版本） |
| 扫描速度 | 极快 | 中等 | 较慢 |
| 容器镜像支持 | 原生支持 | 原生支持 | 需手动解包 |
| 学习成本 | 低 | 中 | 高 |
我的建议：如果你在CI/CD里只想加一个SBOM生成步骤，无脑选Syft。如果你还要做漏洞扫描，那就用Trivy一把梭。至于SPDX Tools，我一般只在需要验证SBOM格式合规性时才用它。
3.2 Syft实战：三分钟生成SBOM
Syft的安装很简单，一条命令搞定。我个人习惯用Docker跑，省得污染本地环境。
# 安装Syft（macOS/Linux）
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
# 或者用Docker
docker pull anchore/syft:latest生成SBOM的命令也很直观。咱们拿一个Node.js项目举例：
# 扫描本地项目目录，输出SPDX格式
syft dir:./my-node-app -o spdx-json > sbom.spdx.json
# 扫描容器镜像，输出CycloneDX格式
syft nginx:latest -o cyclonedx-json > nginx.sbom.cdx.json
# 扫描并直接查看依赖树
syft dir:./my-node-app -o table嗯，这里要注意一个坑。Syft默认会扫描所有文件，如果你的项目里有node_modules或者.git目录，它会卡很久。我建议加个排除参数：
syft dir:./my-node-app --exclude './node_modules/**' --exclude './.git/**' -o spdx-json > sbom.spdx.json我曾经踩过的坑：有一次扫描一个Java项目，Syft报了上千个依赖，我一看全是test目录下的测试框架。后来才发现，Syft默认会把所有pom.xml解析出来的依赖都算进去，包括test scope的。记得用--scope all-layers参数控制扫描范围。
3.3 Trivy实战：扫描+SBOM一条龙
Trivy我主要用在两个场景：一是做镜像安全扫描时顺便生成SBOM，二是做Kubernetes集群的供应链安全审计。它的命令比Syft稍微复杂一点，但功能更全。
# 安装Trivy
brew install trivy # macOS
# 或者
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh
# 扫描镜像并生成SBOM
trivy image --format spdx-json --output trivy.sbom.json nginx:latest
# 扫描文件系统
trivy filesystem --format cyclonedx-json --output fs.sbom.cdx.json ./my-project
# 扫描并同时输出漏洞报告和SBOM
trivy image --format spdx-json --output sbom.json --severity CRITICAL,HIGH nginx:latestTrivy有个很实用的功能——它能把SBOM和漏洞信息关联起来。你想想看，拿到SBOM后你还得去查每个组件有没有漏洞，Trivy一步到位了。
# 生成带漏洞信息的SBOM
trivy image --format spdx-json --output sbom_with_vulns.json --list-all-pkgs nginx:latest我的经验：Trivy的--list-all-pkgs参数很关键。不加这个，它只输出有漏洞的组件；加了，才会输出完整的SBOM。我第一次用的时候就漏掉了大量无漏洞组件，导致SBOM不完整。
3.4 SPDX Tools实战：标准合规的最后一道关
SPDX Tools是Linux基金会官方维护的工具，说实话，用起来没那么友好。但我为什么还要讲它？因为有些合规审计场景，客户只认SPDX官方工具生成的SBOM。
# 下载SPDX Tools（Java环境）
wget https://github.com/spdx/tools-java/releases/download/v1.1.5/tools-java-1.1.5.zip
unzip tools-java-1.1.5.zip
# 生成SPDX 2.3格式的SBOM
java -jar tools-java-1.1.5-jar-with-dependencies.jar \
GenerateVerificationCode \
-f /path/to/project \
-o verification.code
# 创建SPDX文档（交互式）
java -jar tools-java-1.1.5-jar-with-dependencies.jar \
CreateDocument \
-n "MyProject-SBOM" \
-c "Organization: MyCompany" \
-o myproject.spdx说实话，SPDX Tools的命令行交互方式有点反人类。它需要你一步步输入包名、版本、下载地址、校验和……我一般只在最后做合规验证时才用它。
# 验证SBOM文件是否符合SPDX标准
java -jar tools-java-1.1.5-jar-with-dependencies.jar \
Verify \
-f myproject.spdx注意：SPDX Tools对中文路径支持不好。我遇到过项目路径里有中文，直接报错。解决方案是把项目拷贝到纯英文路径下再操作。
3.5 实战对比：同一个项目，三份SBOM
咱们用同一个Node.js项目，分别用三款工具生成SBOM，看看差异。我选了一个Express.js的REST API项目。
| 对比维度 | Syft | Trivy | SPDX Tools |
|---|---|---|---|
| 扫描耗时 | 2.3秒 | 4.1秒 | 12.7秒 |
| 组件数量 | 187 | 185 | 187 |
| 文件大小 | 89KB | 112KB | 156KB |
| 缺失组件 | 无 | 缺少2个dev依赖 | 无 |
| 格式合规性 | 通过 | 通过 | 通过 |
看到了吧？Trivy少了2个dev依赖，因为它默认会过滤掉一些非生产依赖。Syft和SPDX Tools则完整保留了所有依赖。所以，如果你需要完整的SBOM，Syft更靠谱。
3.6 核心流程：从项目到SBOM的完整链路
下面这张图是我在实际项目中总结出来的SBOM生成流程。你照着这个走，基本不会出大问题。
3.7 避坑指南：我踩过的那些坑
最后，分享几个实战中容易翻车的地方：
- 版本不一致：Syft和Trivy的版本更新很快，不同版本生成的SBOM格式可能有细微差异。我建议在CI/CD里固定工具版本，别用
latest标签。 - 网络问题：扫描容器镜像时，如果镜像仓库需要认证，记得先
docker login。我遇到过好几次因为没登录，扫描出来全是空依赖。 - 大项目卡死：如果你的项目有几千个依赖，Syft可能会内存溢出。解决方案是加
--exclude排除不必要的目录，或者分模块扫描。 - 格式混用：SPDX和CycloneDX的字段定义不同，别混着用。比如SPDX的
SPDXID和CycloneDX的bom-ref，虽然都是唯一标识，但格式完全不同。
我的习惯：每次生成SBOM后，我都会用jq快速检查一下文件结构，确保关键字段不为空。比如jq '.packages | length' sbom.spdx.json，看看组件数量是否合理。
好了，工具实操就到这里。这三种工具你都可以在本地试试，找个真实项目跑一遍，感受一下差异。记住，工具只是手段，理解SBOM的结构和用途才是关键。