A Software Bill of Materials (SBOM) is a machine-readable list of everything inside a piece of software: the open-source packages, commercial libraries, and dependencies, their versions, who made them, and how they connect. When a new vulnerability is disclosed, an SBOM tells you in minutes whether you’re exposed.
Key facts
- Policy milestone: U.S. Executive Order 14028 (May 2021) directed new federal guidance on software supply chain security, SBOMs included. NTIA’s SBOM work had started before the order, and it published the first minimum elements on July 12, 2021.
- Current baseline: In July 2026, CISA’s 2026 Minimum Elements for an SBOM replaced the NTIA version and added 10 required fields, including component hashes, licenses, an author signature, and generation context.
- The two formats: SPDX (ISO/IEC 5962:2021) and CycloneDX (ECMA-424).
- What regulators expect: Under the EU Cyber Resilience Act, manufacturers must keep an SBOM that covers at least top-level dependencies. That obligation applies from December 11, 2027.
- What it protects against: Vulnerable or unlicensed components hiding in software you build or buy. It doesn’t cover code that loads into the browser after deployment, such as third-party tags.
How an SBOM Works
An SBOM on its own is just structured data. Its value comes from what you can do with that data once it exists. Most teams work through five steps:
- Generate. A software composition analysis (SCA) tool or build plugin reads your manifests, lock files, source code, or compiled binaries, and records every component it finds.
- Describe. Each component gets the details needed to identify it: name, version, producer, an identifier such as a package URL (purl) or CPE, a hash, its license, and what it depends on. The SBOM also records who generated it, when, with which tool, and at what stage.
- Format. The data is written in SPDX or CycloneDX, so anyone who receives it can read it without building a custom importer.
- Share. Producers send the SBOM to customers, auditors, or regulators. Many also provide a VEX(Vulnerability Exploitability eXchange) statement that says which known vulnerabilities actually affect the product.
- Use and refresh. Security teams check components against vulnerability feeds and license policies. A new SBOM is generated with every build or release.
Types of SBOM
CISA sorts SBOMs into six types based on when in the software lifecycle they’re created. An early SBOM describes what you plan to build. A late one describes what’s actually running (OpenSSF SBOM Catalog).
Design SBOM
Lists the components you plan to use in software that doesn’t exist yet. It’s useful for early risk reviews and for procurement discussions.
Source SBOM
Built from the development environment: the source files plus the dependencies used to build them. Most developers encounter this type first, usually in a CI pipeline.
Build SBOM
Generated during the build that produces the release. It shows what was actually compiled and packaged, not just what the manifest listed.
Analyzed SBOM
Created by inspecting a finished artifact, often with binary analysis and some heuristics. Buyers can produce one without the vendor’s help, which is why it’s sometimes called a “third-party” SBOM.
Deployed SBOM
Describes the software installed on a specific system. It often combines several other SBOMs with configuration data.
Runtime SBOM
Captured by instrumenting a live system, so it can include components that are loaded dynamically or called externally. Runtime SBOMs are usually captured on servers or cloud workloads. OMB M-26-05, for example, advises agencies that adopt SBOM contract terms for cloud platforms to request an SBOM of the runtime production environment. Of the six types, it comes closest to showing what’s really running on your infrastructure, but it doesn’t record which third-party tags each user’s browser loaded.
SBOM Formats: SPDX vs CycloneDX
In practice, you’ll see two formats. Both are open standards, and CISA’s 2026 baseline accepts either one (FOSSA summary).
| SPDX | CycloneDX | |
| Steward | Linux Foundation | OWASP and Ecma International |
| Formal standard | ISO/IEC 5962:2021 (standardizes SPDX 2.2.1; the current line is SPDX 3.x, released April 2024) | ECMA-424 (2nd edition, December 2025, CycloneDX v1.7) |
| Origin focus | License compliance and package data exchange | Application security and supply chain risk |
| Scope beyond software | Files, snippets, licenses and relationships. SPDX 3.0 added Security (vulnerabilities and VEX), Build, AI, and Dataset profiles. | Services, vulnerabilities, cryptographic assets, ML models, attestations |
SBOM vs SCA vs Client-Side Runtime Inventory
An SBOM is a document. SCA is the tooling that usually produces and reads it. A client-side runtime inventory is different from both: it records the scripts that actually execute in each user’s browser session.
| SBOM | Software composition analysis (SCA) | Client-side runtime inventory | |
| What it is | A standardized inventory document | A tool category that scans code for components, vulnerabilities and licenses | A live record of first-, third- and fourth-party scripts running in browser sessions |
| Question it answers | What is in this software? | Which components are risky? | What is executing right now, and what is it doing? |
| When it applies | Any stage from design to runtime; most are produced at build or release | Mainly during development and CI | In production, during each user’s browser session |
| Output | SPDX or CycloneDX file | Findings, alerts, generated SBOMs | Continuous inventory, behavior and data access mapping |
| Covers third-party tags loaded at runtime | Rarely. Even runtime SBOMs are usually captured server-side | No | Yes |
| Can stop malicious behavior | No | Can block malicious packages pre-release only; nothing at runtime | Yes, when paired with runtime enforcement |
SBOM and SCA tell you what you shipped, and a runtime SBOM can tell you what runs on your servers. None of them can tell you what a vendor’s tag did in a customer’s browser on your checkout page this morning. Client-side runtime controls handle that.
Why SBOMs Matter
Very little software is written from scratch anymore. Open-source packages, commercial libraries and SDKs make up much of what teams ship, and each one comes with its own vulnerabilities and license terms. When Log4Shell was disclosed in December 2021, security teams first had to work out where they were running Log4j. Teams with SBOMs could answer quickly; the rest had to check system by system.
Faster answers are the main benefit, but SBOMs help in other ways too:
- Vulnerability response. You check new advisories against a known list of components instead of guessing.
- License compliance. You can identify open-source obligations before they become legal problems.
- Supplier transparency. Buyers can see what’s inside the software they purchase instead of relying on a vendor questionnaire.
- Regulatory evidence. SBOMs are increasingly showing up in regulations and contracts:
- United States: Since OMB Memorandum M-26-05 (January 2026), each federal agency sets its own software assurance policy, and agencies may add contract terms requiring producers to provide a current SBOM on request. CISA’s 2026 Minimum Elements describes what a good SBOM contains. It is guidance, not a procurement rule.
- European Union: The Cyber Resilience Act (Annex I, Part II) requires products with digital elements to have an SBOM in a commonly used, machine-readable format as part of their technical documentation, from December 11, 2027.
- PCI DSS v4.0.1: Requirement 6.3.2 requires an inventory of bespoke and custom software and the third-party software components built into it to support vulnerability and patch management. It has been mandatory since April 1, 2025.
- OWASP Top 10 2025: Supply chain risk expanded and is now ranked third, as A03:2025 Software Supply Chain Failures.
Where SBOMs Stop: The Client-Side Blind Spot
Most SBOMs describe software at build or release time. Runtime SBOMs go further, but they’re usually captured on servers and cloud workloads, not in your users’ browsers. That leaves out much of what runs on a website. Tag managers, analytics, advertising tags, chat widgets, payment SDKs and AI-powered scripts load directly from vendor servers into each user’s browser. A vendor can change that code whenever it likes, and its script can load fourth-party code of its own.
None of that code goes through your build pipeline or runs on your servers, so it rarely appears in any SBOM. Your inventory describes one set of code while the browser runs another. Web skimming, formjacking and Magecart-style attacks exploit exactly that gap.
SBOM Best Practices
- Generate SBOMs in CI/CD. Produce one with every build or release, as CISA’s 2026 guidance expects, rather than once for an audit.
- Cover every dependency. CISA’s 2026 baseline expects full coverage, transitive dependencies included, with no minimum depth at which you can stop. You can link to SBOMs for subcomponents, as long as recipients can access them.
- Use SPDX or CycloneDX. Your customers’ tools can already read both.
- Include hashes, licenses, and generation context. These fields are new in the 2026 baseline. They let recipients verify each component and see how you produced the SBOM.
- Be clear about gaps. Mark information you couldn’t determine differently from information you chose to redact, and tell recipients how to ask about it.
- Sign your SBOMs. An author signature lets recipients confirm the file wasn’t changed in transit.
- Include VEX. It tells customers which listed vulnerabilities are actually exploitable, reducing triage work.
- Ask suppliers for SBOMs. Then use them in your third-party risk management process instead of just filing them.
- Cover the runtime too. Keep a continuous inventory of the first-, third-, and fourth-party scripts running in the browser, and control what data they can access and where they can send it.
Solutions by Jscrambler
An SBOM covers the code you build. Jscrambler covers what actually executes. The Jscrambler Client-Side Security Platform extends supply chain controls into the browser runtime, where third-party code arrives after the build and usually isn’t in the SBOM.
- Software Supply Chain Security: Covers the blind spot after deployment. It maintains a continuous client-side runtime inventory of third- and fourth-party scripts, detects behavioral drift, enforces least-privilege data access, and controls where data can be sent.
- Jscrambler Webpage Integrity: Discovers third- and fourth-party scripts as they appear and shows which ones access payment, login, and form data. During live sessions, it enforces data access and network exfiltration controls.
- Jscrambler Code Integrity: Protects the first-party application logic your SBOM describes from tampering and reverse engineering once it reaches the browser.
FAQs
What does SBOM stand for?
Software Bill of Materials. The term comes from manufacturing, where a bill of materials lists every part that goes into a product.
What information does an SBOM contain?
Under CISA’s 2026 Minimum Elements, an SBOM holds two kinds of data. Component data describes each component: producer, name, version, identifiers, hash, hash algorithm, license, and dependencies. SBOM metadata describes the document itself: author, author signature, timestamp, tool name and version, data format name and version, SBOM version, and generation context.
Is an SBOM legally required?
U.S. federal agencies may require suppliers to provide an SBOM on request, under the risk-based approach set by OMB M-26-05 (January 2026). In the EU, the Cyber Resilience Act requires an SBOM for products with digital elements from December 11, 2027. Even when no law applies, many enterprise buyers now request one during procurement.
How often should an SBOM be updated?
With every build or release. Once the code changes, an old SBOM no longer describes what’s in production.
Does an SBOM cover JavaScript running in the browser?
Partly. It covers first-party JavaScript and npm packages bundled at build time. It usually doesn’t cover third-party tags that load from a vendor’s server at runtime, or the fourth-party scripts those tags load. For those, you need a continuous client-side inventory and runtime controls.
What is the difference between an SBOM and VEX?
An SBOM tells you what’s in the product. A VEX (Vulnerability Exploitability eXchange) document tells you whether a known vulnerability in one of those components actually affects it.