SBOM Requirements in 2026: A Developer's Practical Checklist

The EU CRA vulnerability reporting deadline is September 2026. Here's the checklist your team needs to be ready.

This is the companion checklist to our SBOM and Vulnerability Scanning: What the EU CRA Means for Your Dependencies guide. If you need background on what SBOMs are, what the CRA requires, or why this matters — read the pillar article first. This page is pure action items.

What We'll Cover

• Who needs this checklist
• Phase 1: Vulnerability reporting readiness by Sep 2026
• Phase 2: Full SBOM compliance by Dec 2027
• Tools to get started today
• Common mistakes to avoid

Who Needs This Checklist

You need this checklist if:

• You build software that uses open-source dependencies (npm, PyPI, Maven, Composer, Go modules, Cargo, RubyGems, NuGet — any ecosystem)
• That software is sold, distributed, or made available to users in the EU
• You are the manufacturer, importer, or distributor placing the product on the EU market

If you're unsure whether the CRA applies to your product, see the scope section of our CRA deep dive. The short version: if you sell software to EU customers and it has dependencies, it applies.

Phase 1: Vulnerability Reporting Readiness (by Sep 2026)

Deadline: September 11, 2026 — Manufacturers must report actively exploited vulnerabilities and severe incidents to national authorities within 24 hours.

This phase is about detection and response capability. You need to know when your dependencies are vulnerable and have a process for responding.

Inventory

• Identify all software products with open-source dependencies that reach the EU market
• Locate all dependency lock files (package-lock.json, composer.lock, poetry.lock, go.sum, Cargo.lock, Gemfile.lock, packages.lock.json, pom.xml) across your repositories
• Document which products use which lock files — you need traceability from product to dependency

Vulnerability scanning

• Set up vulnerability scanning on every dependency lock file for every product in scope
• Run scans on every CI build, not just periodically — vulnerabilities are published continuously
• Verify scanning covers all ecosystems your products use (a Python-only scanner misses your npm dependencies)

GeekWala scans lock files across all 8 major ecosystems — npm, PyPI, Maven, Composer, Go, Cargo, RubyGems, and NuGet — with a single tool.

Exploitation intelligence

• Configure alerts for CISA KEV matches — vulnerabilities confirmed actively exploited require immediate attention
• Set thresholds on EPSS scores — EPSS > 0.1 (10% exploitation probability in the next 30 days) warrants priority review
• Monitor for new KEV entries affecting your dependency tree — this is the signal the CRA's vulnerability reporting obligation is designed around

Incident response

• Define an internal process for handling dependency vulnerability reports — who gets notified, who triages, who patches
• Set response time targets — 24 hours for KEV-listed vulnerabilities, 1 week for high EPSS, standard cycle for everything else (see the 3-Signal Triage Method)
• Establish a reporting channel to your EU national authority (each member state designates a Computer Security Incident Response Team)
• Run a tabletop exercise — simulate receiving a KEV alert for a critical dependency and walk through your response process

Documentation

• Write a vulnerability handling policy — this is a CRA requirement, not optional
• Document your scanning tools, frequency, and coverage — market surveillance authorities will ask
• Record your triage criteria — how you decide what gets patched immediately vs. next cycle

Phase 2: Full SBOM Compliance (by Dec 2027)

Deadline: December 11, 2027 — Full CRA requirements apply, including SBOM documentation.

Phase 2 builds on Phase 1. Don't start here — get vulnerability reporting working first.

SBOM format and tooling

• Choose a standard format: SPDX or CycloneDX — either satisfies the CRA's "commonly used, machine-readable" requirement
• Select an SBOM generation tool — Syft (multi-ecosystem) or ecosystem-specific CycloneDX tools. See SBOM Scanning Tools in 2026 for a detailed comparison
• Generate a test SBOM for one product and review it — verify it captures what you expect

CI/CD integration

• Add SBOM generation to your CI/CD pipeline — every build should produce a current SBOM
• Generate a new SBOM for each release — your SBOM must reflect what's actually deployed, not what was deployed six months ago
• Store SBOMs alongside release artifacts — they are part of your technical documentation under the CRA

Dependency coverage

• Include all direct dependencies at minimum (CRA requirement)
• Include transitive dependencies as best practice — lock file-based generation handles this automatically
• Verify SBOM accuracy against actual deployed dependencies — check that your SBOM tool correctly resolves what your package manager resolves
• Automate drift detection — flag when deployed dependencies diverge from the SBOM (e.g., manual hotfixes, container base image updates)

VEX workflow

• Set up a process for issuing VEX statements for vulnerabilities your scanning detects but that are not exploitable in your product
• Document your exploitability assessment criteria — when do you mark something "Not Affected" vs. "Affected"?
• Use EPSS and KEV as inputs to VEX decisions — a "Not Affected" VEX status for a KEV-listed vulnerability requires very strong justification

Ongoing monitoring

• Continuously scan — not just at build time, but against the live vulnerability databases
• Re-assess VEX statements when EPSS scores change significantly or when a vulnerability is added to CISA KEV
• Update SBOMs on every dependency change — not just major releases

Tools to Get Started Today

You don't need to evaluate 50 tools. Here's the minimal effective stack:

SBOM generation:

• Syft — multi-ecosystem, produces SPDX and CycloneDX, works on lock files and container images
• CycloneDX CLI tools — per-ecosystem generators (npm, Python, PHP, etc.)

Vulnerability scanning with exploitation intelligence:

• GeekWala — scans lock files across npm, PyPI, Maven, Composer, Go, Cargo, RubyGems, and NuGet. Every vulnerability match is enriched with EPSS exploitation probability and CISA KEV active exploitation status. Try a scan now →

SBOM storage and lifecycle:

• OWASP Dependency-Track — ingest SBOMs, track vulnerabilities across products, manage VEX statements

Start with scanning (GeekWala) and generation (Syft). Add Dependency-Track when you're managing SBOMs across multiple products.

Common Mistakes

Forgetting transitive dependencies. Your package.json lists 20 packages. Your node_modules contains 800. The CRA requires at minimum top-level dependencies, but vulnerabilities hide deep in the transitive tree. Generate SBOMs from lock files (which capture the full tree), not manifests.

Treating SBOM as a one-time task. An SBOM generated at initial release is stale the next day. Dependencies change, new CVEs are published, EPSS scores shift. Your SBOM and vulnerability scanning must be continuous, not snapshot-based.

Not updating SBOMs on each release. If your SBOM says lodash@4.17.20 but your deployed product upgraded to 4.17.21 three months ago, your documentation is wrong. Automate SBOM generation in CI so every release produces a current SBOM.

Ignoring VEX. Without VEX, every vulnerability your scanner finds is implicitly "Affected." For products with large dependency trees, this creates overwhelming noise. VEX lets you document that specific findings are not exploitable in your product context — reducing alert fatigue and demonstrating due diligence to market surveillance authorities.

---

Start with Phase 1. The September 2026 deadline is six months away.

Scan your dependencies now → — GeekWala covers all 8 major ecosystems with EPSS and CISA KEV enrichment. Know what's vulnerable and what's actively being exploited before you need to report it. No account needed.