14 Tage kostenlos testen, ohne Kreditkarte

CRA-Schwachstellen-Handling, endlich langweilig.

Seit dem 11. September 2026 müssen ausgenutzte Schwachstellen binnen 24 Stunden gemeldet werden. boring.tools überwacht deine SBOMs und entwirft die Meldungen.

Kostenlos testenDoku lesen
CRA-Meldungen / CVE-2026-45321
Beispielfall

CVE-2026-45321

CISA KEVENISA EUVD

Aktiv ausgenutzt in Lagerwerk Portal, erkannt vor 3 Std.

Frühwarnung

Als Nächstes

Binnen 24 Stunden nach Kenntnis

fällig in21:13:52

Meldung

fällig in 2 Tagen

Abschlussbericht

wartet auf einen Fix

  1. KI hat den Meldeentwurf vorbereitetvor 2 Std.
  2. Owner und Admins per E-Mail informiertvor 3 Std.
  3. Als aktiv ausgenutzt erkanntvor 3 Std.

Der CRA hat aus Dependency-Updates eine gesetzliche Frist gemacht

Und in den meisten Firmen landet das bei einer Person, neben allem anderen.

  1. 0 Std.

    Du erfährst davon

    Eine aktiv ausgenutzte Schwachstelle in einem Produkt, das du verkaufst.

  2. 24 Std.

    Frühwarnung

    An dein CSIRT und die ENISA, mit den Mitgliedstaaten, in denen das Produkt verkauft wird.

  3. 72 Std.

    Meldung

    Produkt, Schwachstelle und Exploit, die ergriffenen Maßnahmen.

  4. Fix + 14 Tage

    Abschlussbericht

    Schwere und Auswirkung, der Angreifer falls bekannt, das Sicherheitsupdate.

Art. 14 CRA, gilt seit dem 11. September 2026

Die 24-Stunden-Uhr läuft

Eine aktiv ausgenutzte Schwachstelle in einem Produkt, das du verkaufst, muss innerhalb von 24 Stunden gemeldet werden. Melden kannst du nur, was du kennst.

Hunderte Befunde, eine Person

Jeder Scanner findet etwas. Langsam ist die Entscheidung, was dein Produkt wirklich betrifft, und die beginnt mit jedem Release von vorn.

Nachweis auf Nachfrage

Kunden und Behörden fragen, was du wusstest und wie du entschieden hast. Eine Tabelle und ein Chat-Verlauf beantworten das nicht.

Drei Schritte. Dann wird's langweilig.

Einmal in der Pipeline einrichten. Hinschauen, wenn es zählt.

  1. Hochladen

    Dein Build erzeugt schon eine SBOM (cyclonedx-npm, cdxgen, Syft …). Ein curl-Aufruf in der CI schickt sie an boring.tools. Kein Agent, kein Zugriff auf dein Repository.

  2. Überwachen

    Jede Komponente wird gegen OSV abgeglichen. Ändern sich die Schwachstellendaten, werden deine Versionen im Support von selbst neu geprüft.

  3. Entscheiden

    Die KI schlägt einen VEX-Status mit Begründung vor, du nimmst an oder lehnst ab. Jede Entscheidung bleibt mit Historie erhalten und lässt sich als OpenVEX exportieren.

sbom-upload#482

v2.4.0 · 3f9a2c1 · push

running…
█

Was heute funktioniert

Alles auf dieser Liste ist produktiv im Einsatz.

Sehen

Was du auslieferst und was davon betroffen ist.

CI-Upload mit einem Aufruf

CycloneDX oder SPDX als JSON, über Upload-Keys, die deiner Organisation gehören, für ein Projekt oder alle. Snippets für GitHub Actions und GitLab CI.

Laufender Abgleich

Komponenten werden gegen unsere OSV-Kopie abgeglichen, alle fünf Minuten aktualisiert, mit den Versionsregeln jedes Ökosystems. Versionen im Support werden automatisch neu analysiert.

Ausgenutzte zuerst

Befunde, die CISA KEV oder ENISA EUVD als aktiv ausgenutzt listen, stehen oben, danach nach EPSS. Eine ausgenutzte 5 schlägt eine theoretische 9.8.

Abhängigkeitsgraph

Direkt oder transitiv, und welche direkte Abhängigkeit sie mitbringt. So weißt du, welches Upgrade einen Befund wirklich behebt.

Entscheiden

Was dein Produkt wirklich betrifft, nachvollziehbar dokumentiert.

VEX-Triage mit Historie

Betroffen, nicht betroffen, behoben oder in Prüfung, mit Begründung. Entscheidungen gehören zum Release und überstehen neue Uploads.

KI-Vorbewertung

Vorschläge auf Basis deines Einsatzprofils, mit Konfidenz und Monatsbudget. Die letzte Entscheidung trifft immer ein Mensch.

OpenVEX-Export & Fix-Hinweise

Entscheidungen als OpenVEX für Kunden exportieren. Für npm gibt es den Upgrade-Befehl, der einen Befund behebt.

Melden

Fristen, Entwürfe und Erinnerungen nach Art. 14.

CRA-Meldefälle

Eine ausgenutzte Schwachstelle in einem Produkt eröffnet einen Fall mit den Fristen nach Art. 14: Frühwarnung in 24 h, Meldung in 72 h, Abschlussbericht nach dem Fix. Zu jedem Schritt gibt es einen vorausgefüllten Entwurf für die ENISA-Plattform.

Ruhige Benachrichtigungen

Eine E-Mail, wenn ein Fall entsteht und vor jeder Frist. Sonst montags ein kurzer Digest, und nur, wenn es etwas zu sehen gibt.

Ein CRA-Meldefall in boring.tools

Deine Daten bleiben in Formaten, die du mitnehmen kannst

SBOMs rein, VEX raus. Kein proprietärer Lock-in.

Rein

  • CycloneDX

    SBOM-Import (JSON)

  • SPDX

    SBOM-Import (JSON)

  • OSV, KEV, EUVD, EPSS

    Schwachstellen- und Exploit-Daten

Raus

  • OpenVEX

    VEX-Export

  • CSAF 2.0

    in Arbeit

In Arbeit

Als Nächstes: der Rest der CRA-Kette

Daran bauen wir als Nächstes. Das ist noch nicht verfügbar.

  • CSAF-2.0-Export

    Das VEX-Format, das Industriekunden und das BSI erwarten, erzeugt aus denselben Entscheidungen.

  • CRA-Status pro Produkt

    Eine Ampel und ein Monats-PDF für die Geschäftsführung: SBOM aktuell, Befunde bearbeitet, Fristen eingehalten.

  • SBOM-Qualitätsprüfung

    Jeder Upload bewertet nach BSI TR-03183-2, mit der Korrektur für jede Lücke.

Im Vergleich

Ein ehrlicher Vergleich mit dem, was die meisten Teams heute nutzen.

 boring.toolsDependency-TrackTabelle
Laufender CVE-Abgleich auf SBOMs
Triage-Entscheidungen mit Historiemanuell
KI-Vorbewertung, Mensch entscheidet
Kein eigener Betrieb nötig
CRA-Meldeworkflow (Art. 14)manuell
CSAF-Exportin Arbeit
Self-Hostinggeplant

Häufige Fragen

Alles, was du vor der Anmeldung wissen willst.

Noch etwas offen? Schreib uns.
Ist boring.tools produktionsreif?

Ja. Upload, Abgleich, Triage, die CRA-Meldefälle mit E-Mail-Benachrichtigung und der OpenVEX-Export sind produktiv im Einsatz. CSAF-Export und ein CRA-Statusbericht stehen auf der Roadmap.

Erzeugt ihr SBOMs?

Nein. Das kann dein Build schon: cyclonedx-npm, cdxgen oder Syft brauchen eine Zeile in der CI. Wir nehmen das CycloneDX- oder SPDX-JSON und kümmern uns um alles danach.

Welche Ökosysteme werden abgedeckt?

Der Abgleich deckt npm, PyPI, Go, Maven, crates.io, RubyGems, Packagist und NuGet ab, jeweils mit eigenen Versionsregeln (semver, PEP 440, Maven-Qualifier). Betriebssystem-Pakete aus Container-Images folgen als Nächstes.

Woher kommen die Schwachstellendaten?

Aus OSV, das unter anderem GitHub Security Advisories und die Advisory-Datenbanken von Python, Go und Rust bündelt. Ob eine Schwachstelle aktiv ausgenutzt wird, kommt aus CISA KEV und der EU-Schwachstellendatenbank der ENISA, die Ausnutzungswahrscheinlichkeit aus EPSS.

Entscheidet die KI für mich?

Nein. Sie schlägt einen VEX-Status mit Begründung vor; ein Mensch nimmt an oder lehnt ab. Die KI-Triage ist optional und wird pro Projekt eingeschaltet.

Macht uns boring.tools CRA-konform?

Das schafft kein Tool allein. boring.tools deckt das Schwachstellen-Handling und den Meldeworkflow nach Art. 14 ab. Konformitätsbewertung, technische Dokumentation und sichere Entwicklung bleiben bei dir.

Kann ich es selbst hosten?

Self-Hosting ist als Option für größere Kunden geplant. Bis dahin läuft boring.tools als gehosteter Dienst.

Was wird es kosten?

Es gibt einen kostenlosen Plan für ein Produkt, Starter für 149 € und Business für 449 € im Monat pro Organisation, mit beliebig vielen Nutzern. Jede neue Organisation kann 14 Tage Business testen. Details auf der Preisseite.

Wie bekomme ich Zugang?

Melde dich in der App mit deiner geschäftlichen E-Mail-Adresse an. Du bekommst einen Anmeldelink, Passwörter gibt es nicht.

Mach den CRA langweilig.

Starte deine 14 Tage Testphase. Ohne Kreditkarte, in Minuten eingerichtet.

Kostenlos testen

Anmeldung per Link an deine geschäftliche E-Mail-Adresse