Software teams don't lack dependencies — the average modern application pulls in somewhere between 150 and 200 open source components, according to Synopsys's 2024 OSSRA report, and most engineering teams can't name more than a fraction of them from memory. That blind spot is exactly what a Software Bill of Materials (SBOM) is built to close, and since the May 2021 Executive Order 14028 and the NTIA's July 2021 "minimum elements" guidance, generating one has gone from a nice-to-have to a procurement requirement for anyone selling into the U.S. federal supply chain. The good news is that you don't need a budget to start: tools like Syft, Trivy, and the CycloneDX CLI are free, open source, and can produce a usable SBOM in minutes. This guide walks through exactly how to generate one, which tool fits which use case, and where free tooling runs out of road — a point Anchore, the company behind Syft, has built its entire commercial product around.
What is an SBOM and why does it matter now?
An SBOM is a structured, machine-readable inventory of every component, library, and dependency in a piece of software, typically formatted as SPDX or CycloneDX JSON. It matters now because two things happened almost simultaneously: Executive Order 14028 made SBOMs a condition of selling software to U.S. federal agencies, and the December 2021 Log4Shell vulnerability (CVE-2021-44228) proved that most organizations had no fast way to answer "are we affected?" Companies with SBOMs on hand for their applications could grep a JSON file and get an answer in minutes; everyone else spent days or weeks manually auditing build manifests. CISA's 2023 "Types of SBOM Documents" guidance and the SPDX 2.3 spec (now also ISO/IEC 5962:2021) have since standardized what a compliant SBOM needs to contain: component name, version, supplier, unique identifier, dependency relationships, and a timestamp, at minimum.
Which free open source tools can generate an SBOM?
Three tools cover the vast majority of real-world use cases: Syft, Trivy, and the CycloneDX CLI family. Syft, maintained by Anchore and released under Apache 2.0, is the closest thing to a default choice — it scans container images, filesystems, and archives, and as of its 1.x releases supports over 20 language ecosystems including npm, PyPI, Maven, Go modules, and RubyGems. Trivy, maintained by Aqua Security, started as a vulnerability scanner but added native trivy sbom generation in 2022 and is popular because it does scanning and SBOM output in one pass. The CycloneDX project ships ecosystem-specific generators — cyclonedx-gomod for Go, cyclonedx-maven-plugin for Java, @cyclonedx/cyclonedx-npm for Node — for teams that want format-native tooling tied closely to their build system rather than a general-purpose scanner. All three are free, actively maintained, and produce SPDX or CycloneDX output that downstream tools can consume.
How do you generate an SBOM with Syft in under five minutes?
You install Syft with a single shell script and run one command against any image or directory. On macOS or Linux:
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
syft nginx:1.25 -o cyclonedx-json > sbom.json
That second command pulls the nginx:1.25 image, catalogs every OS package and application dependency inside it, and writes a CycloneDX 1.5 JSON file. On a typical container image this takes 10-30 seconds and returns anywhere from 80 to 400+ components depending on the base image. Swap -o cyclonedx-json for -o spdx-json if your compliance requirement specifies SPDX instead — Syft supports both natively, which is part of why it's become a de facto standard embedded inside Docker Desktop, GitHub's anchore/sbom-action, and GitLab's dependency scanning pipeline.
How do you generate an SBOM with Trivy instead?
You run trivy image --format cyclonedx --output sbom.json <image>, and Trivy produces a CycloneDX SBOM while also giving you the option to layer a vulnerability scan on top in the same invocation. For example:
trivy image --format cyclonedx --output sbom.json myapp:latest
trivy sbom sbom.json --severity CRITICAL,HIGH
The second command re-scans the SBOM you just generated against Trivy's vulnerability database, which pulls from NVD, GHSA, and vendor advisories and refreshes roughly every 6 hours. This two-step workflow — generate, then scan — is why teams already using Trivy for container scanning often adopt it for SBOM generation too, rather than adding Syft as a second tool. The tradeoff is ecosystem coverage: Trivy's SBOM generation is strongest for OS packages and slightly behind Syft for some application-language dependency trees, particularly in monorepos with mixed package managers.
What breaks when you rely only on free SBOM tools?
Free tools generate a correct SBOM for a single scan at a single point in time, but they don't track how that SBOM changes across your fleet or over time, which is the actual operational problem for any organization with more than a handful of repositories. Concretely: if you have 50 services each generating a Syft SBOM in CI, you now have 50 JSON files with no shared storage, no diffing between builds, and no automated alerting when a newly disclosed CVE — say, the next Log4Shell — shows up in one of them. Anchore addresses this gap with Anchore Enterprise, layering centralized SBOM storage, policy-as-code, and continuous vulnerability matching on top of the open source Syft/Grype engine. That's a reasonable path if you're already standardized on Anchore's scanning format, but it also means your entire supply chain visibility depends on one vendor's closed platform and pricing tiers, typically licensed per node or per image scanned. Other gaps free tools share regardless of vendor: no VEX (Vulnerability Exploitability eXchange) status tracking to suppress non-exploitable findings, no attestation or signing workflow tied to the SBOM, and no cross-team dashboard showing which of your hundreds of SBOMs actually got regenerated after the last dependency bump.
How do you choose between raw open source tooling and a managed platform?
You choose open source alone if you have fewer than 10-15 services, one team responsible for security, and no compliance mandate requiring continuous SBOM freshness — for that scale, a Syft or Trivy step in CI plus a shared S3 bucket for storage is genuinely sufficient. You need a managed platform once you cross into multiple teams, multiple repos, and any external audit requirement (SOC 2, FedRAMP, or a customer security questionnaire asking "can you produce an SBOM for release X from six months ago"), because that's when the coordination cost of tracking SBOMs by hand exceeds the cost of a platform. A useful gut check: if your last SBOM request from a customer or auditor took more than a day to fulfill because someone had to manually locate, regenerate, or reconcile files, you've already outgrown the free-tooling-only approach, regardless of which generator you started with.
How Safeguard Helps
Safeguard is built for the point where free tooling stops being enough — not to replace Syft or Trivy, but to make their output actually operational across an entire organization. Safeguard ingests SBOMs from any generator (Syft, Trivy, CycloneDX CLI, or your existing CI pipeline) and gives every team a single, continuously updated inventory of components across all repositories and container images, instead of a folder of disconnected JSON files. When a new CVE drops, Safeguard automatically cross-references it against every stored SBOM and tells you within minutes which services, versions, and environments are actually affected — the exact workflow that took most teams days during Log4Shell. Safeguard also layers on VEX-aware triage so you can mark findings as not-exploitable with an audit trail, policy gates that block a release if its SBOM shows a banned or unpatched component, and one-click, always-current SBOM exports formatted for SPDX or CycloneDX when a customer, auditor, or regulator asks for one. Unlike a single-vendor scanning stack, Safeguard is generator-agnostic by design: keep using the free tool your team already trusts to produce the SBOM, and let Safeguard handle everything that happens to it afterward — storage, monitoring, correlation, and compliance reporting — at a scale that spreadsheets and standalone CLI runs can't sustain.