SBOMs & Komponenten

Jede Produktversion trägt eine aktive SBOM. Sie ist das Rohmaterial für alles Weitere: das Komponenteninventar, die flottenweite Schwachstellen-Korrelation sowie die Evidenz- und Dokumentationsfunktionen.

SBOM hochladen

Laden Sie an einer Produktversion eine CycloneDX-JSON- (v1.4–1.6) oder SPDX-JSON-Datei (v2.2/2.3) hoch. Das Format wird aus dem Dokument selbst erkannt — Sie wählen nie eines aus. Nicht erkennbare oder nicht parsbare Inhalte werden mit einer Fehlermeldung abgelehnt statt halb eingelesen.

Resilic liest das Dokument in Komponenten ein: Name, Version, Package-URL (PURL), CPE und Lieferant, soweit die SBOM sie liefert. Eine neue SBOM für dieselbe Version ersetzt die vorherige — es gibt genau eine aktive SBOM je Version.

SBOM beim Lieferanten anfragen

Fehlt Ihnen eine SBOM für eine Komponente oder Version, fragen Sie sie an:

1. Wählen Sie an der Produktversion Beim Lieferanten anfragen und geben Sie Name und E-Mail-Adresse des Lieferanten ein.
2. Resilic sendet dem Lieferanten einen tokenisierten Upload-Link per E-Mail (und zeigt ihn auch Ihnen, damit Sie ihn direkt teilen können). Der Lieferant benötigt kein Konto: Die Upload-Seite zeigt nur Ihren Organisationsnamen, das angefragte Produkt/die Version und seinen eigenen Namen — sonst nichts.
3. Verfolgen Sie Anfragen je Version: wartend, eingereicht, abgelaufen oder widerrufen. Eine wartende Anfrage können Sie jederzeit widerrufen; Links sind einmal verwendbar und laufen von selbst ab.

Lädt ein Lieferant hoch, geht die SBOM nicht automatisch live. Sie prüfen sie und wählen Übernehmen & einlesen — erst dann wird sie zur aktiven SBOM der Version, mit dem Lieferanten als dokumentierter Herkunft. Bis dahin bleibt Ihre zuvor selbst hochgeladene SBOM (falls vorhanden) aktiv.

Eine SBOM ohne Tooling erstellen

Keine SBOM vom Lieferanten — nur eine Stückliste als Tabelle? Erstellen Sie eine in Resilic. Bei jeder Produktversion ohne SBOM können Sie Komponenten von Hand erfassen (Name, Version, Lieferant) oder eine CSV-Datei importieren: Datei wählen, in der Vorschau die Spalten den Komponentenfeldern zuordnen (nur der Komponentenname ist Pflicht — gängige deutsche und englische Spaltennamen wie Komponente oder Hersteller schlägt Resilic automatisch vor) und importieren. Nicht lesbare Zeilen werden einzeln mit Zeilennummer gemeldet; der Rest wird trotzdem importiert, und ein erneuter Import derselben Datei überspringt bereits Erfasstes.

Wenn das Register Ihren Kenntnisstand abbildet, wählen Sie SBOM erstellen (CycloneDX). Resilic erzeugt aus den erfassten Komponenten ein CycloneDX-1.6-Dokument und macht es zur aktiven SBOM der Version — es speist Schwachstellen-Korrelation, Abdeckungs-Badges und den Passport genau wie eine hochgeladene SBOM, und Sie können das Artefakt herunterladen und an Kunden oder Auditoren weitergeben.

Zwei Ehrlichkeitsregeln sind eingebaut. Das Artefakt nennt Resilic als Ersteller — es ist Ihre Komponentenangabe, zusammengestellt aus Ihren Eingaben, nie ein Scan-Ergebnis. Und solange Sie nicht „Die Komponentenliste ist vollständig“ ankreuzen, vermerkt die SBOM selbst ihre Zusammensetzung als unvollständig — niemand hält so eine Teilliste versehentlich für ein vollständiges Inventar. Das Register lässt sich jederzeit bearbeiten und die SBOM neu erstellen; erstellte SBOMs tragen als Herkunft das Badge Erstellt.

Signierte SBOMs & Manipulationsschutz

Jede importierte SBOM speichert den SHA-256-Hash der hochgeladenen Datei — der Integritätsanker, den Sie jederzeit mit dem Original vergleichen können. CycloneDX-Dokumente mit eingebetteter Signatur (JSON Signature Format, z. B. via cyclonedx-cli sign) werden beim Import verifiziert:

• Signiert · Schlüssel hinterlegt — Signatur gültig und passt zum Schlüssel aus der Qualifizierungsakte des Lieferanten. Die stärkste Herkunftsstufe.
• Signiert — kryptografisch gültig, aber kein hinterlegter Schlüssel als Vertrauensanker.
• Signatur ungültig — das Dokument wurde nach dem Signieren verändert oder mit einem anderen als dem hinterlegten Schlüssel signiert. Als nicht vertrauenswürdig behandeln.

Zum Hinterlegen fügen Sie den öffentlichen Schlüssel (PEM) des Lieferanten einmalig in dessen Qualifizierungsakte ein — außerhalb der Plattform ausgetauscht. Resilic verifiziert Signaturen; es signiert selbst keine SBOMs.

Die Original-SBOM herunterladen

Jede seit Einführung der Rohdaten-Aufbewahrung importierte SBOM lässt sich byte-identisch wieder herunterladen — eine eingebettete Lieferanten-Signatur bleibt prüfbar, und der erfasste SHA-256 passt zur erhaltenen Datei. SBOM herunterladen finden Sie neben dem Signatur-Badge in der Produktansicht. Vor der Aufbewahrung importierte SBOMs haben kein gespeichertes Original — einmal neu hochladen genügt.

Komponenten-End-of-Life

Jede Komponente kann ein End-of-Life-Datum (EOL) tragen — den Zeitpunkt, ab dem der Lieferant sie nicht mehr pflegt. Setzen Sie es von Hand an jeder Komponente in der SBOM-Ansicht oder importieren Sie EOL-Daten aus einer CSV (Spalten purl, end_of_life als JJJJ-MM-TT), um eine ganze SBOM auf einmal zu füllen — die Zuordnung erfolgt über die Package-URL.

Das früheste Komponenten-EOL ist die stärkste einzelne Einschränkung eines vertretbaren Unterstützungszeitraums: Erreicht eine Komponente ihr End-of-Life vor dem für das Produkt zugesagten Unterstützungszeitraum, markiert Resilic ein Unterstützungszeitraum-Risiko an diesem Produkt und benachrichtigt Sie — sofern abonniert — einmalig per E-Mail. Es ist ein Hinweis zur Bereitschaft, keine harte Sperre: Verkürzen Sie den zugesagten Zeitraum, planen Sie ein Komponenten-Update oder dokumentieren Sie, warum die kürzere Komponenten-Lebensdauer vertretbar ist. Der Hinweis verschwindet automatisch, sobald das Risiko nicht mehr besteht.

Komponenten-Normalisierung

SBOMs von Industrielieferanten sind in der Praxis unordentlich: dieselbe Komponente unterschiedlich benannt, fehlende Identifikatoren, inkonsistente Versionen. Resilic normalisiert jede eingelesene Komponente auf eine kanonische Identität (kanonische PURL, validierte CPE), damit die Korrelation zuverlässig treffen kann — und dedupliziert versionsübergreifend: dasselbe OpenSSL 3.1.0 in fünf Produktversionen ist ein Registry-Eintrag.

Die Normalisierung ist standardmäßig deterministisch. Bei fehlenden oder unscharfen Identifikatoren kann ein KI-gestützter Normalisierer sie auflösen; solche Komponenten sind sichtbar als „KI-normalisiert“ gekennzeichnet und können von Ihnen korrigiert werden. Beim Einlesen wird nichts unterschrieben — die menschliche Freigabe erfolgt dort, wo sie zählt: am Artikel-14-Bericht selbst.

Was das ist — und was nicht

SBOM-Pflichten sind Pflichten aus CRA Artikel 13 / Anhang I und gelten ab dem 11. Dez 2027 — sie sind nicht Teil der Artikel-14-Meldepflicht, und eine eingelesene SBOM ist keine „Artikel-13-Compliance“. In Resilic ist die SBOM das Erkennungsfundament der Artikel-14-Bereitschaft: Sie erlaubt es, eine CVE zu einer Komponente, eine Komponente zu einer Produktversion und eine Version zu den Maschinen im Feld zurückzuverfolgen.

Namensprüfung

Jede Komponente im Register wird automatisch gegen eine kuratierte Liste bekannter Paketnamen geprüft: Ein-Buchstaben-Abweichungen, verwechselbare Zeichen (etwa l0dash) und bekannte Namen unter einem unerwarteten Paket-Ökosystem — ein typisches Dependency-Confusion-Muster. Eine markierte Komponente zeigt den Hinweis Namen prüfen mit einer Erklärung. Die Prüfung markiert zur eigenen Beurteilung; sie blockiert oder verwirft nie eine Komponente, und eine Markierung ist kein Urteil über Bösartigkeit.