You would never eat something without knowing what is in it. Or at least, you would want the option to check. That little nutrition label on the back of every food product exists because we collectively decided transparency matters when it comes to things we consume. Software is finally catching up.

A Software Bill of Materials, or SBOM, is the ingredient label for software. And if your organization builds, buys, or sells software, this is something you need to understand right now.

What Exactly Is an SBOM?

An SBOM is a machine-readable inventory of every component inside a piece of software. That includes the code your team wrote, every open source library it depends on, every transitive dependency those libraries pull in, version numbers, licenses, and supplier information.

Think of a typical web application. Your team wrote maybe 10,000 lines of code. But the final build might contain 200 open source packages, each with their own dependency trees. An SBOM captures all of it in a structured, standardized format that tools can parse and analyze automatically.

"You cannot secure what you cannot see. An SBOM turns your software from a black box into something you can actually inspect."

Why SBOMs Matter for Supply Chain Security

If you read our earlier post on supply chain attacks, you already know that attackers love to target the components your software depends on rather than attacking you directly. A poisoned npm package, a compromised Python library, a backdoored Docker image. These attacks succeed because most organizations have no idea what is actually running inside their applications.

An SBOM changes that equation. When a new vulnerability drops (like Log4Shell did in late 2021), the first question every security team asks is: "Are we affected?" Without an SBOM, the answer involves days of manual searching, frantic Slack messages, and a lot of guessing. With an SBOM, you query a file and have your answer in seconds.

Here is what an SBOM enables in practice:

The Two Main SBOM Formats

There are two dominant standards for SBOMs, and understanding the difference helps you pick the right one for your situation.

SPDX (Software Package Data Exchange)

Originally developed by the Linux Foundation, SPDX is an ISO/IEC 5962:2021 international standard. It has deep roots in license compliance and is widely used in the open source community. SPDX supports JSON, YAML, XML, RDF, and tag-value formats. If your primary concern is license tracking alongside security, SPDX is a strong choice.

CycloneDX

Created by OWASP, CycloneDX was built from the ground up with security as the primary focus. It supports software, hardware, services, and even machine learning models. CycloneDX uses JSON and XML formats, and it includes native support for vulnerability data, making it popular with security teams. If your main goal is vulnerability management and security analysis, CycloneDX is often the better fit.

The good news is that both formats are well-supported by modern tooling, and conversion between them is possible. You will not get locked in by choosing one over the other.

How to Generate an SBOM with Syft

Syft is an open source CLI tool from Anchore that generates SBOMs from container images, filesystems, and archives. It is one of the easiest ways to get started.

Install Syft

On macOS or Linux, the quickest method is:

curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

Generate an SBOM from a container image

syft scan yourimage:latest -o spdx-json > sbom.spdx.json

Or if you prefer CycloneDX format:

syft scan yourimage:latest -o cyclonedx-json > sbom.cdx.json

Generate an SBOM from a local directory

syft scan dir:/path/to/your/project -o cyclonedx-json > sbom.cdx.json

Syft automatically detects package managers (npm, pip, Maven, Go modules, and many more) and catalogs everything it finds. The output is a structured JSON file listing every component, its version, and its source.

Scanning Your SBOM for Vulnerabilities with Grype

Generating an SBOM is only half the picture. You need to know if any of those components have known vulnerabilities. That is where Grype comes in. Also from Anchore, Grype is a vulnerability scanner that works directly with SBOMs.

Install Grype

curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

Scan your SBOM

grype sbom:./sbom.cdx.json

Grype checks every component in your SBOM against multiple vulnerability databases and outputs a table showing the component name, installed version, vulnerability ID (CVE), severity, and whether a fix is available. You can also set a severity threshold to fail builds automatically:

grype sbom:./sbom.cdx.json --fail-on high

This makes it straightforward to integrate SBOM scanning into your CI/CD pipeline. Generate the SBOM during the build, scan it with Grype, and block deployments that contain high or critical vulnerabilities.

SBOM Disclosure Policy Template

If you are a software vendor, having an SBOM disclosure policy tells your customers how you handle transparency. Here is a simple framework to start with:

  1. Generation. State that an SBOM is generated for every release using a specified tool and format (for example, CycloneDX JSON via Syft).
  2. Availability. Define how customers can request and receive the SBOM. This might be through a customer portal, bundled with the release, or available on request.
  3. Update cadence. Specify that SBOMs are regenerated with every release, patch, or dependency update.
  4. Vulnerability monitoring. Describe your process for continuously scanning SBOMs against new CVEs and notifying affected customers.
  5. Retention. Define how long historical SBOMs are kept (a minimum of three years is a reasonable starting point).

Even if you are not required to publish SBOMs today, having this policy ready shows maturity and builds trust with customers who are increasingly asking these questions.

The Government Mandate: Executive Order 14028

In May 2021, the Biden administration issued Executive Order 14028, "Improving the Nation's Cybersecurity." Among its many directives, it required software vendors selling to the federal government to provide SBOMs. This was not a suggestion. It was a procurement requirement.

Since then, agencies like CISA and NIST have published detailed guidance on minimum SBOM elements, and the requirements have continued to tighten. If your software touches any federal contract, or if you are a subcontractor to someone who does, SBOM compliance is not optional.

Federal Procurement Season and Why Timing Matters

Federal agencies are actively evaluating vendors against these requirements right now. If you sell software to the government and cannot produce an SBOM on request, you are at a competitive disadvantage. The agencies that have budget to spend are prioritizing vendors who can demonstrate supply chain transparency. Getting your SBOM process in place before the next procurement cycle is not just good security practice. It is a business advantage.

Getting Started Today

You do not need a massive budget or a dedicated team to begin. Here is a practical starting point:

  1. Pick one application. Start with your most important or most customer-facing product.
  2. Install Syft and generate your first SBOM. It takes about five minutes.
  3. Scan it with Grype. You will likely be surprised by what shows up.
  4. Remediate the critical and high findings. Update or replace vulnerable components.
  5. Automate it. Add SBOM generation and scanning to your CI/CD pipeline so it happens with every build.
  6. Document your policy. Even a one-page SBOM disclosure policy puts you ahead of most organizations.

Software transparency is heading in the same direction food labeling went decades ago. It will not be optional forever. The organizations that get ahead of this shift will spend less scrambling when the next major vulnerability hits, have an easier time with compliance, and earn more trust from the customers and agencies they serve. The ingredient label is coming for software. The only question is whether you will be ready.