anchore/syft

如果你需要清点一个容器镜像或目录里实际包含哪些软件包，并希望用标准格式交给其他工具消费，Syft 值得一试。它是一个专注的命令行工具和 Go 库，而不是完整的安全平台，扫描和处置决策仍在它之外。

解决什么问题

你要发布一个容器镜像或文件系统，需要快速回答里面有哪些包、版本是多少。现在往往靠人工翻语言锁文件、发行版包列表和镜像层，或者依赖仓库提供的元数据。Syft 改成一条命令遍历目标，同时识别多个生态的包，输出一份 SBOM，可以归档、在版本间对比，或交给扫描器。于是问题从“我们装了哪些东西”变成“这个交付物里到底有什么”。

有什么不同

Syft 的核心做法是广谱、多来源的包识别：读取各生态已经留下的元数据，覆盖 Alpine apk、Debian dpkg、RPM、Go、Python、Java、JavaScript、Ruby、Rust、PHP、.NET 等，而不是只看某一个包管理器的视角。扫描目标包括容器镜像、文件系统、归档文件，以及 OCI、Docker、Singularity 等镜像格式；输出支持 CycloneDX、SPDX 和 Syft 自有 JSON，还能在 SBOM 格式之间转换。这个广度有现实意义：一个镜像通常混合了操作系统层和多个语言运行时，只认单一生态的工具会漏掉一部分。

作者把它定位成两件套中的“清点”环节：Syft 生成 SBOM，Grype 负责漏洞扫描。如果你已经有扫描器或策略引擎，这个拆分很实用；如果你期待一个工具直接给出 CVE 报告，这就是需要接受的边界。另一个需要留意的是识别准确度：工具报告的是能从元数据识别出来的包，通过非常规方式安装的组件可能存在于镜像中却未被列出。in-toto 签名的 SBOM 附加能力是对文档做完整性封装，并不证明所有依赖都被找到。

谁值得试

适合：需要为每次镜像构建产出 SBOM、随版本归档，或者在 CI 中批量检查镜像的平台工程师和安全工程师。一次运行同时写 SPDX 和 CycloneDX，对下游消费者格式不一致的场景很省事。也适合想在打包前快速查看本地目录包清单的开发者。

不适合：想要开箱即得 CVE 报告的人，因为 Syft 本身不做漏洞扫描，需要配合 Grype 或其他扫描器。单语言应用如果本语言的锁文件已经给出可信的依赖清单，用它收益也不明显，因为广谱检测在这里帮助有限。

使用条件与边界

Syft 是 Apache-2.0 的 Go 命令行工具与库，分发方式包括发布二进制、Homebrew、Docker、Scoop、Chocolatey、Nix 和安装脚本，无需绑定单一获取途径。CLI 与配置文档提供了详细参数说明。扫描本地 containers-storage 镜像的范围更窄：在 Linux 上必须用 --from containers-storage 明确指定，普通镜像引用不会去那里查找；rootless 存储需要在构建器的用户命名空间内读取。从源码构建支持这条路径还需要特定 build tag。如果工作流依赖 Podman 或 Buildah 的本地镜像，建议先确认这条路径再考虑标准化。

长期维护是真正的成本。新的打包生态和格式版本不断出现，SBOM 的覆盖范围取决于工具对包生态的认知，固定版本也就固定了它能识别的内容。把生成的文档当作“已检测包的清单”即可，如何存储、签名和重新扫描要另行决定。

HotRepo 点评

HotRepo 从 2026-05-10 才开始跟踪该项目，唯一记录到的日榜观察是 2026-10-28：9,778 星，当天 +14。这只是一个快照，不是趋势序列，无法据此判断热度能否持续；2020 年以来的项目历史也不能说明当前势头。如果你缺的正是跨混合生态、标准格式的 SBOM 生成，Syft 是对口的选择；在投入之前，先用扫描目标和输出格式文档确认下游要求的格式和范围，并想清楚与 Grype 的衔接如何放进现有流水线。