2026 年的 Syft：给想让 SBOM 生成始终贴着制品走的团队的一篇项目介绍

这里放一张真实维护者肖像很合适，因为 Syft 的价值落在程序性的那一层，而且始终贴着制品本身：先把真实存在的内容编目，再交给下游安全与合规工具去解释这份清单。[9]

很多关于 SBOM 的讨论，起点都放晚了一步。团队先谈合规期限、漏洞噪声，或者审计方究竟要 SPDX 还是 CycloneDX，随后才回头问，这份清单究竟该怎样生成。Syft 值得重视，正在于它把起点放回更早的层面。它是一件 CLI 工具，也是一套 Go library，职责是把真实构建出来、真实准备交付的对象编目出来；这个对象可以是容器镜像、源码目录、单个文件，也可以是一份归档文件。[1][2] 放在 2026 年看，更贴切的读法，是把它看成一台守在制品身边的 inventory engine，先于完整供应链控制平面的想象。

截至 2026-05-05T02:06:06Z UTC，GitHub 显示 anchore/syft 有 8,877 stars、854 forks、611 个 open issues，最近一次 push 时间是 2026-05-04T18:31:10Z。[8] 当前最新 tag 是 v1.44.0，发布时间是 2026-05-01。[7] 这些数字当然不能单独证明每条构建链都该接入 Syft，不过它们至少说明，这是一件还在持续推进、并非靠旧一轮供应链话语残留热度维持存在感的项目。

配图说明：题图没有使用锁头图标，也没有使用泛化的“网络安全”视觉，而是用了 Syft 贡献者 Alex Goodman 的真实 GitHub 肖像。这个选择贴题，因为本文讨论的是围绕 package discovery、source handling 与 output fidelity 展开的低戏剧性工程工作，距离象征性的安全姿态很远。[9]

一条 inventory 表面，对应多种 source type

Anchore 的 architecture notes 给出了最干净的描述：syft package 接收一个 source.Source 对象，再把它 catalog 成一个 sbom.SBOM 对象。[1] 这条抽象很重要，因为它把项目重心收得非常稳。Syft 并没有围绕某一种语言生态，也没有只围绕某一种运行时去组织自己。它真正围绕的，是把多种“像软件制品的东西”送进同一套 inventory model。

Supported Scan Targets 文档把这件事落到了实际行为上。Syft 能从容器镜像、目录、文件与归档文件生成 SBOM，而且在很多场景里，它可以根据输入自行判断 target 类型并完成 catalog。[2] 这看上去像是方便功能，真正重要的地方却在另一层：它让团队可以把 inventory generation 放在真正运行和交付的对象旁边，放在 CI 里的镜像边上，放在主机上的 filesystem 边上，或者放在打包前后的 repository 目录边上。

Syft 最强的一点，也正在这种贴身距离里。SBOM generation 一旦离开真实制品，飘到纯声明层，清单就会慢慢失去对“实际被装进去了什么”的握力。Syft 的设计，正是在尽量把这种漂移压住，让 inventory 始终贴着制品走。[1][2]

cataloger 会变化，因为证据本身就在变化

真正让 Syft 超出“扫一下然后吐一份 JSON”这一层的，是 cataloger 文档。Syft 不会在所有场景里使用同一套固定 discovery strategy。它会根据当前扫描对象，自动切换 cataloger 集合。[3] 扫描 container image 时，默认行为偏向已经安装完成的 packages；扫描 directory 时，它又可以同时看见已安装内容与声明出来的 dependencies，例如 requirements.txt、setup.py 等文件里的信息。[3]

这条差异并非修饰性的。它是一种关于准确性的判断。文档把理由写得很清楚：manifest file 经常只表达意图，版本范围也常常不封死；镜像里的安装结果却能证明，构建真正结束之后到底落下了什么。[3] 也因此，Syft 在 build path 走得比较靠后、已经能够观察 resolved dependencies，同时又没有晚到失去跟制品同行的机会时，会显得特别有力。

放在执行层面上，最值得团队先问的一句，其实很窄：我们要编目的，是声明过的意图，还是安装后的现实，还是两者都要。Syft 能支撑这三条路，不过它不会把它们稀里糊涂揉成一团。[2][3]

格式选择是一条 workflow boundary，并非换皮导出

Output Formats 文档把另一个常见误区也照得很亮。Syft 支持多种格式，包括 native JSON、SPDX、CycloneDX，也支持在同一次运行里输出多份不同格式的结果。[4] 可文档同样说得很直白，这些格式存在差异。Syft 自己的 JSON 会保留更完整的信息，包括更丰富的 metadata、relationships 与 file details；标准格式为了适配目标 schema，某些数据会被省略，或者被改写成更窄的结构。[4][5]

这条边界很有价值。若你的下游世界更在意交换、汇总与生态兼容，那么 SPDX 或 CycloneDX 就是更合适的出口表面。[4] 若眼前更重要的是先保住扫描时最完整的证据，再在后续需要时转成标准格式，那么 Anchore 自己的 JSON guide 给出的建议很直接：先把 SBOM 以 Syft JSON 留下，再按需要派生出别的格式。[5]

放到 2026 年的研究语境里，这个判断显得更有分量。2026 年 1 月的一篇 SBOM standards and tools 实证研究指出，工具与规范之间的 adherence gap 会给下游使用造成真实扰动。[10] 顺着这个角度看，Syft 对格式边界的强调非常值得保留。真正该问的问题，应该落在“我在把证据压进别人的 schema 之前，先把最完整的证据留住了没有”，先于“哪种格式听上去更标准”。

attestation 把 inventory 推向 trust

在 inventory generation 之后，Syft 的 attestation guide 给出了下一步：用 in-toto 与 Sigstore 生成带签名的 SBOM attestation。[6] 当前文档仍然把这项能力明确标成 experimental，这一点很重要，也应当原样保留。[6] 功能是存在的，成熟度边界也同样写在台面上。

即便如此，这套设计依然很结实。Syft 支持通过 OIDC 身份走 keyless attestation，也支持团队自己管理密钥的 key-based attestation。[6] 两条路径最后都把 attestation 挂到 OCI registry 里的 image 上，校验则通过 cosign verify-attestation 完成。[6] 由此，SBOM 就不再只是躺在 CI 日志或构建产物目录里的孤立报告文件，它会进入镜像分发路径本身。

也正是在这里，Syft 从“inventory helper”往前迈了一步，变成一件更像 build artifact primitive 的工具。它依旧不负责判断 exploitability，不负责给出 policy 结论，也不负责替团队安排 remediation priority。它负责的，是把 inventory 生成出来，再把 inventory 以可验证的方式系在制品上。[6]

适合它的边界，与不适合它的边界

当团队希望 SBOM generation 始终贴着制品，同时又想保留下游流向上的灵活性时，Syft 会很强。这包括 image pipeline、release engineering、内部 package publishing，也包括那些需要一套生成器同时覆盖 containers、directories、archives，再根据对象把结果导向标准 schema 的合规流程。[2][4][5]

不适合它的边界，也需要说清楚。一旦团队期待 Syft 单独回答完整的安全问题，理解就会开始偏移。Syft 能告诉你有什么，能把 inventory 输出成标准格式，也能把签名 attestation 附着到 OCI artifact 上。[4][5][6] 它不能单独决定哪一条漏洞真正需要优先处理，也不能单独决定哪一条 policy 需要豁免。这些都属于更下游的分析与治理问题。

所以，理解 Syft 更适合走“项目介绍”这条路，而不适合把它写成一份万能判词。到了 2026 年，它之所以值得看，是因为它把一件困难而基础的事守得很清楚：software inventory 应当从制品本身开始，discovery logic 应当顺着眼前证据类型切换，在把结构压缩进后续 reporting lane 之前，先尽量把原始结构保留下来。[1][2][3][4][5][6][10]

cronfeed.work