Syft can produce several SBOM formats, but choosing a format does not establish that its dependency graph answers your policy question. For release and security teams, the useful evaluation is whether the inventory contains the packages, identifiers and relationships their downstream tools need.
What Syft provides
The Syft README describes a CLI and Go library for generating SBOMs from container images and filesystems. It lists archives, dozens of package ecosystems, format conversion, CycloneDX, SPDX, Syft JSON and signed attestations using the in-toto specification. These are documented capabilities, not workloads measured in our run. The README pairs Syft with Grype for vulnerability scanning.
Its basic image example uses alpine:latest. For repeatable release evidence, use an immutable image digest and record the Syft version, configuration and output format. The installation example uses curl | sudo sh; review installation scripts and artifacts under your organization's normal release policy. We did not assess the security of that installation route.
What our recorded run establishes
Our stored run is dated October 9, 2026, at commit 546c872c9d942216d9ddc0da4909cb06fcac356c, whose recorded commit date is October 7, 2026. It used a sandbox configured with 3 CPUs, 8 GB of memory and image golang:1.24-bookworm. The install tail says go: downloading go1.26.8 (linux/amd64), so describing the effective toolchain simply as Go 1.24 would be misleading.
The dependency step exited 0 in 61.514 seconds, with 858 dependencies recorded. This is dependency setup, not an installed-binary check. The build step exited 0 in 169.994 seconds, but its tail includes unkeyed-field diagnostics, unreachable code and vet-exit:1. We can report successful completion of the recorded build step, not a clean static-analysis result.
The test command exited 1 in 232.306 seconds and did not time out. The parser recorded 113 successful package results and 33 failed package results, plus 38 packages with no tests. Its total of 146 covers the successful and failed package results. These figures are not counts of individual test cases, and the stored parser summary has not been reconciled against a complete log to verify unique, exhaustive coverage.
The available test tail names failures in Python, Red Hat and Rust catalogers, stereoscope sources and CLI tests, including Test_Unknowns. It does not show a missing-Docker error or establish the causes of all failures. Assigning those failures to Docker would exceed this run's evidence.
The checkout had 2,944 files, approximately 228,540 source lines and 34.3 MB. It included 4 CI workflows, a Dockerfile and a tests directory. No separate installed-binary check, representative scan workload, scan-speed benchmark, accuracy evaluation or security audit is supplied. A failed test command alone does not prove that Syft cannot perform its documented scanning tasks.
Check relationship semantics before relying on a graph
Issue 5173 reports missing language-package dependency edges and differences between CycloneDX and SPDX graphs for the same images. Those are the reporter's observations, not our measurements. An August 25 contributor comment describes encoder-level differences at bf82010f; an October 12 contributor comment asks for clarification of the report. Neither comment establishes the behavior of our measured commit across the reporter's corpus.
The report explicitly describes a data-quality issue for consumers that use declared relationships, rather than a vulnerability. Its practical lesson is to check what an edge means before computing reachability or comparing graph completeness across formats. A containment relationship and a dependency relationship answer different questions.
For an adoption trial, select artifacts with known expected packages and dependency edges. Generate the formats your consumers require, inspect the identifiers and relationships, and document any gaps. We have not performed that trial, so this review cannot certify graph completeness.
Release notes describe fixes, not our test results
The v1.51.0 release notes list fixes involving legacy JAR PURLs, phantom JavaScript packages, hardlink handling in SPDX verification codes and Git for Windows CPE candidates. These are upstream release claims. They explain why inventory identifiers and output details deserve validation, but they do not establish that our later checkout passed those regression tests. v1.51.0 is a release reference here, not the verified version of an installed binary from our run.
Choosing an alternative
Trivy is relevant when the requirement combines SBOM inventory with vulnerability, misconfiguration or secret scanning. Microsoft SBOM Tool is relevant when SPDX 2.2 or SPDX 3.0 generation and separate shipped-file and build-component inputs fit the release workflow. These distinctions come from their primary documentation; we did not run a comparative evaluation.
How to read the scores
Scores are editorial assessments on a five-point scale: 1 means substantial documented obstacles, 2 means limited support in the supplied evidence, 3 means a documented route with material validation still needed, 4 means strong evidence with bounded gaps, and 5 requires broad verification beyond feature lists. They do not measure adoption, compatibility or scan accuracy. Unknowns limit the scores rather than counting as product defects.
Syft's documented scope makes it a candidate for teams that need several SBOM formats or Go integration. The next useful step is a small inventory-validation trial on your own release artifacts, followed by a separate vulnerability-scanning step if that is part of your workflow.