rio. Ein Aufruf. Ein Beleg.

So sieht ein Beleg aus

Ausschnitt aus dem tatsächlich erzeugten Beispiel von rio v0.7.0: zwei SBOMs übernommen, Build-Angaben ergänzt, an Dependency-Track geliefert, Annahme bestätigt.

Consumed → enriched → delivered → acknowledged
api.cdx.json     1d2b04c0df45… → 55e46a63a8b3…  (2307 output bytes)
worker.cdx.json  721bd8311e64… → 085265392b20…  (2316 output bytes)
Added to both: build.url = https://ci.example.org/runs/42
build.id  = 42
Destination:   https://127.0.0.1:53946
Projects:      api / 1.0.0, worker / 1.0.0
TLS:           observed; certificate verification enforced
api:     HTTP 200, accepted; token 11111111-1111-4111-8111-111111111111
worker:  HTTP 200, accepted; token 22222222-2222-4222-8222-222222222222

Synthetische Daten: Beispiel-SBOMs, lokaler HTTPS-Empfänger und Beispiel-Tokens. Die Digests sind nur in diesem Ausschnitt gekürzt; der vollständige Beleg enthält sie ungekürzt. Die URL bezeichnet den Zielserver, in Ihrem Beleg steht Ihre konfigurierte Instanz.

Vollständiger JSON-Beleg (5.791 Bytes) · HTML-Bericht herunterladen · Lauffähiges Beispiel herunterladen

Eine Konfiguration. Vom lokalen Check bis zur Übergabe.

In rio.yaml stehen Ihre SBOMs, ergänzende Angaben und Lieferziele. Danach genügt rio: Der Aufruf führt die Verarbeitung aus und nennt den Pfad zum Beleg. Mit --skip-delivery bleiben alle Schritte lokal.

Erst offline prüfen

Normalisierung, Planung, Inspektion und Bericht laufen ohne Netzwerkzugriff. rio plan --json zeigt die wirksame Konfiguration, ohne etwas zu schreiben oder hochzuladen.

Dann gezielt ausliefern

Namen und Versionen für Dependency-Track stammen aus dem SBOM-Gegenstand. Fehlende Eingaben führen nie dazu, dass veraltete Ergebnisse eines früheren Laufs ausgeliefert werden. rio wiederholt Lieferungen nicht automatisch; eine verlorene Antwort gilt nicht als Ablehnung. Ausdrückliche Wiederholungen und Abgleiche erzeugen neue Belege mit Verweis auf den früheren Versuch.

Für interne Zertifizierungsstellen lässt sich ein CA-Zertifikat konfigurieren. Eine ausdrücklich gewählte Abschaltung der Zertifikatsprüfung wird im Beleg sichtbar; sie ist kein automatischer Fallback.

Schnellstart · Lieferziele einrichten · Aufbau und Grenzen des Belegs

Erprobter Umfang: Dependency-Track 5.1.1 über HTTP und HTTPS, zot und Distribution für die OCI-Lieferung, mit v0.5.0 zusätzlich Nexus Community 3.94.0-12. Distribution unterstützt die eigenständige SBOM-Lieferung; Image-Anhänge werden dort wegen fehlender Referrers-Unterstützung abgewiesen. Artifactory ist noch nicht validiert. Testumfang von v0.6.0 · v0.5.0

Was der Beleg aussagt

rio erzeugt keine Komponenteninventur und sucht nicht selbst nach Schwachstellen. Es ergänzt keine fehlenden Komponenten oder geratenen Abhängigkeiten. Ein bestandener Qualitätscheck bestätigt die deklarierten SBOM-Anforderungen, nicht die Vollständigkeit der SBOM.

Digests identifizieren die verarbeiteten Bytes. Sie authentifizieren nicht den Erzeuger und belegen nicht, was ein Empfänger aufbewahrt. Eine HTTP-Annahme ist keine bestätigte Verarbeitung. Bereitgestellte Build-Angaben bleiben Aussagen ihres Erzeugers.

Die CLI schreibt Belege und Normalisierungsstatements unsigniert. Separate Signier- und Prüfwerkzeuge können die Normalisierungsstatements mit einem lokalen Schlüssel signieren und zusammen mit der zugehörigen SBOM prüfen. Sie signieren nicht den Laufbeleg. Vertrauen in den Schlüssel und langfristige Aufbewahrung bleiben Aufgaben Ihrer Umgebung. Die Signaturen der rio-Release-Dateien und Apples Notarisierung ersetzen das nicht.

Die weitere Entwicklung

Geplant sind zusätzliche Beziehungen zwischen Release-Artefakten, SBOMs und Prüfergebnissen sowie die Auswertung vereinbarter Release-Anforderungen. Eine allgemeine Release-Freigabe oder die vollständige Verbindung bis zum aktuellen Deployment-Stand gehört noch nicht zum Funktionsumfang. rebaze implementiert die benötigten Prüfungen und Freigaberegeln in Ihrem Release-Prozess.

Release Controls und ihre Rolle verstehen