SBOM & OSS Compliance Tools — One Parts List, Two Lenses (US/EU)

Written: 2026-06 / Scope: tools and formats are jurisdiction-neutral; the drivers part is US/EU-focused / last_updated: 2026-06-11 Changelog: 2026-06-11 first published as an international (US/EU) edition

Where this post sits: this is the operations companion to Reading OSS Licenses Before You Use Them. The license post covered "how to read the terms (knowledge)"; this one covers "how to automate compliance and vulnerability management with tools (operations)." It also delivers the supply-chain deep-dive promised in Virtualization & Sandboxes.

A few terms (for newcomers):

• SBOM (Software Bill of Materials): a parts list of everything inside your software — libraries, packages, their versions and licenses. The software counterpart of a manufacturing BOM.
• SCA (Software Composition Analysis): the family of techniques and tools that analyze dependencies for vulnerabilities and licenses.
• Copyleft: the property of licenses (GPL / AGPL) under which, when you distribute derivatives, source-provision and same-license obligations can arise (AGPL extends the trigger to network use). See the licenses post.
• OSV: Google's open-source vulnerability database, aggregating multiple advisory sources.

"A customer asked us for an SBOM — what exactly do we hand over?" Such requests are spreading alongside the institutional drivers covered later (US EO 14028, EU CRA). The punchline: SBOM readiness decomposes into ① generating the parts list and ② inspecting it through two lenses — license and vulnerability — and both can start with free OSS tools. This article ① pins down what an SBOM is and why it is suddenly demanded, ② sorts what you want to automate into the two pillars, ③ lays out ten tools on a role map, ④ lands on realistic setups by team size with a CI recipe, and ⑤ closes with where the demands come from (US/EU drivers). Choose your stack from "what do I want to automate," not from memorized tool names.

What an SBOM is — the era of parts lists for software

An SBOM is a parts list of every component in your software: OSS libraries, packages, versions, and licenses. Just as a bill of materials underpins quality control and recalls in manufacturing, showing "what is inside" in machine-readable form is increasingly demanded in procurement and commercial contracts. The big trigger was US Executive Order 14028 (2021), which centers on federal procurement; in practice the demand also shows up in commercial contracts and M&A due diligence (details in the final section).

Formats have effectively consolidated into two:

• SPDX (Linux Foundation): SPDX◆ 2.3 is the widely implemented version. SPDX 3.0 adds AI and Dataset Profiles (parts lists for AI models and datasets).
• CycloneDX (OWASP): standardized internationally as ECMA-424; the latest spec is 1.7 (ECMA-424 2nd edition). Extensions such as ML-BOM and VEX lead here. Note that tool implementations mostly support up to 1.6 — tooling lags the latest spec.

The practical takeaway is simple: when in doubt, pick a tool that can emit both SPDX 2.3 and CycloneDX 1.6. Whichever format the requester names, you can comply without joining the format debate.

What do you want to automate? — the two pillars

SBOM tool comparisons tend to become feature lists, but what practitioners actually want to automate boils down to two things.

Pillar 1: license compliance. When you ship products containing OSS, you must meet each license's obligations (attribution, notices, source disclosure). What you want automated:

• NOTICE / attribution aggregation: collect the notices that licenses like Apache 2.0 require, across all dependencies, and bundle them with your distribution
• Early copyleft detection: alert the moment a GPL◆ / AGPL◆ library slips into your dependency tree (finding out just before release is expensive)

The legal background — how linking and distribution determine your obligations — is covered in the OSS licenses post. This post is about making machines do the detection and aggregation.

Pillar 2: vulnerability detection. Continuously detect known vulnerabilities (CVEs) in dependencies from CI:

• Scanning the whole tree: lockfiles, container images, and filesystems matched against advisories
• Prioritization: fix what is actually dangerous first (filtering by EPSS scores and the CISA KEV catalog)

Both pillars can consume the same SBOM, so the efficient shape is "generate once, inspect through two lenses." And the key fact: no single free tool does both perfectly — which is why you need the role map.

The role map — ten tools by what they do

Four groups, by role. Pricing is shown as a model, not exact figures (it changes quickly; check each official pricing page when you adopt).

Three notes on reading the map:

1. Generation and inspection are usually split. Syft (generate) + Grype (inspect) come from the same vendor and re-scan generated SBOMs quickly. Trivy is the all-in-one that does both, with the constraint that its CycloneDX output goes up to 1.5 (JSON only, as of this writing).
2. NOTICE aggregation is the weak spot of free OSS. Automatically collecting Apache 2.0 NOTICEs into an attribution report is standard in FOSSA / Black Duck (SaaS); on the free side, ScanCode-toolkit's template output gets close. Syft / Trivy record license info in the SBOM but do not generate NOTICE files.
3. Trivy is the free-side representative for copyleft alerts, auto-classifying GPL-2.0/3.0 / AGPL as Restricted / Forbidden at HIGH / CRITICAL. OSV-Scanner detects violations against an SPDX-ID allowlist.

Realistic setups by size — how far free goes, where paying starts

A three-stage CI starting point (GitHub Actions sketch — verify versions and arguments against the official docs):

# Sketch: generate SBOM → inspect for vulnerabilities + licenses
jobs:
  sbom-and-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # 1. Syft: generate SBOM (SPDX 2.3)
      - uses: anchore/sbom-action@v0
        with: { format: spdx-json, output-file: sbom.spdx.json }
      # 2. Trivy: vulnerabilities + licenses + secrets
      - uses: aquasecurity/trivy-action@master
        with: { scan-type: fs, scanners: "vuln,secret,license", severity: "HIGH,CRITICAL" }
      # 3. OSV-Scanner: lockfiles + license allowlist
      - uses: google/osv-scanner-action@v2
        with:
          scan-args: |-
            --recursive
            --licenses=Apache-2.0,MIT,BSD-3-Clause,ISC
            ./

Paste this checklist to audit your rollout:

[SBOM adoption check]
□ Confirmed the requester's format (SPDX / CycloneDX / unspecified)?
□ SBOM generation wired into CI (auto-generated per build — never hand-made)?
□ Copyleft (GPL / AGPL) detection turned into an alert?
□ Decided how NOTICEs / attribution get aggregated (ScanCode batch or SaaS)?
□ Decided vulnerability gating (HIGH/CRITICAL only; narrowed by EPSS / KEV)?
□ Decided where SBOMs are stored per release (so "which versions are affected?" is answerable later)?
□ For SaaS, checked current pricing and plan terms on the official page before signing?

Where the demands come from — US procurement, EU hard law

• US: Executive Order 14028 (2021) directed stronger software supply-chain security in federal procurement, making SBOM standard vocabulary in government buying. Even without US government customers, the requirement often arrives in practice via large customers' procurement standards (an observation from the field rather than a legal mandate). CISA continues to maintain guidance on SBOM minimum elements (building on NTIA's 2021 work).
• EU: the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) imposes supply-chain due diligence on manufacturers of "products with digital elements" — responsibility for the components you integrate (reporting obligations apply from 2026-09-11; main obligations from 2027-12-11). The CRA is not a blanket "SBOM mandate," but knowing your parts — SBOM-style management — becomes the de facto premise of compliance.
• The common thread: the demand arrives through procurement and contracts before it arrives through law. Being able to answer "yes, we can provide an SBOM" with free OSS tooling is the cheapest insurance this article can offer. For Japan's drivers (METI's SBOM guidance ver 2.0), see the Japanese edition.

Summary

SBOM readiness decomposes into "① generate the parts list, ② inspect it through the license and vulnerability lenses," and a free OSS division of labor — Syft to generate, Trivy / Grype / OSV-Scanner to inspect, ScanCode for license precision — gets you started. As you grow, layer paid pieces only where needed: obligation tracking (FOSSA) and remediation automation (GitHub Code Security). Copy the adoption checklist above and audit your own setup.

Related: Reading OSS Licenses Before You Use Them / Virtualization & Sandboxes / Pre-ship rights checklist

Sources / References

Last verified: 2026-06-11 / Jurisdiction: tools and formats are neutral; the drivers part of this edition is US/EU-focused (Japan is covered in the Japanese edition).

Formats (primary)

• SPDX (Linux Foundation) / SPDX 3.0 AI Profile
• CycloneDX (OWASP) / ECMA-424 (CycloneDX international standard)

Tools (official)

• Syft / Grype (Anchore)
• Trivy (Aqua Security) / license scanner docs / SBOM output docs
• OSV-Scanner (Google) / OSV.dev
• CycloneDX CLI / ScanCode-toolkit
• GitHub Dependency Graph / GitHub security plans
• Snyk plans / FOSSA pricing / Black Duck SCA

Drivers (official)

• EO 14028 — Improving the Nation's Cybersecurity (NIST hub) / Federal Register text
• CISA — SBOM resources
• EU Cyber Resilience Act — overview (European Commission) / Regulation (EU) 2024/2847 (EUR-Lex)

Tool features, supported formats, prices, and plan names change (SaaS pricing can change quarterly). This article is an entry-point overview; verify against the primary sources and current official pricing pages before adopting or signing.

About the author

Over 20 years of electrical and software development at a major electronics manufacturer, starting from control engineering, plus about 10 years of independent development. I write from the fundamentals that "become risks if you don't know them," across hardware and software, corporate and personal — and plan to cover practical AI usage as well. More at About this blog.