What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Full list of package catalogers and supported ecosystems: confirm against current documentation
- Accuracy of catalogers for statically linked and stripped binaries: confirm current capability
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
Syft produces a software bill of materials by cataloging what is present, not by reading a build definition. It takes a container image, a directory, an archive or a registry reference, unpacks the layers, and runs per ecosystem catalogers across the contents. Each cataloger knows the on disk shape of one packaging format: operating system package databases for the common Linux distributions, jar and war metadata, node_modules and lockfiles, Python distribution metadata, Go module information embedded in compiled binaries, Ruby gem specs, Rust and .NET artifacts, and others. The result is an inventory with names, versions, licenses where declared, and the file locations behind each entry.
Working from the artifact rather than the manifest is the important property. What ends up in an image includes base image packages, things a package manager installed during the build, and dependencies pulled in by a step nobody documented, none of which appear in your application's dependency file. Output is emitted in SPDX and CycloneDX, and Syft is the inventory half of a pairing with Grype, which does the vulnerability matching. Syft deliberately does not match against advisories itself.
Where it fits
A build pipeline step that runs after the image is assembled, producing an attestable artifact alongside it. It is also used at analysis time, pointed at an image already in a registry to find out what is in it. The tool is a single binary with no service, no state and no database, easy to run anywhere, which equally means you need somewhere to store and query the documents it emits if you want an estate wide view.
Strengths
- Catalogs the actual contents of an image, including operating system packages and anything installed outside the application manifest.
- Emits standard SBOM formats, so the output is portable rather than locked to one vendor's tooling.
- Extracts module information from compiled Go binaries, which is otherwise hard to recover after build.
- Single static binary, no infrastructure, trivially embedded in CI.
Limitations
- Inventory only. No vulnerability data, no policy, no reporting interface. You need a second tool for anything beyond the list.
- Cataloger accuracy varies by ecosystem. Vendored code, stripped binaries and statically linked C libraries are frequently invisible or reported without a usable version.
- Dependency relationships in the output are coarser than an SBOM produced by the build system itself, so it describes what is present more reliably than how it got there.
Who it suits
Anyone who needs SBOMs from containers without a platform commitment, and teams building their own supply chain tooling who want a dependable inventory component. Teams that want findings, triage workflow and reporting out of the box should choose a platform that includes generation instead.
Used Syft? Recommend it under your own name and title.
Recommend this tool