“Fix without delay.” Which one first?

The CRA tells you to identify what’s inside your product, keep a machine-readable SBOM and remediate without delay. It doesn’t tell you where to start. Working that out is mostly arithmetic, and that’s the part sbomtriage does.

Where the regulation is, today
26days since reporting duties began
430days until everything else applies
  1. 11 Sep 2026Reporting duties began
  2. 11 Dec 2027Full obligations apply

If it’s being exploited, the clock is shorter than you think.

Regulation (EU) 2024/2847, Article 14

An actively exploited vulnerability in your product starts a reporting sequence measured in hours. Knowing which of your components are in CISA’s exploited catalogue is the earliest warning you’ll get that the clock may be running.

  1. 24h
    Early warning

    To your CSIRT and ENISA, once you know.

  2. 72h
    Notification

    What it is, what you’ve done and what you’ll do next.

  3. 14d
    Final report

    Within 14 days of a fix or mitigation being available: the correction, and how users get it.

Check what’s inside your product

No account needed. The file is parsed in memory and never written to disk. Your report includes a CRA evidence section and draft wording you can adapt.

Drop files here, or click to browse

Add several at once, up to 20 MB. No account needed.

  • CycloneDX JSON
  • SPDX JSON
  • package-lock.json
  • package.json
  • yarn.lock
  • pnpm-lock.yaml
  • requirements.txt
  • Pipfile.lock
  • poetry.lock
  • Cargo.lock
  • go.mod
  • composer.lock
  • Gemfile.lock
  • packages.lock.json
Manufacturers shall … identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products.

Regulation (EU) 2024/2847, Annex I, Part II

That’s the sentence sbomtriage reads and acts on. The rest of Annex I (secure design, update delivery, documentation) is your job, and no scanner can do it for you.

What it does, and what it won’t claim to do.

A readiness check isn’t a compliance assessment. Nothing here makes anyone compliant or certified, and nothing is filed on your behalf.

Where it helps

  • Reads the SBOM the regulation asks you to keep, in CycloneDX or SPDX, or a lockfile.
  • Flags vulnerabilities in CISA’s Known Exploited catalogue, which is an early signal that reporting duties may apply.
  • Ranks what to fix first and prints the reason for every decision, so the ordering can be defended.
  • Scores how complete your SBOM is, so a document that looks compliant but says nothing doesn’t go unnoticed.
  • Produces a report and exports you can keep as evidence of what you found and when.
  • Drafts wording you can adapt for your own technical documentation.

Where it doesn’t

  • Make anyone compliant or certified. No tool can, and this one doesn’t claim to.
  • Decide whether a flaw is actively exploited in your product. That’s your assessment to make, with legal advice.
  • File anything with ENISA or a national authority on your behalf.
  • Generate an SBOM from firmware or a binary. It reads what you already declare.
  • Cover the rest of Annex I: secure design, update delivery, and product documentation.