SBOM Is Mandatory in the EU by September 2026 — Is Your Team Ready for Software Supply Chain Compliance?

General
1

I’m going to be direct: if your company ships software to EU customers and you don’t have an SBOM process in place, you’re already behind. The clock is ticking, and most teams I talk to haven’t even started.

What’s Happening

The EU Cyber Resilience Act (CRA), formally adopted in late 2024, requires that all products with digital elements sold in the EU must include a Software Bill of Materials (SBOM) by September 2026. This isn’t a suggestion. It’s law, with real penalties — up to EUR 15 million or 2.5% of global turnover, whichever is higher.

The CRA also introduces vulnerability reporting obligations: manufacturers must report actively exploited vulnerabilities to ENISA (the EU cybersecurity agency) within 24 hours of becoming aware of exploitation. Not 24 hours after you’ve analyzed it. Not 24 hours after your security team has a meeting. Within 24 hours of awareness.

What an SBOM Actually Is

For those who haven’t been tracking this: a Software Bill of Materials is a comprehensive, machine-readable inventory of every software component in your product. Every library, every dependency, every transitive dependency, and their exact versions. Think of it as a nutritional label for software — it tells you exactly what’s inside.

An SBOM should include:

  • Component name and version for every dependency
  • Supplier information for each component
  • Dependency relationships — what depends on what
  • Licensing information for compliance
  • Known vulnerability identifiers (CVE references)

The two main standards are SPDX (Linux Foundation, ISO standard) and CycloneDX (OWASP). Both are acceptable under the CRA, and both have strong tooling ecosystems.

Most Companies Aren’t Ready

A 2025 survey by the Ponemon Institute found that only 47% of organizations have any SBOM generation capability, and of those, less than half generate SBOMs automatically as part of their CI/CD pipeline. That means roughly 75% of organizations are either doing this manually or not at all.

Manual SBOM tracking is essentially impossible at scale. A moderately complex web application might have 500+ direct and transitive dependencies. A microservices architecture with 50+ services? You’re looking at thousands of components, versions updating weekly, and a dependency graph that changes with every merge to main.

The Tooling Landscape

The good news is that tooling exists and is maturing quickly:

SBOM Generation:

  • Syft (Anchore) — generates SBOMs from container images, file systems, and archives. Supports SPDX and CycloneDX. Open source and fast.
  • cdxgen (CycloneDX generator) — language-aware SBOM generator that understands package managers natively.
  • Trivy (Aqua Security) — originally a vulnerability scanner, now generates SBOMs as well. Good for container-heavy environments.

Vulnerability Scanning:

  • Grype (Anchore) — scans SBOMs for known vulnerabilities. Pairs naturally with Syft.
  • OSV-Scanner (Google) — uses the OSV database for vulnerability matching, good coverage across ecosystems.

Management & Compliance:

  • GUAC (Google) — Graph for Understanding Artifact Composition. Aggregates SBOM data and provides queryable supply chain intelligence.
  • Dependency-Track (OWASP) — SBOM management platform with vulnerability tracking and policy enforcement.

Why Tooling Alone Isn’t Enough

Here’s where most teams make a mistake: they think implementing SBOMs is a tooling problem. It’s not. It’s an organizational process problem.

You need:

  1. Automated generation — SBOMs must be generated on every build, not manually
  2. Storage and versioning — Every release must have a corresponding, versioned SBOM
  3. Continuous scanning — New vulnerabilities are disclosed daily; your SBOM from last week might have new CVEs today
  4. Reporting infrastructure — When you discover an exploited vulnerability, can you identify affected products within hours?
  5. Cross-team adoption — Every team must use the same tooling and processes, consistently

That last point is the killer. In every organization I’ve worked with, getting 100% adoption across all teams is the hardest part. There’s always one team that builds differently, uses a custom package manager, or has legacy services that don’t fit the standard pipeline.

My Warning

If you sell software or SaaS to EU customers, here’s my timeline recommendation:

  • Q1 2026 (now): Start pilot implementation with one service. Choose your SBOM standard and tooling.
  • Q2 2026: Roll out to all actively developed services. Integrate into CI/CD pipelines.
  • Q3 2026 (deadline): Full coverage, vulnerability scanning active, reporting processes tested.

If you haven’t started by the end of this quarter, you’re going to be running a crash program that will cost you significantly more in engineering time and create compliance risk.

This isn’t the kind of thing you can bolt on at the last minute. Start now.

What’s your team’s SBOM readiness? I’d genuinely like to understand where the community stands on this.

2

Sam, thank you for this. I’ve been championing SBOMs internally for two years and I cannot tell you how many times I heard “that’s nice to have, not need to have.” The CRA just changed that calculus overnight. Suddenly, the executive team that couldn’t prioritize SBOM work for eight quarters is asking me for a 90-day implementation plan.

I’m not bitter about it. Okay, maybe a little. But mostly I’m grateful that regulatory pressure is finally giving security teams the leverage we’ve needed.

Our Implementation Journey

Let me share what we’ve built over the past 18 months, because I think it can save other teams time:

Phase 1: Standard Selection (2 weeks)
We went with CycloneDX over SPDX for a few reasons: better tooling ecosystem for our stack (Node.js, Python, Go), more active community development, and the JSON format is easier for our teams to work with programmatically. Both standards are CRA-compliant, so this is mostly a pragmatic choice.

Phase 2: CI/CD Integration (6 weeks)
We integrated Syft into our GitHub Actions pipelines. Every PR that merges to main generates an SBOM artifact. Every production deployment publishes the SBOM to our internal artifact registry alongside the container image. The key insight: SBOM generation must be automatic and non-optional. If it requires a developer to remember to do it, it won’t happen.

Phase 3: Vulnerability Scanning (4 weeks)
Grype runs against every generated SBOM. We set thresholds: critical CVEs block deployment, high CVEs generate alerts, medium and below get tracked in our vulnerability management system. We also run daily re-scans of all production SBOMs against updated vulnerability databases — a CVE disclosed today against a library you deployed last month is still your problem.

Phase 4: Compliance Dashboard (ongoing)
We built a lightweight dashboard using Dependency-Track that shows compliance status across all services. Any service without a current SBOM shows as non-compliant. This visibility was the game-changer for adoption.

The Hardest Part

The tooling was honestly the easy part. The hard part was getting every team to adopt it consistently. We have 30+ microservices owned by 8 different teams. Some use npm, some use pip, some use Cargo. Each ecosystem has quirks in how dependencies are resolved and declared.

What worked: making SBOM generation a required CI check that blocks merges. If your pipeline doesn’t produce a valid SBOM, your code doesn’t ship. Harsh? Yes. Effective? Absolutely. Adoption went from 40% to 100% in three sprints after we made it a deployment gate.

If your team is starting from zero, my advice: don’t try to boil the ocean. Pick one service, one pipeline, prove the process works, then mandate it everywhere.

3

I’ll be honest: the CRA caught us flat-footed, and I suspect we’re not alone.

We’re a mid-stage SaaS company selling to enterprise customers, including several large EU-based organizations. When the CRA was first announced, our legal team’s initial assessment was that it didn’t apply to us because we’re a SaaS provider, not a hardware manufacturer. Turns out that interpretation was wrong. The CRA covers “products with digital elements,” and while pure SaaS has some nuances, if you provide on-premise components, APIs that process customer data, or software that integrates with customer systems, you’re likely in scope.

We wasted six months operating under the wrong assumption. Don’t make the same mistake — if there’s any ambiguity about whether the CRA applies to your product, assume it does and consult legal counsel who specializes in EU digital regulation.

The Reality of a Crash Program

Once we realized we were in scope, I approved what amounts to a crash SBOM implementation program. Here’s what it actually costs:

  • 2 senior engineers dedicated full-time for 6 months — one focused on tooling and pipeline integration, one focused on process design and cross-team rollout
  • Approximately $180K in direct engineering cost (salaries + opportunity cost of pulling them off product work)
  • Tooling costs: Dependency-Track hosting, additional CI/CD compute for SBOM generation, storage for SBOM artifacts — roughly $2K/month
  • Legal and compliance consulting: $40K for EU digital regulation legal review

For a company our size (200+ microservices, ~120 engineers), this is significant but manageable. For smaller companies, the relative burden is higher. For larger enterprises, the coordination cost scales non-linearly.

My Advice: Prioritize by Risk

You can’t do everything at once. Here’s how I’d prioritize:

  1. Start with customer-facing services. These have the highest regulatory exposure and are most likely to be examined in a compliance audit.
  2. Then internal services that process or store customer data. These are covered under the vulnerability reporting requirements even if they’re not directly customer-facing.
  3. Then supporting infrastructure. Important but lower immediate risk.
  4. Legacy services last. If they’re still running but not actively developed, they need SBOMs too, but they can wait until your process is proven.

The other thing I’ll say is this: SBOM readiness is becoming a procurement requirement. Two of our enterprise customers have already started asking for SBOMs as part of vendor security assessments, independent of the CRA. If you’re in B2B software, this is coming from both the regulatory side and the customer side. There’s no scenario where you don’t need this capability.

Sam, your timeline is right. Q1 is for piloting. Q2 is for rolling out. If you’re not in pilot by end of March, you’re going to be uncomfortable by September.

4

Great thread. Sam and Priya covered the application layer well, but I want to raise a question that I think most teams are overlooking: what about everything below the application layer?

SBOMs for your npm packages or Python dependencies are relatively straightforward. The tooling handles it, the dependency manifests are well-structured, and the vulnerability databases have good coverage. But a modern production environment has multiple layers, and the CRA’s scope covers all of them.

The Full Stack SBOM Problem

Think about what’s actually running in production:

  1. Application dependencies — npm, pip, Cargo, Go modules. This is where most SBOM efforts focus. Solved problem with good tooling.

  2. Container base images — What’s in your node:20-slim or python:3.12-bookworm base image? Hundreds of system packages, each with their own version and vulnerability surface. When Debian pushes a security update to libssl, do you know which of your containers are affected?

  3. Infrastructure-as-Code dependencies — Your Terraform modules, Helm charts, Pulumi packages. These define your infrastructure but rarely show up in SBOMs. A vulnerable Terraform provider or a Helm chart that pulls a compromised image is a supply chain risk.

  4. Runtime dependencies — System libraries loaded at runtime that aren’t declared in your package manifest. This is especially common in Python and Node.js environments where native extensions link against system libraries.

  5. Third-party SaaS and API dependencies — You integrate with Stripe, Datadog, Auth0. If their systems are compromised, your product is affected. The CRA’s vulnerability reporting scope arguably extends to components you depend on but don’t control.

What I’m Building

I’ve been working on an automated SBOM pipeline that tries to cover the full stack. Here’s the architecture:

Layer 1: Application SBOMs

  • Syft runs in CI/CD and generates CycloneDX SBOMs for each service
  • Covers npm, pip, Cargo, and Go module dependencies
  • Output stored as build artifacts alongside container images

Layer 2: Container Image SBOMs

  • Syft also scans the final built container image (not just the application layer)
  • This captures OS packages from the base image — the stuff that npm audit will never see
  • We diff the image SBOM against the app SBOM to identify the “infrastructure surface”

Layer 3: Infrastructure SBOMs

  • Custom scripting (honestly, the tooling here is immature) to inventory Terraform provider versions, Helm chart versions, and base image tags
  • Stored in a separate CycloneDX document linked to the deployment environment

Aggregation:

  • All SBOMs feed into Dependency-Track, which gives us a unified view
  • Grype runs daily against all stored SBOMs
  • Alerts route to the team that owns each service

The weak link is Layer 3. There’s no mature standard for infrastructure SBOMs, and the tooling requires significant custom work. But ignoring this layer means you have a blind spot that’s arguably larger than your application dependencies.

Michelle’s point about prioritization is good. But I’d add: when you prioritize, think in layers, not just in services. A complete SBOM for your three most critical services is more valuable than application-only SBOMs for all 200 services.

The September deadline is real. Build for depth, not just breadth.