Svelnor SBOM
Laden Sie ein Container-Image oder ein Build-Artefakt hoch, bekommen Sie eine maschinenlesbare Komponenten-Liste zurück - im Format CycloneDX und SPDX, angereichert um Schwachstellen-Daten aus öffentlichen Datenbanken. Kein Abonnement, keine Datenspeicherung über den Scan hinaus. Als Pay-per-Call für CI-Integration oder als Einzelabruf im Browser.
Dieses Werkzeug befindet sich noch in Entwicklung und ist noch nicht nutzbar. Die hier beschriebenen Funktionen sind als Vorschau auf den späteren Lieferumfang zu verstehen.
- Eingaben: OCI-Container-Images, tar.gz, jar, npm- und Python-Pakete
- Ausgaben: CycloneDX 1.6 (JSON), SPDX 2.3 (JSON oder Tag-Value), PDF mit Zusammenfassung
- Abgleich gegen OSV.dev und GitHub Advisory Database, CVE-Zuordnung mit Severity
- BSI-TR-03183-2-konformes Pflichtfeld-Set als Default, optional erweiterbar
- REST-API für CI-Integration, Single-Shot-Upload für Ad-hoc-Prüfungen
- Eingabedatei wird nach dem Scan gelöscht, die SBOM wird nicht bei uns archiviert
Wofür SBOM gemacht ist
Der Cyber Resilience Act verpflichtet Softwarehersteller ab 11. Dezember 2027, eine SBOM über die Hauptkomponenten ihrer Produkte zu führen und auf Anfrage den Marktüberwachungsbehörden bereitzustellen. SBOM-Erzeugung selbst ist mit Open-Source-Tools lösbar, aber die Pflege, die Formatkompatibilität und das VEX-Statement (Vulnerability Exploitability eXchange) für "CVE trifft uns gar nicht" sind Aufwand, den man nicht jedes Release neu treiben will.
Kein Abonnement-Zwang
Wer einmal im Quartal ein Release prüfen will, zahlt pro Scan. Wer in einer CI-Pipeline pro Commit prüft, bekommt einen monatlichen Paketpreis. Keine Datenaufbewahrung auf unserer Seite außer dem, was für die jeweilige Ausgabe nötig ist.
Unterschied zu Svelnor Scan
Scan prüft einzelne Dateien auf Schadsoftware und strukturelle Auffälligkeiten. SBOM prüft Build-Artefakte auf Komponenten und Abhängigkeiten. Ein Container-Image kann in Scan einen grünen Befund bekommen und in SBOM trotzdem eine kritische Log4j-Abhängigkeit offenlegen. Beides ergänzt sich, ist aber nicht dasselbe.
Offene Punkte
VEX-Erzeugung (also die Bewertung "diese CVE ist für uns nicht ausnutzbar") ist in der ersten Ausbaustufe manuell. Signierte SBOM-Auslieferung über eine Transparency-Log-Verankerung kommt später mit Svelnor Sign. Wer SLSA-Level-3-Build-Provenance braucht, ist mit sigstore/cosign direkt besser bedient; wir liefern dann den SBOM-Anteil und akzeptieren eine Fremd-Provenance.