SBOM Scanning Tools in 2026: Which Ones Actually Help with EU CRA?

The EU Cyber Resilience Act's first major deadline is September 11, 2026. From that date, manufacturers of products with digital elements sold in the EU must report actively exploited vulnerabilities to ENISA within 24 hours of discovery.

Twenty-four hours. That's not enough time to inventory your dependencies for the first time.

The December 2027 deadline — full SBOM generation and documentation — gets more attention because it's further away. But the September 2026 requirement is the harder one in practice: you can't report a vulnerability within 24 hours if you don't know what's in your software. That requires an SBOM and automated vulnerability tracking already running before the deadline. For the exact reporting timeline and who's on the hook, see EU CRA Reporting Obligations Start September 11, 2026.

This article compares the five SBOM scanning tools you're most likely to evaluate in 2026: Syft + Grype, Trivy, FOSSA, Anchore Enterprise, and GeekWala. We cover what each tool actually does, where it fits in the CRA compliance workflow, and honest guidance on which use cases each one serves.

Why SBOM Scanning Matters Right Now

Most developers know the term "SBOM" — Software Bill of Materials — but haven't had a reason to implement one. The EU CRA changes that.

Here's the compliance timeline:

The September 2026 deadline is the one that should concern you now. "Actively exploited" means vulnerabilities appearing in the CISA Known Exploited Vulnerabilities catalog or otherwise confirmed as being weaponized. You can't report these within 24 hours without:

1. Knowing what dependencies are in your software (SBOM)
2. Continuously monitoring those dependencies against exploitation signals (KEV catalog)
3. Having a reporting workflow already in place

The December 2027 SBOM deadline is more widely discussed because it's explicit about format requirements (SPDX or CycloneDX). But the September 2026 monitoring requirement means you effectively need an SBOM and vulnerability tracking pipeline six months earlier.

Who this applies to: Any manufacturer of "products with digital elements" sold in the EU — SaaS platforms, commercial software, developer tools, embedded systems, mobile apps. A project developed or supplied outside any commercial activity has no obligations at all — it is outside the regulation's scope because supplying unmonetised FOSS is not a "commercial activity" (Recital 18), not merely lightly regulated. If your software generates revenue from EU customers, the CRA applies.

For the full compliance timeline and obligations breakdown, see SBOM and Vulnerability Scanning: What the EU CRA Means for Your Dependencies.

What to Look for in an SBOM Scanning Tool

Before comparing tools, here's what the EU CRA compliance workflow actually requires from tooling:

SBOM generation. Produces a machine-readable inventory of your software components in SPDX or CycloneDX format. Not all "SBOM tools" generate SBOMs — some only scan existing ones.

Vulnerability scanning against the SBOM. Matches SBOM components against vulnerability databases (NVD, OSV, vendor advisories) to identify affected packages.

EPSS and KEV integration. For the 24-hour reporting requirement, you need to know when a vulnerability becomes actively exploited. KEV flags from CISA tell you this directly. EPSS scores give you early warning on exploitation probability before a CVE is officially KEV-listed.

VEX output. Vulnerability Exploitability eXchange documents let you assert that a CVE doesn't actually affect your product in its deployed configuration — for example, a vulnerable function is present but never called. For EU CRA, VEX helps narrow which findings actually require reporting. See What is VEX and Why it Matters for context.

Reporting and audit trails. For compliance, you need evidence: when was the vulnerability discovered, when was it reported, what remediation action was taken. Spreadsheets don't scale.

Container vs. application dependency scope. Some tools focus on OS-level packages inside containers. Others focus on application-level dependencies (npm, PyPI, Maven, etc.). The CRA applies to both, but your specific risk surface determines which matters more.

Tool 1: Syft + Grype

What it is: Syft (by Anchore) generates SBOMs. Grype (by Anchore) scans SBOMs and container images for vulnerabilities. They're separate tools designed to work together.

SBOM generation: Syft generates SBOMs in CycloneDX 1.4/1.5 and SPDX 2.3 formats from container images, filesystems, and source trees. Output formats include JSON, XML, and tag-value. For CRA purposes, syft packages your-container -o cyclonedx-json > sbom.json produces a compliant artifact.

Vulnerability scanning: Grype scans the Syft-generated SBOM against NVD, GHSA, OSV, and vendor-specific databases. As of recent releases, Grype enriches findings with EPSS exploitation probability and CISA KEV active exploitation flags — both directly relevant to the September 2026 reporting requirement.

EPSS + KEV support: Yes, native in current Grype versions. JSON output includes epss and cisa-kev fields. This makes Grype one of the stronger free options for the KEV-monitoring requirement.

VEX output: Limited natively. Grype and Syft have some VEX-adjacent capabilities, but full VEX workflows generally require Anchore Enterprise or integration with a dedicated VEX tool.

Container support: Strong. Syft excels at scanning container images and OCI artifacts. Application dependency scanning (lock files) is also supported but container scanning is the primary use case.

Pricing: Free and open source (Apache 2.0). Anchore Enterprise adds policy engines, VEX management, reporting dashboards, and RBAC — at enterprise pricing.

Best for: DevOps and platform engineering teams that need CLI-based SBOM generation and vulnerability scanning in CI/CD pipelines. Excellent starting point for CRA tooling if you're comfortable with JSON output and don't need a managed dashboard.

Limitations: CLI-only (no dashboard). VEX management requires additional tooling. CRA reporting workflows need to be built around the JSON output. No scheduled monitoring — you run it when you invoke it.

Tool 2: Trivy

What it is: Trivy (by Aqua Security) is an all-in-one security scanner for containers, filesystems, Kubernetes, IaC, and application dependencies. It generates SBOMs and scans them for vulnerabilities.

SBOM generation: Trivy generates SBOMs in CycloneDX and SPDX formats: trivy image --format cyclonedx -o sbom.json your-app. It can also scan existing SBOMs from other tools.

Vulnerability scanning: Trivy queries multiple advisory sources — NVD, OS vendor databases (Alpine, Debian, Red Hat, Ubuntu), GHSA, and others. Advisory source coverage is broad, especially for OS-level packages.

EPSS + KEV support: Trivy does not natively include EPSS scores or CISA KEV flags as of early 2026. This is a meaningful gap for the September 2026 reporting requirement — you'd need to post-process Trivy output to enrich it with KEV data separately.

Container and IaC scope: Trivy's strength is breadth — it scans Docker images (OS packages + app dependencies inside containers), Kubernetes manifests, Terraform, CloudFormation, Dockerfiles, and Helm charts. For teams with containerized infrastructure, this consolidation has significant operational value.

Pricing: Free and open source (Apache 2.0). Aqua Security offers Trivy Premium with a managed dashboard and policy engine — similar dynamic to Anchore Enterprise vs. Grype.

Best for: Teams that need one scanner for both infrastructure (containers, Kubernetes, IaC) and application dependencies. If your threat model is primarily containerized workloads, Trivy consolidates what might otherwise require 3-4 separate tools.

Limitations: No native EPSS or KEV enrichment — a significant gap for the CRA's 24-hour exploitation reporting requirement. CLI-only (no free dashboard). Noisier for application-only scanning (lots of container findings mixed in with app dependency findings). For detailed comparison, see GeekWala vs Trivy.

Tool 3: FOSSA

What it is: FOSSA is an enterprise SCA (Software Composition Analysis) platform focused on open-source license compliance and vulnerability management. It's a paid, cloud-based SaaS product.

SBOM generation: FOSSA generates SBOMs in SPDX and CycloneDX formats as part of its dependency analysis. SBOM export is available in the enterprise tier.

Vulnerability scanning: FOSSA pulls from multiple advisory databases and adds its own proprietary research. It includes reachability analysis for some ecosystems — detecting whether vulnerable code paths are actually reachable in your codebase, which reduces false positives.

EPSS + KEV support: FOSSA integrates EPSS scores and CISA KEV data into its vulnerability prioritization engine. Its risk scoring model combines CVSS, EPSS, reachability, and license risk into a unified view.

Compliance reporting: This is FOSSA's primary differentiator. It generates compliance reports for SBOM policies, license restrictions, and vulnerability disclosure — structured specifically for compliance workflows including NIST SSDF, SLSA, and EU CRA documentation requirements.

VEX support: FOSSA supports VEX document generation and management, allowing you to document suppressed findings with justification for audit trails.

Pricing: Paid only — contact FOSSA for enterprise pricing. No free tier. Per-developer seat pricing model.

Best for: Organizations with formal compliance programs, legal teams reviewing license obligations, and security engineering teams that need audit-ready reporting. The reporting capabilities are specifically designed for compliance workflows that open-source tools require you to build yourself.

Limitations: Cost is significant — not appropriate for small teams or individual developers. Overkill if you need basic vulnerability scanning and don't have formal compliance reporting requirements.

Tool 4: Anchore Enterprise

What it is: The commercial product built on top of the open-source Grype/Syft tools, with added policy management, VEX workflows, reporting dashboards, RBAC, and CI/CD integrations.

SBOM generation: Full Syft capabilities plus enterprise features: SBOM policy enforcement, SBOM comparison across builds, SBOM signing and attestation.

Vulnerability scanning: Grype's vulnerability matching engine with enterprise additions: policy-as-code for defining acceptable risk thresholds, automated VEX generation based on reachability analysis, and compliance-ready reporting.

EPSS + KEV support: Yes, inherited from Grype — with enterprise UI for filtering and reporting on KEV findings specifically. The policy engine can auto-escalate any CVE appearing in the CISA KEV catalog, which directly supports the 24-hour reporting workflow.

VEX support: Anchore Enterprise has strong VEX management — generate, review, and store VEX documents with full audit trails. This is one of the few tools that handles the full VEX lifecycle for compliance purposes.

Compliance reporting: Purpose-built CRA compliance reporting, audit logs, and integration with ticketing systems for remediation tracking.

Pricing: Enterprise — contact Anchore for pricing. Significantly more expensive than open-source alternatives but includes managed infrastructure, SLAs, and professional services.

Best for: Large enterprises with regulated industries (financial services, healthcare, defense contractors) that need the compliance depth of the open-source tools plus a managed policy and reporting layer. The best open-source-to-enterprise upgrade path if your team is already using Syft/Grype.

Limitations: Enterprise pricing is a barrier for SMBs. The open-source Syft + Grype stack covers most of the technical functionality if you're willing to build the reporting layer yourself.

Tool 5: GeekWala

What it is: GeekWala is a web-based dependency vulnerability scanner with EPSS and CISA KEV enrichment across 8 application dependency ecosystems. It focuses on application-level packages — npm, PyPI, Maven, NuGet, Go modules, crates.io, Packagist, and RubyGems.

SBOM generation: GeekWala does not generate SBOMs. It scans dependency manifests (lock files and package definitions) and reports vulnerabilities with exploitation context. If you need to produce CycloneDX or SPDX artifacts for CRA documentation, you'll need Syft, Trivy, or a dedicated SBOM generator alongside GeekWala.

Vulnerability scanning: GeekWala queries OSV, NVD, and GHSA, and crosses every finding against the CISA KEV catalog. EPSS scores are surfaced for every CVE. The result: a prioritized list that distinguishes between "high severity on paper" and "actively exploited right now."

EPSS + KEV support: Yes, core functionality. Every scan shows EPSS scores and KEV flags alongside CVSS. You can filter to KEV-flagged findings only — which is exactly what you need to identify the vulnerabilities requiring 24-hour CRA reporting.

Web dashboard and team access: Unlike the CLI tools above, GeekWala provides a web dashboard where team leads, security champions, and stakeholders can see vulnerability posture without a terminal. Scan history, project trending, and cross-project views are available through the UI.

Scheduled monitoring: Pro accounts get daily and weekly scheduled scans. This means you're automatically alerted when a new CVE matches your dependencies and when EPSS scores spike — rather than discovering it only on the next commit.

Pricing: Free tier (5 projects, 200 packages, 50 scans/month) and a paid Pro tier. See pricing page for current pricing and limits.

Best for: Development teams that need application dependency scanning with exploitation-signal context and team visibility. Strongest value for teams managing multi-language projects where unified EPSS + KEV context across npm, PyPI, Maven, etc. matters. A natural complement to SBOM-focused tools (Syft/Grype, Trivy) that handle the SBOM generation side of CRA.

Limitations: Not a full SBOM scanner — doesn't scan container images or generate SBOM artifacts. Doesn't cover OS-level packages inside containers. For complete CRA compliance, pair GeekWala (application dependency monitoring) with Syft/Grype or Trivy (SBOM generation and container scanning).

Which Tool for Which Use Case

The decision isn't "pick one tool" — it's "which combination covers your compliance surface?"

Small teams and startups

Start with Syft + Grype or Trivy. Both are free, generate CRA-compliant SBOMs, and Grype now includes KEV enrichment. Add GeekWala's free tier for web visibility and multi-ecosystem application dependency monitoring.

Mid-market teams

Syft + Grype in CI, GeekWala Pro for application dependency monitoring and team dashboards. This combination covers SBOM generation, container scanning, and application dependency tracking with exploitation signals — at low cost. Build a simple reporting workflow around Grype's JSON output for CRA documentation.

Enterprise with formal compliance requirements

Anchore Enterprise or FOSSA. The policy engines, VEX management, audit trails, and CRA-specific reporting capabilities justify the cost if you have formal compliance programs, legal teams, or regulated industry requirements. The open-source tools don't replace these — they're technically capable but require significant internal tooling to reach enterprise compliance workflow maturity.

Frequently Asked Questions

Does EU CRA apply to my open-source project?

The CRA applies primarily to software placed on the EU market for commercial purposes. Open-source software developed or supplied outside the course of a commercial activity is outside scope entirely — Recital 18 states that supplying FOSS "not monetised by their manufacturers" is not a commercial activity — but contributors who offer open-source software commercially lose that. A foundation acting as an Article 24 "open-source software steward" is a separate category again — in scope, with reporting duties, exempt only from fines. If your open-source project is the basis for a commercial product, consult legal counsel. For the full scope breakdown, see SBOM and Vulnerability Scanning: What the EU CRA Means for Your Dependencies.

What format does the EU CRA require for SBOMs?

The CRA regulation references machine-readable SBOMs but doesn't mandate a specific format as of current guidance. SPDX and CycloneDX are both widely accepted and supported by all major SBOM tools. ENISA guidance (expected before the December 2027 deadline) will likely clarify format requirements. Generating both formats from your SBOM tool covers the likely options.

Is EPSS required for EU CRA compliance?

Not explicitly — the regulation doesn't mention EPSS by name. But the 24-hour reporting requirement for "actively exploited vulnerabilities" requires you to know when a vulnerability becomes actively exploited. EPSS provides early warning before a CVE reaches KEV status. KEV is the definitive signal — a CVE appearing in the CISA KEV catalog is actively exploited by definition, and that's when the 24-hour clock starts. Tools with native KEV monitoring (Grype, GeekWala) are better positioned for this requirement than tools that require manual KEV correlation.

Can I generate an SBOM with Trivy and then scan it with Grype?

Yes. Trivy generates SBOMs in CycloneDX and SPDX formats. Grype can scan those SBOMs directly: grype sbom:sbom.json. This is a legitimate workflow if you want Trivy's broad container scanning for SBOM generation and Grype's EPSS + KEV enrichment for vulnerability scanning. The formats are compatible.

What's the difference between an SBOM and a VEX document?

An SBOM lists what components are in your software. A VEX (Vulnerability Exploitability eXchange) document asserts whether a known vulnerability in one of those components actually affects your product in its deployed configuration. For example, if CVE-2024-1234 affects a library you use, but you never call the vulnerable function, a VEX document records that assertion with justification. VEX helps narrow which CVEs actually require CRA reporting. For a full explanation, see What is VEX and Why it Matters for Vulnerability Management.

Do I need an SBOM tool and a separate vulnerability scanner?

Not necessarily. Grype and Trivy both generate SBOMs and scan them in the same tool. The Syft + Grype split (generate SBOM separately, then scan) is an architectural choice that gives you more control over the SBOM artifact. If you want a single command that outputs "here are the vulnerabilities in my container image with KEV flags," Trivy handles that. If you want explicit SBOM artifacts for compliance documentation, Syft + Grype gives you more control.

---

The September 2026 deadline requires knowing what's exploited in your dependencies before it's exploited against you.

Monitor your application dependencies for KEV-flagged vulnerabilities → — scan across 8 ecosystems, filter to actively exploited CVEs, and get scheduled monitoring so you know between deploys. Free tier available. For more on EU CRA requirements, see SBOM and Vulnerability Scanning: What the EU CRA Means for Your Dependencies and the SBOM Requirements 2026 Checklist.