2,084 stars · MIT · v4.1.5 (2025-12-15), read from /releases/latest; '15 Dec' has not happened in 2026, so the release is from 2025 · Track this in Scout
Produces a standard parts list of every component inside a software build, with each component's licence.
▶Repo detailsthe review · specs · pros & cons · install
What it does
The tool creates a software bill of materials, which is a standard, machine-readable list of everything inside a build. It writes the SPDX format, in both version 2.2 and version 3.0, with 2.2 as the default. It finds the components by using Microsoft's Component Detection libraries, which read project files such as *.csproj and package.json, and it fills in each component's licence from ClearlyDefined, a public database of open-source licence information. Three commands cover the work: generate writes the list, validate checks an existing one against the files it claims to describe, and redact removes details you do not want to publish. It installs from WinGet, Homebrew, a plain binary, a Docker image or as a .NET tool, and there is a NuGet package for calling it from C#. Three limits are stated outright. It does not accept outside contributions, and tells you to fork instead. Redaction works for SPDX 2.2 only, not 3.0. And it sends nothing to Microsoft: the telemetry it writes is a JSON file in the output folder.
Why it matters
Who it suits. Anyone who sells software to a customer who asks what is inside it, which now includes most public-sector buyers and a growing number of large companies. It also suits anyone who simply wants an accurate inventory once, because a parts list is the thing that turns "is this project affected?" from a day of reading into a search. Skip it if nobody is asking: this records what is there, and does not tell you whether any of it is dangerous. That is entry 6's job.
Verdict. Worth thirty minutes, and almost all of that is reading the command-line arguments. The tool itself is mature and the output is standard. Two things are worth knowing before you adopt it. The first is the release pattern: the newest tagged version, v4.1.5, is from 15 December 2025, while code was committed on 21 September 2026. That is nine months of work with no new tag, which is normal for a tool used mainly inside one company and is worth stating because an old release date looks like neglect and is not. The second is the closed door on contributions. You can read the code and fork it, and you cannot send a fix back. If that is unwelcome, anchore/syft does the same job with an ordinary open development process.
- Writes both SPDX 2.2 and SPDX 3.0, and fills in licence information automatically from a public database.
- Six installation routes, including Homebrew and WinGet, so it fits most working habits without a build step.
- It states clearly that no telemetry is sent anywhere. The telemetry file stays on disk.
- It does not accept outside contributions. A fix you write has to live in a fork.
- The
redactcommand supports SPDX 2.2 only, so a 3.0 list cannot be trimmed before publication. - The full list of supported ecosystems is not in the README. It is deferred to a separate project, which makes "will it see my components?" harder to answer than it should be.
anchore/syftAt 9,700 stars and Apache-2.0, the same parts list for container images and file systems, with an open contribution process and a close pairing with its sibling vulnerability scanner.
Track this in Scout
cdxgen/cdxgenAt 1,100 stars and Apache-2.0, writes the CycloneDX format rather than SPDX and can send the result straight to Dependency-Track.
Track this in Scout
brew install sbom-tool