What is an SBOM (software bill of materials)?

What's in an SBOM

The baseline most guidance still uses is the NTIA's minimum elements for an SBOM (opens in a new tab), published in 2021 under Executive Order 14028. Its data fields, for each component:

• Supplier name: who created or maintains the component.
• Component name and version.
• Other unique identifiers, such as a package URL (purl) or CPE.
• Dependency relationship: which component includes which.
• Author of the SBOM data and a timestamp.

Most SBOMs also carry licenses and cryptographic hashes, which help with license compliance and with checking that a component wasn't swapped.

SBOM example

A minimal CycloneDX SBOM for a small Node.js service: one application, two libraries, and the dependency between them.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {
    "timestamp": "2026-11-14T09:00:00Z",
    "component": { "type": "application", "name": "acme-api", "version": "2.3.0" }
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:npm/express@4.21.2",
      "name": "express",
      "version": "4.21.2",
      "purl": "pkg:npm/express@4.21.2",
      "licenses": [{ "license": { "id": "MIT" } }]
    },
    {
      "type": "library",
      "bom-ref": "pkg:npm/body-parser@1.20.3",
      "name": "body-parser",
      "version": "1.20.3",
      "purl": "pkg:npm/body-parser@1.20.3"
    }
  ],
  "dependencies": [
    { "ref": "pkg:npm/express@4.21.2", "dependsOn": ["pkg:npm/body-parser@1.20.3"] }
  ]
}

A real SBOM for the same service lists hundreds of components, because each library pulls in its own. That's the point: nobody can keep that list in their head.

SBOM formats: SPDX vs CycloneDX

Most tools write both, so pick the one your customers or tooling ask for: CycloneDX is common in security tooling, SPDX in license compliance. A third format, SWID tags (ISO/IEC 19770-2), describes installed software and is rarely used for open-source dependencies.

How to generate an SBOM

• npm: npm sbom --sbom-format cyclonedx writes an SBOM for a Node.js project, in CycloneDX or SPDX.
• Syft (Apache-2.0, by Anchore): syft <image or directory> -o cyclonedx-json, or -o spdx-json, for container images and filesystems.
• Trivy (Apache-2.0): trivy image --format cyclonedx <image>, alongside its vulnerability scanning.
• GitHub: export a repository's dependency graph as an SPDX SBOM from the Insights tab or the REST API.

Generate it in CI for every release, keep it next to the artifact it describes, and feed it to a tool that tracks components across projects, such as OWASP Dependency-Track. Software supply chain security tools covers the options.

SBOM vs SCA, and SBOM vs BOM

An SBOM is a list. Software composition analysis (SCA) is what checks that list, or your manifests directly, against vulnerability and license data. Most SCA tools can produce an SBOM, and most SBOM workflows feed one into an SCA tool.

A bill of materials (BOM) in manufacturing lists the parts that make up a product. An SBOM applies the same idea to software, where the parts are packages and libraries.

Who asks for an SBOM

• US government: Executive Order 14028 (2021) directed the NTIA to publish the minimum elements of an SBOM, the baseline most US guidance still points to.
• Medical devices: section 524B of the FD&C Act requires manufacturers of cyber devices to provide an SBOM covering commercial, open-source and off-the-shelf components (FDA (opens in a new tab)).
• The EU: the Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers of products with digital elements to draw up an SBOM covering at least top-level dependencies; its main obligations apply from December 2027.
• Customers: larger buyers increasingly ask for one in security reviews, whatever the law says.

What an SBOM doesn't tell you

• What happened after the build. It's a snapshot. It doesn't change when a package you shipped turns out to be malicious next week.
• What's installed outside a release. Developers' laptops and CI runners install packages that no release SBOM lists, and that's where malicious packages steal credentials first.
• What's exploitable. That takes SCA, VEX statements, or both.
• Your vendors and runtimes. The SaaS you call and the runtime versions in production usually aren't in it.

That's the gap Pharon fills. It keeps a live inventory of each repo's packages, container images, GitHub Actions and runtimes from a local scan, matches it against new incidents within minutes, and alerts the team that owns the repo. /pharon:check-incident then checks a laptop read-only and names the secrets to rotate. An SBOM proves what shipped; a live inventory tells you what's affected right now. Most teams need both. See what software supply chain security covers.