Generating a Software Bill of Materials should not require a PhD in specification formats or a six-figure tool purchase. Anchore's Syft has become the de facto open source standard for SBOM generation, and for good reason. It is fast, accurate, and handles the format complexity so you do not have to.
What Syft Does
Syft catalogs software packages from container images, filesystems, and archives. It identifies packages installed through OS package managers (apt, rpm, apk) and application-level package managers (npm, pip, Maven, Go, Cargo, and more). The output is a structured SBOM document in your choice of formats.
That sounds simple, but the implementation details matter enormously. Detecting packages reliably across dozens of ecosystems, handling version formats, resolving transitive dependencies, and producing valid SBOM documents that downstream tools can actually consume requires serious engineering.
Format Support
Syft outputs to CycloneDX (JSON and XML), SPDX (JSON, tag-value, and RDF), and Syft's own JSON format. This coverage matters because the SBOM ecosystem has not settled on a single standard. Government contracts typically require SPDX. Security tooling tends to prefer CycloneDX. Having both options from the same tool saves you from running multiple generators.
The CycloneDX output includes component metadata, package URLs (purls), and license information. The SPDX output includes file-level analysis when run against filesystems. Both formats validate against their respective specifications, which is not a given with all SBOM generators.
Syft's native JSON format carries the most detail. If you are feeding SBOMs into Grype for vulnerability scanning or into Anchore Enterprise for policy evaluation, the native format preserves information that gets lost in the CycloneDX and SPDX translations.
Language Ecosystem Coverage
This is where Syft shines. The list of supported ecosystems is extensive and growing:
Well-supported: npm (package-lock.json, yarn.lock), Python (requirements.txt, setup.py, egg-info, wheel), Java (Maven pom.xml, JAR manifests, Gradle), Go (go.sum, compiled binaries), Ruby (Gemfile.lock, gemspec), Rust (Cargo.lock), PHP (composer.lock)
Good coverage: .NET (deps.json, packages.config), Dart (pubspec.lock), Swift (Package.resolved), Haskell (stack.yaml.lock), Elixir (mix.lock)
OS packages: Alpine apk, Debian dpkg, Red Hat rpm, with proper version parsing for each
The Go binary analysis deserves special mention. Syft can extract dependency information from compiled Go binaries by reading the embedded build information. This is invaluable for analyzing third-party Go tools where you do not have source code access.
Container Image Analysis
Syft understands container image layer structure. When you scan a Docker image, it analyzes each layer independently, which means it can identify packages that were installed and then removed in a subsequent layer. These "ghost packages" do not appear in the final filesystem but still exist in the image and could theoretically be exploited.
The tool works with Docker images (local and remote registries), OCI images, and Singularity images. It also handles multi-architecture images, scanning the appropriate variant for your platform.
Performance on container images is impressive. A typical application image with a Debian base and Node.js application scans in 5-15 seconds. Large images with hundreds of OS packages take 30-60 seconds. This is fast enough for CI pipeline use without adding meaningful build time.
Accuracy Testing
We tested Syft against a set of known-composition container images and measured precision and recall for package detection.
For OS packages, Syft achieved near-perfect detection rates. Alpine, Debian, and RHEL packages were identified with correct versions and proper package URL formatting in every test case.
Application dependencies were slightly less consistent. Syft caught 95%+ of packages listed in lock files. The misses were edge cases: vendored dependencies without lock files, packages installed through non-standard mechanisms, and deprecated package manager formats.
The false positive rate was low. Syft occasionally misidentified file fragments as packages, but this was rare and typically limited to images with unusual filesystem layouts.
Integration Patterns
The most common integration is in CI/CD pipelines. A typical workflow:
- Build your container image
- Run
syft <image> -o cyclonedx-json > sbom.json - Store the SBOM as a build artifact
- Feed the SBOM to Grype for vulnerability scanning
- Publish the SBOM to a registry or SBOM management platform
Syft also works as a library. You can import it into Go applications and run scans programmatically. This is how Grype and Anchore Enterprise use Syft internally.
For Kubernetes environments, Syft can scan images referenced in pod specifications, generating SBOMs for everything running in your cluster. Combined with a periodic scanning cron job, this gives you a continuously updated inventory of all software in production.
Limitations
Syft does not detect vulnerabilities. It generates the inventory, and you use Grype or another scanner for the vulnerability matching step. This is by design, separating concerns makes each tool more reliable, but it means you need two tools in your pipeline.
The file-level analysis in SPDX mode is thorough but slow. If you need file hashes and detailed SPDX file entries, expect scan times to increase significantly.
Syft's handling of private registries requires configuration. If your images are in ECR, GCR, or a private Harbor instance, you need to ensure authentication is set up before Syft can pull and scan them.
Community and Development
Syft is developed in the open on GitHub. The release cadence is aggressive, with new versions shipping every few weeks. The Anchore team is responsive to issues, and community contributions are welcomed. The project has solid documentation and an active Slack community.
The tool's architecture is extensible. Adding support for a new package manager involves implementing a cataloger interface, and the existing catalogers serve as clear examples. This extensibility has driven much of Syft's ecosystem coverage growth.
How Safeguard.sh Helps
Syft generates excellent SBOMs, but an SBOM sitting in a CI artifact bucket is not doing much for your security posture. Safeguard.sh ingests SBOMs from Syft (and other generators), stores them in a searchable inventory, tracks changes between versions, and continuously monitors for new vulnerabilities against your cataloged components. When a new CVE drops that affects a package in your SBOM, Safeguard.sh alerts you immediately with the specific services and versions affected. It turns static SBOM documents into a living, queryable security asset.