Syft 1.48.0：SBOM 扫描覆盖 .app 与 .NET 单文件包

当天发生了什么

2026-07-16（UTC 14:47），Anchore 的 SBOM 生成工具 Syft 在 GitHub 发布了 v1.48.0。1.48.0 的新功能包括：macOS .app 编目器、Go 二进制符号捕获、vcpkg 支持、Kerberos 5 库编目、safetensors 模型类型、扫描时长与扫描日期等。修复项包括：.NET 编目器可以在 Linux ELF 单文件包中找到 deps.json 记录的包；修复 Swift 的 PURL 匹配；PE 文件扩展名大小写不敏感；修复 deno.lock 中 npm 键的处理等。发布页列出了 17 位贡献者，这些变化影响的是 SBOM 能在打包好的成品中看到什么，而不仅是源码清单。

对保护应用逻辑意味着什么

SBOM 工具首先是防守方的好帮手：发布后出现漏洞通告时，你需要快速知道哪些版本带了受影响的组件。这次更新让 Syft 能直接从更多“成品”中识别依赖，例如 macOS 应用包和 .NET 单文件包。但同样的可见性对任何拿到你发布包的人都成立：单文件打包、应用包封装并不会隐藏依赖构成，依赖清单和版本基本可以视为公开信息。新增的 safetensors 模型类型也值得注意：如果应用随包分发模型文件，它就是可以被识别和提取的资产，不应当被视为受保护的核心能力。需要说明的是，扫描结果的完整度取决于编目器覆盖范围，不能把“没扫出来”当作“不存在”。

可以在自己的构建上做的检查

第一，对最终发布产物而不只是源码锁文件生成 SBOM，例如 .app、单文件可执行程序和安装包，并与锁文件生成的清单对比，找出打包过程中带入或遗漏的组件。第二，把 SBOM 与发布版本一起归档，以便漏洞响应时快速定位。第三，检查包内是否附带模型文件，评估这些模型被提取后的影响，必要时把推理放到服务端。第四，确认单文件或应用包中没有附带调试符号、测试配置或内部文档。第五，升级 Syft 后重新扫描一次历史版本，留意新编目器带来的新增结果。

行动清单

• 对最终发布产物生成 SBOM 并与锁文件清单比对
• 每个版本归档 SBOM
• 评估随包模型文件被提取的影响
• 确认发布包中没有调试符号和内部配置