Syft 容器与文件系统 SBOM

要解决的问题

容器镜像是交付的最小单元，但一个生产镜像里往往同时混着多个包管理器的产物：基础镜像里的 .deb/.rpm/.apk，应用层的 package.json、requirements.txt、go.mod、pom.xml。安全扫描、许可证清点、漏洞响应都需要一份完整的组件清单，而手工维护或只解析一层 manifest 的做法很容易漏掉深层依赖，也无法满足 CycloneDX、SPDX 这类标准格式的输出要求。

核心能力

这个技能围绕 syft 这个 CLI 工具展开，主要能力包括：

• 从多种镜像源生成 SBOM：OCI registry、本地 Docker 镜像、docker save 导出的 tar，以及 Singularity 等格式。
• 直接对文件系统目录、挂载点或 tar 归档扫描，适合 CI 产物与离线环境。
• 覆盖数十种包生态：Alpine(apk)、Debian(dpkg)、RPM、Go module、Python、Java/JAR、JavaScript、Ruby、Rust、PHP、.NET 等。
• 输出格式可选 CycloneDX（JSON/XML）与 SPDX，并支持表格形式的人类可读输出。

典型流程是：指定输入源 → 选择 SBOM 标准与输出目标 → 生成清单文件 → 交由下游工具（如 Grype 做漏洞匹配）消费。

适用边界

• SBOM 的准确度取决于包管理器的可识别度；用户自定义安装、编译进二进制的依赖（如 Go vendor 目录里未声明的模块）可能不被覆盖。
• 该技能描述的是 syft 本身的能力，资料中没有体现额外的策略分析或漏洞匹配逻辑。
• 镜像格式支持面很广，但个别冷门格式可能存在字段缺失，建议以官方安装文档为准。
• 本次提供的资料中没有包含具体用法示例，实际行为需参考上游 README。