Auf GitHub-Releases sterben SBOMs einen einsamen Tod
| Vivek Sahu
In GitHub-Releases veröffentlichte SBOMs gelangen selten direkt in Ihre Sicherheitswerkzeuge. Erfahren Sie hier, wie sbommv die Übertragung an Dependency-Track vollständig automatisiert – ganz ohne manuellen Aufwand.
Übersicht
Hallo zusammen 👋, SBOM-Enthusiasten! Seit der Executive Order zur Cybersicherheit von 2021 von Joe Biden sind SBOMs (Software-Stücklisten) unverzichtbar für die Softwaresicherheit und -compliance geworden. Da Länder wie die EU, USA, Deutschland und Indien ihre eigenen SBOM-Vorschriften einführen, ist klar:
SBOMs sind nicht mehr optional – sie sind der neue Standard.
Um dieser Nachfrage gerecht zu werden, haben sich Werkzeuge für die SBOM-Erstellung, -Signierung, -Qualitätsanalyse, -Anreicherung und -Integration in Sicherheitsplattformen rasant weiterentwickelt, was maßgeblich von der Open-Source-Community vorangetrieben wurde.
Die SBOM-Transfer-Herausforderung
Nach der Erstellung muss eine SBOM in der Regel manuell heruntergeladen, hochgeladen und in Sicherheitswerkzeuge integriert werden, was bei mehreren Schritten menschliches Eingreifen erfordert.
Dieser Ansatz ist:
❌ Zeitraubend – Das wiederholte Herunterladen und Hochladen von SBOMs kostet wertvolle Zeit.
❌ Fehleranfällig – Manuelle Handhabung erhöht das Fehlerrisiko.
❌ Veraltet – Im Zeitalter der Automatisierung lässt sich die Abhängigkeit von manuellen Arbeitsabläufen einfach nicht skalieren.
Der manuelle Weg gehört in der Welt der Automatisierung der Vergangenheit an.
Diese Ineffizienz ist ein großes Hindernis für Sicherheitsteams und verlangsamt das Risikomanagement in der Software-Lieferkette.
Nahtloser SBOM-Transfer mit sbommv
Bei Interlynk haben wir sbommv entwickelt, um nahtlose SBOM-Übertragungen zwischen Systemen zu ermöglichen. Seine modulare Architektur unterstützt Eingabe- und Ausgabeadapter sowie Übersetzung und Anreicherung, was Flexibilität und Anpassungsfähigkeit gewährleistet. Dieses Design macht sbommv hochgradig erweiterbar und ermöglicht in Zukunft eine einfache Integration mit zusätzlichen Systemen.
Eliminiert manuelle Arbeit – Kein Herunterladen, Hochladen oder mühsame Dateihandhabung mehr.
Mühelose und nahtlose Integration – Verschiebt SBOMs nahtlos und mit minimalem Einrichtungsaufwand über Plattformen hinweg.
Skalierbar & zukunftssicher – Passt sich an die sich entwickelnden Sicherheits- und Compliance-Anforderungen an.
🚀 Mit sbommv fließen SBOMs vom Ursprung zum Ziel ohne manuellen Aufwand – das eliminiert menschliche Eingriffe und fügt sich perfekt in den modernen, auf Automatisierung ausgerichteten Ansatz ein.
Praxisnahes Szenario
Viele Softwareprojekte veröffentlichen SBOMs auf GitHub, zusammen mit Binärdateien, Archiven, ausführbaren Dateien und Signaturen. Die SBOM-Artefakte werden auch als digitale Artefakte bezeichnet.
Sobald eine SBOM generiert wurde, muss sie an SBOM-Management-Plattformen wie Dependency-Track, Interlynk und andere Sicherheitstools für eine tiefere Analyse, Schwachstellenbewertungen und Compliance-Tracking übertragen werden. Dieser Prozess ist jedoch oft manuell und ineffizient. Sicherheitsteams oder Ingenieure müssen SBOMs in der Regel manuell suchen, herunterladen und hochladen, was unnötigen Mehraufwand verursacht und das Fehlerrisiko erhöht.
Dieser veraltete Arbeitsablauf umfasst:
1️⃣ Manuelles Suchen nach SBOMs in GitHub-Releases oder anderen Repositories.
2️⃣ Herunterladen und erneutes Hochladen dieser in SBOM-Management-Plattformen zur Verarbeitung.
3️⃣ Wiederholen dieses Prozesses für jedes Software-Release über mehrere Repositories hinweg – was zu Zeitverschwendung und potenziellen Inkonsistenzen führt.
Dieser manuelle Arbeitsablauf ist weit verbreitet in Open-Source-Projekten, Unternehmen und regulierten Branchen, in denen Softwaresicherheit und Compliance von entscheidender Bedeutung sind. Da sich die Softwareentwicklung beschleunigt und die Release-Zyklen verkürzen, steigt die Häufigkeit der SBOM-Generierung. Die Erwartung an manuelle SBOM-Übertragungen ist nicht mehr praktikabel – Organisationen benötigen einen skalierbaren, automatisierten Ansatz, um Schritt zu halten.
Um diese Herausforderung anzugehen, werfen wir einen Blick auf eine praxisnahe Anleitung zur effizienten Übertragung von SBOMs über Systeme hinweg mittels sbommv...
sbommv in Aktion 🚀
Installation
Wenn Sie nach alternativen Installationsmethoden suchen, können Sie dieser Anleitung folgen.
Praxistest mit sbommv
Bevor Sie SBOMs von GitHub nach Dependency-Track übertragen, stellen Sie sicher, dass Sie es installiert haben und es ausgeführt wird. Detaillierte Schritte zur Installation von Dependency-Track finden Sie im [Anhang](Appendix: Setting Up Dependency-Track) im unteren Bereich.
Wir sind mit der Einrichtung der Voraussetzungen für sbommv fertig. Lassen Sie uns die Power von sbommv entfesseln…
1. Automatischer SBOM-Transfer von GitHub nach Dependency-Track
Dies ist der einfachste und am stärksten automatisierte Weg, SBOMs mit minimalem Aufwand für den Benutzer zu verwalten. Er nutzt die API von GitHub, um automatisch die SBOM für den neuesten Main-Branch abzurufen, da GitHub den Export von SBOMs für ein Repository ermöglicht.
HINWEIS: Aktivieren Sie den SBOM-Export über die Dependency Graph API
Führen Sie den folgenden Befehl aus, um die SBOM aus dem sbommv-Repository abzurufen und nach Dependency-Track zu verschieben:
Nach der Ausführung:
Die SBOM wird abgerufen --> in CycloneDX konvertiert --> in Dependency-Track hochgeladen.
Falls das Projekt nicht existiert, wird es in Dependency-Track automatisch erstellt. Oben wird es mit dem Namen interlynk-io/sbommv-latest erstellt.
Zusammen mit der Projekterstellung werden Beschreibung und Tags hinzugefügt. Oben wird die Beschreibung als - "Created & uploaded by sbommv" und die Tags als "github" und "sbommv" hinzugefügt.
Vor- und Nachteile der Nutzung der GitHub-API-Methode für den SBOM-Transfer
Da GitHub den Export von SBOMs manuell oder über seine Dependency Graph API ermöglicht, stellt es eine bequeme Quelle für SBOMs dar.
✅ Vorteile
✔️ Vollständig automatisiert – Erübrigt die manuelle Erstellung und Übertragung von SBOMs.
✔️ Hält Projekte auf dem neuesten Stand – Synchronisiert sich automatisch mit Dependency-Track, sodass die neueste SBOM immer verfügbar ist.
✔️ Der schnellste Weg für den Einstieg, ohne Tools zur SBOM-Erstellung nutzen zu müssen.
❌ Nachteile
⚠️ Beschränkt auf den Main-Branch – Die API von GitHub stellt SBOMs nur für den Standard-Branch bereit, was bedeutet, dass kein Einblick in frühere Versionen oder spezifische Releases möglich ist.
⚠️ Keine historischen Snapshots – Es werden keine SBOMs für ältere Versionen der Software erfasst, was für Compliance- oder Sicherheitsaudits kritisch sein kann.
Alternative GitHub-Methoden für fortgeschrittenere SBOM-Workflows
Für Teams, die eine größere Kontrolle über die SBOM-Extraktion benötigen, unterstützt sbommv zusätzliche GitHub-Methoden über den API-Ansatz hinaus:
Release-basierte Methode – Ruft alle SBOMs aus GitHub-Releases ab und stellt so sicher, dass die Versionshistorie erfasst wird.
Tool-basierte Methode – Klont das Repository und erstellt neue SBOMs mit Tools wie Syft, was eine umfassendere Software-Stückliste liefert.
Diese Optionen ermöglichen tiefere Einblicke, eine bessere Versionsverfolgung und ein vollständigeres SBOM-Management, das über das hinausgeht, was die API von GitHub allein bieten kann.
2. Hochladen bereits vorhandener SBOMs aus einem Ordner nach Dependency-Track
In Fällen, in denen SBOMs bereits lokal gespeichert sind, kann sbommv diese nahtlos aus einem Ordner nach Dependency-Track übertragen.
Um dies zu demonstrieren, lassen Sie uns einen lokalen Ordner mit SBOMs befüllen. Wir werden alle SBOMs aus dem sbomqs GitHub-Repository über die GitHub-Release-Methode herunterladen, um sicherzustellen, dass wir die neueste verfügbare Version abrufen.
Abb.: Abgerufene SBOMs von der "sbomqs"-Repository-Release-Seite, lokal im Ordner "demo" gespeichert
Da wir nun eine Sammlung von SBOMs in unserem lokalen Ordner demo haben, besteht der nächste Schritt darin, diese mithilfe von sbommv nahtlos nach Dependency-Track zu übertragen.
Führen Sie den folgenden Befehl aus, um alle SBOMs aus dem lokalen Ordner demo nach Dependency-Track hochzuladen:
Abb.: SBOMs aus dem demo-Ordner nach DTrack hochladen
Abb.: In DTrack hochgeladene SBOMs mit dem Projektnamen als "primary comp-version"
Nach der Ausführung:
Nur gültige SBOM-Dateien werden erkannt und hochgeladen.
SPDX 2.2 SBOMs werden automatisch auf SPDX 2.3 upgegradet, bevor sie in CycloneDX konvertiert werden, um die Kompatibilität mit der Akzeptanz von Dependency-Track zu gewährleisten.
Erstellt automatisch den Projektnamen unter Verwendung des primären Komponentennamens und der Version aus der SBOM.
3. Dry-Run-Modus (Optionale Funktion)
Vor der Durchführung eines SBOM-Transfers bietet sbommv einen Dry-Run-Modus (Testlauf), der es Benutzern ermöglicht, eine Vorschau der zu verarbeitenden SBOMs anzuzeigen — ohne tatsächliche Änderungen vorzunehmen. Diese Funktion hilft dabei, Übertragungen sowohl für GitHub-basierte als auch für ordnerbasierte SBOM-Quellen zu überprüfen.
Vorschau eines Transfers von GitHub nach Dependency-Track
Um zu überprüfen, welche SBOMs von einem GitHub-Repository nach Dependency-Track übertragen werden, führen Sie folgenden Befehl aus:
Abb.: Dry-Run-Modus zur Vorschau des Transfers von GitHub nach Dependency-Track
Zeigt die Liste der SBOMs an, die aus allen Repositories abgerufen würden, sowie deren Formate.
Stellt sicher, dass Projektnamen und Formate vor der Ausführung korrekt identifiziert werden.
Gesamtzahl der abgerufenen SBOMs.
Vorschau eines Transfers von einem Ordner nach Dependency-Track
Um SBOMs zu überprüfen, die in einem lokalen Ordner gespeichert sind, bevor sie nach Dependency-Track übertragen werden, führen Sie folgenden Befehl aus:
Abb.: Dry-Run-Modus zur Vorschau des Transfers von einem Ordner nach Dependency-Track
Listet im Ordner erkannte gültige SBOM-Dateien auf.
Bestätigt das Format, den Projektnamen, mit dem es in DTrack hochgeladen wird, die Spec-Version und den Dateinamen.
Gesamtzahl der hochzuladenden SBOMs.
Der Dry-Run-Modus hilft, Fehler zu vermeiden und Übertragungen zu validieren, bevor sie ausgeführt werden. Dies macht ihn zu einer nützlichen Funktion für ein reibungsloses SBOM-Management.
Bisher haben wir zwei wichtige Praxisszenarien abgedeckt:
1️⃣ Automatische SBOM-Erstellung und -Übertragung – Direktes Abrufen von SBOMs von GitHub und nahtlose Integration in Dependency-Track.
2️⃣ Hochladen bereits vorhandener SBOMs – Übertragen lokal gespeicherter SBOMs aus einem Ordner nach Dependency-Track bei gleichzeitiger Sicherstellung der Formatkompatibilität und Projektorganisation.
Diese Workflows zeigen, wie sbommv den SBOM-Transfer rationalisiert, den manuellen Aufwand reduziert und sicherstellt, dass SBOMs für Sicherheits- und Compliance-Analysen immer verfügbar sind.
Zukünftige Arbeit: Wie geht es weiter mit sbommv?
Wir fangen gerade erst an! 🚀 Das erwartet Sie als Nächstes:
Ordner-Überwachung – Anstatt SBOM-Übertragungen manuell auszulösen, wird sbommv Verzeichnisse kontinuierlich überwachen und neue SBOMs automatisch hochladen, sobald sie erscheinen. Bleiben Sie dran – dieses Feature wird nächste Woche veröffentlicht 🚀, inklusive praktischer Anwendung mit der Interlynk-Plattform !
Erweiterte Eingabe- und Ausgabeunterstützung – Wir fügen Unterstützung für S3-Buckets, zusätzliche Sicherheitswerkzeuge und weitere SBOM-Formate hinzu, was sbommv noch vielseitiger macht.
Fortgeschrittene SBOM-Verarbeitung – Verbesserungen sind auf dem Weg, darunter bessere SBOM-Formatkonvertierungen, eine optimierte Validierung und eine detaillierte Protokollierung für mehr Transparenz bei SBOM-Übertragungen.
Wenn Sie sbommv nützlich finden, zeigen Sie Ihre Unterstützung, indem Sie dem Repository ein ⭐ auf GitHub geben. Ihr Feedback und Ihre Beiträge helfen, die zukünftige Entwicklung voranzutreiben!
Haben Sie einen Feature-Wunsch? Erstellen Sie ein Issue in unserem GitHub-Repo – wir freuen uns auf Ihre Ideen! 🚀
Fazit
Die manuelle Übertragung von SBOMs ist kein praktikabler Ansatz mehr, insbesondere da sich die Anforderungen an die Sicherheit der Software-Lieferkette und Compliance ständig weiterentwickeln. Ineffiziente Arbeitsabläufe verschwenden nicht nur Zeit, sondern bergen auch Risiken, die die Sicherheit gefährden können. Automatisierung ist die einzige skalierbare Lösung.
Mit sbommv verläuft die SBOM-Übertragung nahtlos – unabhängig davon, ob Sie direkt von GitHub abrufen oder bereits vorhandene SBOMs aus lokalen Ordnern zu Dependency-Track übertragen. Durch den Verzicht auf manuelle Arbeitsschritte können Unternehmen sicherstellen, dass SBOMs immer auf dem neuesten Stand, in Sicherheitstools integriert und für Analysen sofort verfügbar sind.
Der Übergang zu einem automatisierten SBOM-Management ist nicht nur eine Annehmlichkeit – er ist eine Notwendigkeit.
"Nutzen Sie sbommv noch heute und automatisieren Sie Ihren SBOM-Lebenszyklus
– weil Sicherheit sich nicht manuell skalieren lässt."
Referenzen & Ressourcen
🔹 sbommv GitHub-Repository – [GitHub Link]
🔹 Dependency-Track Dokumentation – [DT-Dokumentations-Link] und [GitHub Link]
🔹 SPDX- & CycloneDX-Spezifikation – [SPDX Link] | [CycloneDX Link]
🔹 Offizielle Interlynk-Website – [Website-Link]
🔹 Interlynk OSS-Projekte – [GitHub Link]
🔹sbommv [Leitfaden für den Einstieg] und [Beispiele]
Anhang: Einrichtung von Dependency-Track
Führen Sie Dependency-Track lokal auf Ihrem System mithilfe von docker aus
Besuchen Sie http://localhost:8080
Melden Sie sich mit den Standard-Zugangsdaten an:
Ändern Sie nun Ihr Passwort.
Schließlich gelangen Sie auf die Startseite der Dependency-Track-Plattform.
Lassen Sie uns den Token DTRACK_API_KEY erstellen, der für den Zugriff auf die Plattform erforderlich ist.
Gehen Sie auf der linken Seite zu Administration --> Access Management --> Teams --> klicken Sie auf Administrator --> kopieren Sie die folgenden API-Schlüssel, in etwa so:
Exportieren Sie nun diesen Token in Ihrer CLI, bevor Sie sbommv ausführen.