CVD Portal
← All tools
Free Tool

SBOM Exposure Snapshot

Upload or paste a CycloneDX, SPDX JSON document or dependency manifest to scan all declared components against the OSV.dev open vulnerability database. The scanner identifies known CVEs and security advisories with precise version matching, returning an immediate severity breakdown across Critical, High, Medium, and Low vulnerabilities alongside top exposed components. The live interactive scanner is available at /sbom-exposure with no registration required. The tool operates in-request and does not store your SBOM data on our servers. For continuous vulnerability monitoring and full CRA Annex I Part II(1) due diligence, CVD Portal integrates SBOM ingestion with automated alerting and CSAF 2.0 advisory generation.

Last updated 29 August 2026

Key takeaways

  1. Annex I Part II(1) mandates that manufacturers identify and document component vulnerabilities throughout the entire product lifecycle.
  2. Article 13(5) obligates manufacturers to exercise and document due diligence when integrating third-party software components.
  3. Vulnerability exposure analysis matches declared component versions against open advisory feeds aggregated in the OSV.dev database.
  4. Supported SBOM and manifest formats include CycloneDX JSON, SPDX 2.3, SPDX 3.0, and standard ecosystem dependency files.
.json, .txt, .mod, .lock, .xml

Accepts CycloneDX or SPDX JSON, or a dependency manifest (package.json, requirements.txt, go.mod, Cargo.toml, Gemfile.lock).

Analysed in-request. Your SBOM is never stored on our servers.

Flow diagram from an SBOM to an exploitation verdict. A CycloneDX or SPDX SBOM enters the CVD Portal platform. Component match against OSV.dev feeds exploitation evidence from GCVE, which carries CISA KEV, CIRCL sightings and EPSS, and that feeds level distillation. ENISA EUVD attaches to the evidence stage as a failover that answers with exploitation dates alone. Level distillation produces one of three verdicts, none, proof of concept, or exploited. A person then decides.
Evidence prompts a person and the person decides. The platform never sets actively exploited on its own, because that flag starts the Article 14 clock. EPSS is carried for context and never raises the verdict, because it forecasts exploitation rather than observing it.

Frequently asked

Where can I run the SBOM exposure snapshot tool?+

The live tool is available at /sbom-exposure. You can upload a CycloneDX or SPDX JSON document, or a package dependency manifest, to run an immediate vulnerability exposure scan.

What formats does the SBOM exposure snapshot support?+

The tool accepts CycloneDX JSON, SPDX 2.3 and 3.0 JSON, as well as package dependency manifests including package.json, requirements.txt, go.mod, Cargo.toml, and Gemfile.lock.

How are vulnerabilities matched against components?+

Components and their exact version strings are matched against OSV.dev, an open vulnerability database aggregating GitHub Security Advisories, RustSec, PyPA, Go vulnerability database, and distribution security feeds.

Does this tool upload or store my SBOM?+

No. The document is analysed in-request and is never stored on our servers or in any database. The scan results are returned directly to your browser.

How does SBOM exposure scanning help with CRA compliance?+

CRA Annex I Part II(1) requires manufacturers to identify and document vulnerabilities in components throughout the product lifecycle. Article 13(5) obligates manufacturers to exercise due diligence on third-party components. Regular SBOM vulnerability scanning provides the evidence needed to demonstrate component due diligence.

Other free CRA tools

SBOM Validator (BSI TR-03183-2 and CISA 2026 Minimum Elements)Upload or paste a CycloneDX or SPDX JSON SBOM and check it against BSI TR-03183-2 v2.1.0, the German federal guideline that concretises the CRA SBOM requirement. The validator verifies the minimum specification version of CycloneDX 1.6 or SPDX 3.0.1. It checks every required data field for the SBOM and for each component, including creator, timestamp, dependencies, licences, and hashes. Validation runs entirely in your browser. The same document is also assessed against the 2026 Minimum Elements for a Software Bill of Materials, version 2.1. CISA published this specification with seventeen partner agencies, including seven EU national cybersecurity authorities. That document replaced the 2021 NTIA minimum elements and expanded the field count from seven to seventeen. It is not EU law and creates no CRA obligation, but it is increasingly what procurement asks for. The two verdicts are reported separately and never blended because the frameworks disagree on key requirements. TR-03183-2 sets minimum format versions that the 2026 elements do not. In addition, the 2026 elements require transitive dependency coverage that CRA Annex I Part II(1) does not.SBOM Checker and Component CVE LookupThe SBOM checker matches software components against the NVD CVE database. Paste a component list in package@version form and the tool returns one NVD search link for each component, with no upload and no account.CSAF 2.0 Advisory ValidatorPaste your CSAF 2.0 JSON advisory and instantly validate the structure against the OASIS CSAF 2.0 schema. Identifies missing mandatory fields, invalid values, and flags common issues that would cause rejection by automated consumers and ENISA tooling.security.txt GeneratorGenerate a standards-compliant security.txt file (RFC 9116) for your product or website. The EU Cyber Resilience Act names no file format, and Annex I Part II point 6 requires a contact address for reporting vulnerabilities. security.txt is the machine-readable way to publish it.

Ready to automate your CVD programme?

CVD Portal integrates all these tools and handles your Article 13 and 14 obligations automatically.

Start your free portal →