SBOM and Vulnerability Scanning: What the EU Cyber Resilience Act Means for Your Dependencies

Starting September 2026, the EU Cyber Resilience Act requires vulnerability and incident reporting for software sold in Europe. By December 2027, you'll need a machine-readable Software Bill of Materials for every product. If your software has open-source dependencies — and it does — this directly affects you.

Most developers haven't heard of the CRA yet. Those who have tend to assume it's someone else's problem — a legal team concern, an enterprise compliance checkbox. It's not. The CRA applies to anyone who manufactures or distributes "products with digital elements" in the EU market. That includes SaaS platforms, developer tools, embedded firmware, mobile apps, and anything else that runs software.

The practical requirement comes down to two things: know what's in your software, and know which parts of it are vulnerable. That's where SBOM generation and vulnerability scanning intersect.

What We'll Cover

• What the EU Cyber Resilience Act is and who it applies to
• What an SBOM is and what it contains
• What the CRA actually requires for SBOMs
• CRA compliance timeline and key dates
• Where vulnerability scanning fits in CRA compliance
• What VEX is and why it matters alongside SBOMs
• Practical steps to start preparing today
• SBOM tools landscape and how to choose
• FAQ: Common questions about CRA and SBOMs

What Is the EU Cyber Resilience Act?

The Cyber Resilience Act (CRA) is EU legislation that establishes cybersecurity requirements for "products with digital elements" — essentially any hardware or software product that connects to a network or processes data. The European Parliament adopted the regulation in October 2024. It entered into force in December 2024.

The CRA is the EU's response to a straightforward problem: most software ships without meaningful security guarantees, and consumers and businesses have no way to evaluate the security posture of the products they use. Supply chain attacks like SolarWinds, Log4Shell, and the xz utils backdoor demonstrated that software security is a systemic risk, not just an individual vendor concern.

Who it applies to:

The CRA targets manufacturers — the entity that places a product with digital elements on the EU market. This includes:

• Companies selling software products to EU customers (even if headquartered outside the EU)
• SaaS platforms where the software component is distributed (e.g., client applications, SDKs, plugins)
• Open-source projects that are commercialized by a corporate entity (an individual maintaining FOSS outside commercial activity is outside the regulation's scope, because supplying FOSS that is not monetised is not a "commercial activity" (Recital 18); an "open-source software steward" under Article 24 is a separate, narrower category that is in scope — see below)
• Hardware manufacturers shipping firmware or embedded software
• Importers and distributors who place third-party products on the EU market

The scope is broad. If you sell or distribute software that reaches EU end users, you are almost certainly in scope.

What it doesn't cover:

The CRA excludes free and open-source software developed or supplied outside the course of a commercial activity (Recital 18: FOSS "not monetised by their manufacturers" is not a commercial activity). If you're a volunteer maintainer publishing packages to npm or PyPI without commercial intent, the CRA doesn't apply to you at all — you're not a manufacturer, so there are no obligations to be exempt from.

Foundations are a different case, and the distinction is routinely muddled. An "open-source software steward" under Article 24 — typically a foundation sustaining a FOSS product intended for commercial use — is in scope, with a documented cybersecurity policy and the same actively-exploited-vulnerability reporting duty as a manufacturer from September 11, 2026. Stewards are exempt only from administrative fines under Article 64, not from the obligations themselves. But if a company incorporates your package into their commercial product, that company is responsible for the CRA obligations — including understanding the security posture of every dependency they ship.

What Is an SBOM?

A Software Bill of Materials (SBOM) is a machine-readable inventory of all components in a software product — think of it as a nutrition label for software. Instead of listing calories and ingredients, an SBOM lists package names, versions, suppliers, and relationships.

What an SBOM contains:

• Package identifiers: Names, versions, and package URLs (purl) for every component
• Supplier information: Who created or published each component
• Dependency relationships: Which packages depend on which other packages
• License information: What license governs each component
• Hash values: Cryptographic digests for verifying component integrity

Standard SBOM formats:

Two formats dominate the SBOM landscape:

Both formats express the same core information. The CRA doesn't mandate a specific format — it requires machine-readability and "commonly used" formats. Either SPDX or CycloneDX satisfies this requirement.

Where SBOMs come from:

SBOMs are generated from the same dependency metadata your package manager already tracks. Your package-lock.json, poetry.lock, composer.lock, go.sum, Cargo.lock, Gemfile.lock, or packages.lock.json already contains most of the information an SBOM needs. SBOM generators parse these lock files and produce the standardized output.

CRA SBOM Requirements

The CRA's SBOM requirements are more pragmatic than many developers expect. Here's what the regulation actually says:

Required:

• A machine-readable SBOM identifying at minimum the top-level dependencies of the product
• The SBOM must be part of the product's technical documentation
• The SBOM must be available to market surveillance authorities on request
• Manufacturers must exercise due diligence when integrating third-party components, including open-source

Not required:

• The SBOM does not need to be publicly available (you're not forced to publish your dependency tree)
• The regulation does not mandate a specific format (SPDX and CycloneDX both qualify)
• Full transitive dependency enumeration is not explicitly required (top-level dependencies at minimum), though documenting the full tree is best practice

The practical standard is higher than the legal minimum. While the CRA requires "at minimum" top-level dependencies, market surveillance authorities will expect thorough documentation. An SBOM that only lists 5 top-level packages while your product ships 300 transitive dependencies will invite scrutiny.

The approach that balances compliance and effort: generate SBOMs from your lock files (which already capture the full dependency tree), and let the tools handle the depth. Trying to manually curate a minimal SBOM is more work than generating a complete one automatically.

CRA Compliance Timeline

The CRA has a phased implementation schedule. These dates are fixed — they are not subject to further negotiation or delay:

EU CYBER RESILIENCE ACT — KEY DATES
════════════════════════════════════════════════════════════════

  Dec 2024         Sep 11, 2026          Dec 11, 2027
  ────●──────────────────●───────────────────●──────────────
      │                  │                   │
      │                  │                   │
  Entry into         Vulnerability       Full requirements
  force              & incident           (including SBOM)
                     reporting
                     mandatory

  ┌─────────────────────────────────────────────────────────┐
  │  NON-COMPLIANCE FINES                                   │
  │  Up to EUR 15,000,000 or 2.5% of global annual         │
  │  turnover, whichever is higher                          │
  └─────────────────────────────────────────────────────────┘

Phase 1 — Vulnerability and incident reporting (September 11, 2026):

Starting September 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents to the designated national authorities within 24 hours of becoming aware of active exploitation, with a full report within 72 hours. This means you need a process for detecting when vulnerabilities in your dependencies are being actively exploited — which is exactly what CISA KEV monitoring and EPSS tracking provide. For the full reporting timeline, who it applies to, and a readiness checklist specific to this earlier deadline, see EU CRA Reporting Obligations Start September 11, 2026.

Phase 2 — Full compliance including SBOM (December 11, 2027):

By December 2027, all essential cybersecurity requirements apply. This includes SBOM documentation, secure-by-default configuration, vulnerability handling processes, and ongoing security updates for the product's expected lifetime.

The fine structure is designed to get attention. EUR 15 million or 2.5% of global annual turnover for the most serious violations. Even for essential requirements violations (which include SBOM obligations), fines reach EUR 10 million or 2% of turnover. These are GDPR-level penalties.

Where Vulnerability Scanning Fits

An SBOM answers the question: what's in my software?

Vulnerability scanning answers the follow-up: which of those components have known security issues?

You need both, and you need them in this order. The SBOM gives you the inventory. Vulnerability scanning gives you the risk assessment. Together, they satisfy the CRA's dual requirements of documentation (SBOM) and vulnerability handling (monitoring and response).

The workflow:

Lock files (package-lock.json, composer.lock, etc.)
    │
    ├──→ SBOM Generator (Syft, CycloneDX CLI)
    │        └──→ SBOM document (SPDX or CycloneDX format)
    │
    └──→ Vulnerability Scanner (GeekWala, OSV)
             └──→ CVE matches
                    └──→ Enrichment (EPSS score + CISA KEV status)
                           └──→ Prioritized vulnerability report

Most teams already have vulnerability scanning in some form — npm audit, Dependabot alerts, or a commercial scanner. What many don't have is the connection between their scanning results and the exploitation intelligence that makes those results actionable.

A vulnerability scanner that reports a CVE with a CVSS score tells you severity. A scanner that also reports the EPSS score tells you exploitation likelihood. A scanner that flags CISA KEV status tells you confirmed active exploitation. That three-signal approach — described in our vulnerability prioritization guide — is what turns scanning from noise into signal.

For CRA compliance specifically, this matters because the September 2026 vulnerability reporting obligation requires you to detect when dependencies in your product are actively exploited. You can't report what you can't detect.

What Is VEX?

VEX (Vulnerability Exploitability eXchange) is a companion standard to SBOM that answers the question: is this vulnerability actually exploitable in my product?

An SBOM might show that your product includes lodash@4.17.20, and a vulnerability scanner might flag CVE-2021-23337 (prototype pollution). But if your code never calls the affected function (lodash.template with user-controlled input), the vulnerability exists in your dependency tree but is not exploitable in your specific product.

VEX provides a machine-readable way to document this:

VEX Statement:
  Product: MyApp v2.3
  Vulnerability: CVE-2021-23337 (lodash prototype pollution)
  Status: NOT AFFECTED
  Justification: Vulnerable code path not reachable
  Detail: "MyApp does not use lodash.template or pass
           user-controlled input to any lodash function
           that uses template compilation."

VEX statuses:

How VEX connects to EPSS and KEV:

VEX decisions become more defensible when they're backed by exploitation intelligence. Consider this decision framework:

• EPSS near zero AND not on KEV AND reachability analysis confirms no call path → Strong case for "Not Affected" VEX status. The vulnerability is theoretically present but practically irrelevant.
• EPSS > 0.1 OR on KEV → Even if reachability analysis suggests the code path isn't called, the risk profile is elevated. Investigate more thoroughly before issuing a "Not Affected" status.
• On CISA KEV → Active exploitation confirmed. Unless you can conclusively prove your product's usage is not exploitable, treat this as "Affected" and prioritize remediation.

VEX is not yet required by the CRA in its first compliance phase, but it's the natural complement to SBOM. Once you have an SBOM and vulnerability scanning in place, VEX is how you document the gap between "vulnerabilities present in your dependency tree" and "vulnerabilities that actually affect your product."

Practical Steps for Developers Today

You don't need to wait for the deadlines. Here's what you can do now, ordered by impact:

Step 1: Generate an SBOM from your lock files

Pick a tool (Syft and CycloneDX CLI are both solid choices), point it at your project, and generate your first SBOM. This takes minutes, not days.

# Using Syft (supports all major ecosystems)
syft . -o spdx-json > sbom.spdx.json

# Using CycloneDX CLI for npm
npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json

# Using CycloneDX for Python
cyclonedx-py poetry -o sbom.cdx.json

Don't optimize the output yet. The goal is to see what's in your dependency tree.

Step 2: Integrate SBOM generation into CI

Add SBOM generation to your CI/CD pipeline so every build produces a current SBOM. Store it alongside your build artifacts.

# GitHub Actions example
- name: Generate SBOM
  run: |
    syft . -o spdx-json > sbom.spdx.json
- name: Upload SBOM
  uses: actions/upload-artifact@v4
  with:
    name: sbom
    path: sbom.spdx.json

Step 3: Scan your dependencies for vulnerabilities

An SBOM without vulnerability scanning is an inventory without a risk assessment. Scan your lock files against vulnerability databases.

GeekWala scans the same lock files that SBOM generators consume — package-lock.json, composer.lock, requirements.txt, go.sum, Cargo.lock, Gemfile.lock, packages.lock.json, and pom.xml — across all major ecosystems. Upload your lock file and get vulnerability matches in under a minute.

Step 4: Enrich with EPSS and KEV

Raw CVE matches are noisy. At most about 6% of published CVEs are ever exploited, and stricter datasets put it nearer 1–2%. Enrich your scanning results with EPSS (exploitation probability) and CISA KEV (confirmed exploitation) to focus on what matters.

GeekWala does this automatically — every scan result includes EPSS scores and KEV status so you can prioritize by actual risk rather than theoretical severity.

Step 5: Document non-exploitable vulnerabilities with VEX

For vulnerabilities that your scanning surfaces but that aren't exploitable in your product, create VEX statements. This reduces noise for your team and provides compliance documentation showing you've assessed each finding.

Step 6: Set up ongoing monitoring

Dependencies change. New CVEs are published daily. EPSS scores shift as exploitation patterns evolve. Set up continuous monitoring so you're notified when the risk profile of your dependencies changes — especially when a dependency lands on CISA KEV.

SBOM Tools Landscape

The tooling ecosystem is maturing rapidly. Here's a practical overview:

SBOM generation:

Vulnerability scanning (for SBOM contents):

How GeekWala fits:

GeekWala scans the same lock files that SBOM generators consume. The difference is enrichment: every vulnerability match includes EPSS exploitation probability and CISA KEV active exploitation status, so you can prioritize by real-world risk rather than theoretical CVSS severity. This matters for CRA compliance because the September 2026 vulnerability reporting obligation specifically targets actively exploited vulnerabilities — exactly what KEV monitoring detects.

Storage and management:

For teams managing multiple products, OWASP Dependency-Track provides a platform for ingesting SBOMs, tracking vulnerabilities across products, and managing the lifecycle of vulnerability findings. It pairs well with GeekWala for scanning and enrichment.

For a detailed comparison of all major SBOM scanning tools — including Syft + Grype, Trivy, FOSSA, Anchore Enterprise, and GeekWala — see SBOM Scanning Tools in 2026: Which Ones Actually Help with EU CRA?.

Frequently Asked Questions

Do SBOMs have to be public under the CRA?

No. The CRA requires SBOMs to be part of your technical documentation and available to market surveillance authorities on request. You are not required to publish your SBOM publicly. Many organizations choose to share SBOMs with enterprise customers as part of vendor security questionnaires, but this is a business decision, not a legal requirement.

Does the CRA apply to open-source maintainers?

Not to volunteer-driven, non-commercial open-source development. The CRA reaches products made available "in the course of a commercial activity," and Recital 18 states that supplying FOSS "not monetised by their manufacturers" is not such an activity. If you maintain a package on npm or PyPI as a personal or community project without commercial intent, you are not a "manufacturer" under the CRA. Note this is scope exclusion, not a fines carve-out — and it does not extend to an Article 24 "open-source software steward" (a foundation sustaining a FOSS product intended for commercial use), which is in scope with real reporting duties.

However, if a company uses your open-source package in a commercial product, that company is responsible for CRA compliance — including understanding and documenting the security posture of your package as a dependency.

Open-source foundations (like Apache, Eclipse, Linux Foundation) and companies that commercialize open-source (dual-license models, paid support, hosted versions) may have additional obligations depending on the specifics of their commercial activity.

What format should my SBOM be in?

Either SPDX or CycloneDX. The CRA requires "commonly used and machine-readable" formats. Both SPDX (an ISO standard) and CycloneDX (an OWASP standard) qualify. If you're starting fresh and your primary concern is security (vulnerability tracking, VEX integration), CycloneDX has a slight edge due to its native VEX support. If your concern is license compliance or you're in automotive/industrial domains, SPDX has deeper adoption.

For most development teams, the format matters less than the practice. Pick one and automate it.

What happens if I don't comply?

The CRA establishes three tiers of penalties:

• Essential requirements violations (including SBOM obligations): up to EUR 10 million or 2% of global annual turnover
• Other CRA obligation violations: up to EUR 5 million or 1% of turnover
• Most serious violations (placing non-compliant products on the market): up to EUR 15 million or 2.5% of turnover

Additionally, market surveillance authorities can order products withdrawn from the EU market. For software companies with EU customers, non-compliance means either paying significant fines or losing access to the EU market entirely.

---

Don't wait for the deadlines to discover your dependency risk.

Scan your dependencies now → — GeekWala checks your lock files against vulnerability databases and enriches every finding with EPSS exploitation probability and CISA KEV active exploitation status. Know what's vulnerable and what's actually being exploited. No account needed for your first scan.