An SBOM generator that fits almost anywhere
Syft takes a container image, directory, file, or archive and identifies the software packages inside it. The result can be a readable terminal table, Syft's detailed JSON, SPDX, CycloneDX, package URLs, GitHub dependency snapshot JSON, or a custom template. It can write several formats in one run and select explicit schema versions, which helps when different consumers demand different standards.
The tool covers operating-system packages such as APK, Debian, and RPM, plus a long list of language and artifact ecosystems including Go, Python, Java, JavaScript, Ruby, Rust, PHP, .NET, Nix, Swift, and Terraform. Container input can come from Docker, Podman, containerd, a remote registry, OCI layouts, Docker or OCI archives, and Singularity files. That breadth is why Syft works well as the inventory stage shared by many pipelines.
Just keep the product boundary straight. Syft says what it found. It does not decide whether a package is vulnerable, whether a license violates policy, or whether a release should pass. Anchore's Grype consumes the inventory for vulnerability scanning, while another policy system must store, compare, and approve SBOMs. The separation is useful when you already have those pieces; it is extra assembly when you want one security product.
The quick start is honestly quick
Syft is distributed as a single compiled executable with no runtime dependencies. The official installer, Homebrew, Winget, Docker, Scoop, Chocolatey, and Nix provide several entry points. After installation, syft alpine:latest prints detected packages, while adding -o cyclonedx-json or -o spdx-json emits a standard document. No server, database, or account is required for local and public inputs.
Scan the thing you mean to describe
Syft chooses different catalogers by target. An image scan looks for packages positively installed in the image. A directory scan can include installed packages and declared dependencies from files such as requirements.txt. The distinction is sensible: a declaration may contain a version range or a dependency that never reaches production, while a final image provides stronger evidence of what shipped.
For release security, scan the final immutable image or build artifact. A source-directory SBOM is still useful earlier in development, but it answers a different question. Recording the target type, Syft version, and catalogers used makes later comparisons easier. Syft's JSON includes which catalogers were requested and which actually ran, and the CLI can list catalogers before a team overrides defaults.
The automatic selection is broad enough for most users. Custom cataloger rules are valuable when one ecosystem needs special handling, but overriding all defaults can create blind spots. Treat a smaller SBOM after a configuration change as something to investigate, not instant proof that dependencies disappeared.
Detection quality needs local fixtures
No package detector is perfect because real artifacts carry inconsistent evidence. Syft may infer identity from package databases, lockfiles, manifests, binary metadata, filenames, or embedded records. Those sources can be missing, ambiguous, or contradictory. A well-formed output document only proves that serialization succeeded, not that every component was found correctly.
A new issue against version 1.51.0 makes this risk unusually clear. pnpm can write a two-document pnpm-lock.yaml when config dependencies are used. The report shows Syft reading the first document, listing pnpm's own binaries, and omitting the project's dependencies from the second. The result remains nonempty and valid-looking. pnpm teams using this layout should reproduce the scan before adopting this release and keep a known dependency as a CI assertion.
License data needs similar skepticism. An open Java issue shows Syft preferring a JAR's weaker manifest value and not using the parent POM's more precise multi-license information. Another recent release fixed incorrect package URLs for legacy JARs because those identifiers caused downstream Grype false negatives. These reports show an active project fixing difficult evidence problems, but they also rule out treating generated identifiers and licenses as an unreviewed compliance verdict.
The practical safeguard is a small test corpus: one representative image or artifact per important ecosystem, with expected package names, versions, and identifiers. Run it when upgrading Syft. This is far cheaper than manually auditing every SBOM and much safer than trusting output size.
Formats and attestations are strong extras
Format support is a major advantage. Syft can emit CycloneDX JSON or XML, SPDX JSON or tag-value, GitHub dependency snapshots, package URLs, and its own schema. It can also convert supported SBOM inputs between formats, useful when a supplier gives one standard and an internal scanner expects another. Conversion cannot invent missing evidence, so preserve the original.
Syft can create in-toto SBOM attestations for container images using Cosign and Sigstore. The documentation labels this workflow experimental. It requires Cosign, registry write access, and either OIDC or a managed key pair. Signing establishes who produced an SBOM and binds it to an image; it does not prove the catalog itself is complete.
Healthy, fast-moving, and a sensible default
Version 1.51.0 was released on August 10, 2026, the same day as the repository's latest push. Open issues were updated on August 11. GitHub's combined count of 620 includes issues and pull requests, while a separate search showed 499 open issues, a believable queue for a tool tracking many package ecosystems. The latest release added Go FIPS-mode detection and fixed JavaScript, Java, hard-link, and Deno detection problems.
Documentation is one of Syft's best assets. Separate guides explain targets, catalogers, file selection, formats, conversion, configuration, schemas, private registries, and attestations. The project also holds community meetings and offers a Go library for embedding the engine.
Choose Syft when the job is generating a portable, detailed inventory from the artifact you actually ship. It is focused, easy to install, and unusually flexible at the edges. Pair it with a scanner and policy layer, verify it against your own dependency fixtures, and it becomes a dependable foundation rather than a false promise of perfect visibility.