软件供应链安全事件频发的当下，SBOM（Software Bill of Materials，软件物料清单）已经成为安全合规领域的高频词汇。无论是美国行政令的强制要求，还是国内监管政策的逐步落地，越来越多的团队需要在交付软件时同时交付一份完整的组件清单。Syft是Anchore公司开源的一款SBOM生成工具，它能够扫描容器镜像和文件系统，识别其中包含的软件包与依赖，并输出SPDX、CycloneDX等标准格式的清单文件。本文将从SBOM的概念讲起，完整演示Syft的安装、基本使用、格式选择以及进阶技巧。
一、什么是SBOM，为什么需要Syft
SBOM可以理解为软件的成分表，就像食品包装上的配料清单一样，它完整记录了一个软件中包含的所有组件、依赖库及其版本信息、许可证等元数据。有了SBOM，当某个开源组件爆出高危漏洞（例如经典的Log4j事件）时，团队可以在几分钟内排查自己的资产是否受影响，而不需要逐个项目翻查依赖文件。
SBOM有两大主流标准格式：一个是Linux基金会主导的SPDX，另一个是OWASP主导的CycloneDX。两者都支持JSON和XML等多种序列化方式，区别在于SPDX更偏向许可证合规场景，元数据字段非常完善；CycloneDX则更轻量，与漏洞扫描和安全分析工具的集成度更高。实际工作中，面向甲方交付或合规审查时常被要求SPDX格式，而做内部安全扫描时CycloneDX使用更多。
为什么选择Syft？因为它免费开源、安装简单、支持多种输入源（本地目录、容器镜像、OCI tar包等），内置了庞大的包识别目录库，能识别几百种操作系统的软件包类型和各类语言生态的锁文件依赖，生成速度和准确率在同类工具中都处于第一梯队。
二、Syft的安装与基本使用
Syft提供多种安装方式，最简单的是官方安装脚本，在Linux或macOS上执行一条命令即可完成安装：
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
如果你使用macOS且安装了Homebrew，直接执行brew install syft即可。Windows用户可以通过scoop安装，或者从GitHub的Release页面下载可执行文件。安装完成后执行syft version验证是否可用。
最基础的用法是对本地目录生成SBOM：
# 扫描当前目录，输出格式为syft默认的table格式 syft dir:./my-project # 输出SPDX JSON格式并保存到文件 syft dir:./my-project -o spdx-json -o sbom.spdx.json
Syft的输入源采用类型:路径的写法，常用的包括dir:（本地目录）、registry:（远程镜像仓库）、docker:（本地Docker守护进程中的镜像）、oci:（OCI格式的镜像tar包）。例如直接扫描Docker Hub上的alpine镜像：
# 从远程仓库拉取镜像并生成CycloneDX格式SBOM syft registry:alpine:3.19 -o cyclonedx-json -o alpine.sbom.json
执行后终端会以表格形式列出识别出的所有软件包，包含包名、版本、类型和许可证信息。生成的JSON文件可以直接提交到版本库，或上传到SBOM管理平台做集中分析。
三、格式选择、范围控制与进阶技巧
Syft支持的输出格式非常丰富，通过-o参数指定。常用的有syft-json（默认的完整格式，包含所有证据信息）、spdx-json、cyclonedx-json、cyclonedx-xml等。如果需要同时输出多种格式，可以在一条命令中重复-o参数，例如syft dir:. -o spdx-json -o a.json -o cyclonedx-json -o b.json，这在需要同时满足交付和内部扫描两种需求时非常方便。
扫描范围控制是一个容易被忽略但很实用的功能。默认情况下Syft会扫描全部内容，而通过scope参数可以调整策略：
# 只扫描镜像的Squashed层，忽略删除的文件，速度更快 syft docker:myapp:latest -o syft-json -o sbom.json --scope squashed # 扫描所有层，包括已删除文件的历史层 syft docker:myapp:latest --scope all-layers
squashed是默认值，代表镜像最终状态；all-layers则会逐层分析，能发现那些在构建过程中安装过又被删除的软件包，对安全审计有特殊价值，代价是扫描时间更长。
另一个常见需求是合并多份SBOM。Syft提供了syft convert子命令，可以在不同格式之间转换，也可以借助外部工具将多个模块的清单合并成一份总的SBOM。在CI流水线中，推荐的做法是为每个构建产物生成一份SBOM并以版本号命名归档，例如app-1.2.3.spdx.json，这样在漏洞爆发时可以快速回溯定位受影响的版本范围。
四、结合Grype完成漏洞扫描闭环
生成SBOM本身只是第一步，它的价值要通过下游消费来体现。Syft的姊妹工具Grype可以直接读取Syft生成的SBOM文件进行漏洞匹配：
# 安装Grype curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin # 基于SBOM文件进行漏洞扫描 grype sbom:./sbom.spdx.json
Grype会将SBOM中的每个组件与漏洞数据库比对，输出组件名、版本、漏洞编号、严重等级和修复版本建议。由于扫描是基于SBOM文件而非重新解包镜像，即使镜像已经被删除，只要保留了SBOM文件，随时可以重新评估风险。
这种解耦设计的另一个好处是可以接入多种分析工具。SPDX和CycloneDX都是开放标准，依赖追踪平台、许可证合规系统、漏洞管理平台基本都支持导入这两种格式。把Syft嵌入CI/CD流水线，在每次构建时自动生成SBOM并归档，再配合Grype做门禁扫描，就能搭建起一套低成本却完整的软件供应链安全保障体系。