SBOM Compliance: What to Check and Why It Matters for CRA, NIS2, and SOC2

A Software Bill of Materials (SBOM) is a structured inventory of every component in a software product: open-source libraries, commercial dependencies, build tools, and the relationships between them. Until recently, generating one was a best practice. By 2027, it will be a legal requirement for most software sold in Europe and a practical prerequisite for selling to the US federal government.

Why now?

The momentum behind SBOM mandates comes from a simple hard lesson: you cannot secure what you cannot see. When Log4Shell hit in 2021, organizations had no way to know which products contained Log4j. When the axios supply chain attack landed in March 2026, most organizations had no immediate way to know whether their builds were affected. (Full debrief: The Axios Supply Chain Attack Explained.)

Regulators noticed. If software makers maintain an accurate inventory of what they ship, the time-to-know when a CVE drops goes from weeks to hours.

The regulatory landscape

EU Cyber Resilience Act (CRA)

Full compliance required by December 11, 2027. The CRA explicitly mandates SBOMs: Article 13 requires manufacturers to draw up technical documentation that includes an SBOM for any product with digital elements.

• Format: Machine-readable, SPDX or CycloneDX
• Minimum content: Top-level dependencies at minimum; transitive depth strongly recommended
• Availability: Not required to be public, but available to market surveillance authorities on request
• Retention: 10 years after a product's last sale
• Penalties: Up to €15 million or 2.5% of global annual turnover

NIS2 Directive

NIS2 does not name SBOMs explicitly, but Article 21(2)(d) mandates supply chain security measures. The EU Commission's Implementing Regulation 2024/2690 goes further for specific sectors — requiring "information describing the hardware and software components used in ICT services" — an SBOM by another name.

If you sell software to a NIS2-covered entity, they may ask you for an SBOM as part of their own supply chain risk compliance. This is already happening in contract negotiations. Reporting obligations begin September 2026.

SOC2

SOC2 does not require SBOMs. What it requires is asset management (CC6.1), change management (CC7.1), and vendor risk controls — and auditors increasingly accept a well-maintained SBOM as evidence for all three. Organizations that can point to an SBOM during a SOC2 review answer the vendor risk and change management questions in one shot.

US EO 14028

For software sold to the US federal government, vendors must provide an SBOM in SPDX, CycloneDX, or SWID format plus a signed self-attestation of compliance with NIST SSDF (SP 800-218). If federal contracts are part of your business, an SBOM is non-negotiable.

What a compliant SBOM contains

Field	Description
Supplier name	Who made the component
Component name	Library or package name
Version	Exact version string
Unique identifier	PURL or CPE
Dependency relationships	What depends on what
SBOM author	Who generated the SBOM
Timestamp	When the SBOM was generated

Format choice: CycloneDX is the better choice for most teams — richer vulnerability metadata, integrates with VEX documents, supported by OWASP Dep-Scan and most modern toolchains. SPDX is the ISO standard and required for US government contracts.

SBOM quality matters

Generating an SBOM is the easy part. Making it accurate is harder.

Missing transitive dependencies is the most common failure. An SBOM that only lists direct dependencies misses the packages those packages depend on — where most CVEs actually live.

Stale SBOMs. An SBOM generated once at release goes stale immediately. A new CVE in a dependency requires the SBOM to be current. Treat generation as a CI/CD step on every build, not a one-time compliance checkbox.

Tools like sbomqs score your SBOM against NTIA minimum elements and CRA-relevant fields. A score below 5/10 typically means gaps that will fail a formal audit.

Building it into your workflow

1. Generate automatically on every build. OWASP Dep-Scan supports npm, pip, Maven, Gradle, Go modules, Cargo, and NuGet in a single pass and outputs CycloneDX JSON natively.
2. Store and version alongside the artifact. The SBOM for version 1.4.2 should be retrievable alongside the build artifact for 1.4.2.
3. Monitor against vulnerability databases continuously. Feed your SBOM into a tool monitoring OSV, NVD, and CISA KEV. New CVEs are disclosed daily; a weekly scan is not continuous monitoring.

Adding CISA KEV and EPSS data turns "340 open CVEs" into an ordered list where the top 5 need attention this week. CISA KEV confirms active exploitation in the wild; EPSS gives a 30-day exploitation probability. Neither is in a basic SBOM — they have to be pulled from live feeds.

One SBOM, multiple frameworks

Framework	What the SBOM satisfies
CRA	Article 13 technical documentation requirement
NIS2	Article 21 supply chain security evidence
SOC2	CC6, CC7 asset and change management evidence
EO 14028	Federal procurement SBOM deliverable
Customer audits	Vendor risk questionnaire evidence

Building one SBOM pipeline and maintaining it well is cheaper than satisfying each framework separately — and gives you the visibility to respond quickly when the next supply chain incident lands.

---

Lumstep generates a CycloneDX SBOM on every scan and scores it using sbomqs. Scores, quality grades, and per-component vulnerability data (including CISA KEV flags and EPSS scores) are available in the dashboard per repository and per commit.