In jedem Repository mit aktiviertem Dependency Graph liegt ein SBOM-Export direkt in der Oberfläche: Insights, dann Dependency graph, dort im Tab Dependencies der Button „Export SBOM“ oben rechts. Die Datei lädt sofort im Browser herunter, ohne CLI, ohne Installation, ohne externes Werkzeug. Für Teams, die SBOMs bisher für ein Projekt mit eigener Tooling-Kette halten, ist das der eigentliche Unterschied: GitHub liefert den Export als eingebautes Feature mit, nicht als zusätzlichen Schritt in der Pipeline.
Drei native Wege, ein Format
Neben dem Button beschreibt die GitHub-Dokumentation zwei weitere Wege zum selben Ergebnis, beide ebenfalls ohne externes Tooling. Über die REST-API löst eine Anfrage die SBOM-Erzeugung aus, die Antwort liefert eine sbom_url. Solange der Status 202 zurückkommt, ist das Dokument noch nicht fertig, bei Status 302 folgst du dem Redirect zur fertigen Datei. Und über GitHub Actions nennt die Dokumentation drei konkrete Actions, die ein SBOM als Workflow-Artifact erzeugen: die SPDX Dependency Submission Action (nutzt Microsofts SBOM Tool, SPDX 2.2), die Anchore SBOM Action (nutzt intern Syft, ebenfalls SPDX 2.2) und die SBOM Dependency Submission Action, die ein CycloneDX-SBOM an die Dependency-Submission-API lädt. Auch wenn eine dieser Actions intern auf Syft zurückgreift, läuft sie als dokumentierte GitHub Action, nicht als eigenständig von dir installiertes und gepflegtes CLI in deiner Pipeline. Alle drei Wege liefern am Ende ein Dokument im SPDX-Format, der Dokumentation zufolge dem „industry standard SPDX format“.
Was im SPDX-Dokument tatsächlich steht
Laut GitHub-Dokumentation gilt wörtlich: „SBOMs include an inventory of a project’s dependencies and associated information such as versions, package identifiers, licenses, transitive paths, and copyright information.“ Übersetzt: Versionen, Paket-Identifier, Lizenzen, transitive Abhängigkeitspfade und Copyright-Angaben zu allem, von dem dein Projekt abhängt. Für eine Bestandsaufnahme der eigenen Abhängigkeiten reicht das aus, und genau dafür ist der native Export gedacht.
Die Lücke: Dependents fehlen im nativen Export
Direkt im Anschluss an diese Aufzählung steht in der Dokumentation ein zweiter Satz, der in der Praxis leicht übersehen wird: „SBOMs do not include dependents (other projects that rely on your project).“ Der native Export beantwortet also nur, was dein Projekt braucht, nicht, wer dein Projekt braucht. Das ist keine Einschränkung einer bestimmten Export-Variante, sie gilt für den Button, die REST-API und die drei genannten Actions gleichermaßen, weil alle drei dasselbe SPDX-Dokument nach demselben Schema füllen.
Was das für die Frage „wer ist betroffen“ bedeutet
Sobald in einer deiner Abhängigkeiten eine Schwachstelle auftaucht, stellt sich meist zuerst die Frage, was in deinem eigenen Projekt davon betroffen ist, und die beantwortet der native Export zuverlässig. Die umgekehrte Frage, welche anderen Projekte oder Teams von deinem Projekt abhängen und deshalb benachrichtigt werden müssten, beantwortet derselbe Export nicht, weil Dependents laut Dokumentation kein Bestandteil des SBOM sind. Wer intern mehrere Repositories oder Bibliotheken pflegt, die von anderen Teams eingebunden werden, braucht für diese Richtung ein anderes Mittel, zum Beispiel die Abhängigkeits-Ansicht einzelner Repos im Dependency Graph selbst oder eine eigene Liste der internen Verwender. Der SPDX-Export aus dem Dependency Graph ersetzt das nicht.
Abgrenzung zu zwei anderen Beiträgen
Im Beitrag „Von der Excel-Liste zum SBOM“ vom 08.08.2026 ging es um den Tooling-Einstieg allgemein, also um den Weg von keiner SBOM-Pflege zu einer ersten funktionierenden Kette. Im Beitrag „SBOM in der Praxis: Software-Stückliste mit Syft erzeugen und mit Grype scannen“ vom 08.06.2026 ging es um ein eigenständig installiertes und bedientes CLI-Tooling, Syft zur Erzeugung und Grype zum Scannen. Hier geht es um keinen der beiden Fälle, sondern ausschließlich um den Weg, der in GitHub selbst eingebaut ist: Button, REST-API oder eine der drei genannten Actions, ohne dass du ein eigenes Werkzeug auswählen, installieren oder pflegen musst.
Konsequenz für dein eigenes Vorgehen
Bevor du für ein Repository eine eigene SBOM-Kette aufbaust, lohnt sich die Prüfung, ob der native Export bereits ausreicht. Für die reine Bestandsaufnahme der eigenen Abhängigkeiten im SPDX-Format tut er das. Für die Frage, wer von deinem Projekt abhängt, tut er das laut Dokumentation ausdrücklich nicht, und diese Lücke lässt sich auch mit mehrfachem Export nicht schließen, weil sie im Format selbst angelegt ist.
Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.
Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.
Kommentar verfassen