Bildquelle: Pexels / SHVETS production / https://www.pexels.com/photo/man-writing-label-on-box-7203964/
SBOM-Exports scheitern nicht an SPDX, sondern an Zehn-Sekunden-Automation
Software Bill of Materials, kurz SBOM, klingt zunächst nach Compliance-Vokabular für Audits. Gemeint ist im Kern aber etwas sehr Praktisches: eine maschinenlesbare Liste der Komponenten, Bibliotheken und Paketbeziehungen, die in einer Anwendung stecken. Dieses Verzeichnis wird relevant, sobald Sicherheitslücken, Lieferkettenprüfungen, Kundenanforderungen oder regulatorische Nachweise auf den Tisch kommen. Wer dann nicht belastbar sagen kann, welche Abhängigkeiten in welchem Stand in einem Repository oder Build enthalten sind, diskutiert nicht über Dokumentation, sondern über operative Blindheit.
Genau deshalb ist GitHubs aktuelle Änderung bei den SBOM-Exports mehr als ein API-Detail. Am 14. April 2026 stellte GitHub den Export technisch auf einen asynchronen Ablauf um. Am 12. Mai 2026 folgte dann die klare Ansage: Der alte synchrone Endpoint ist veraltet und wird am 13. November 2026 entfernt. Auf den ersten Blick klingt das nach normaler API-Pflege. Für Teams, die SBOMs in CI, Nachweisstrecken, Freigaben oder Security-Automation eingebaut haben, ist der Schritt aber größer. Denn er entlarvt einen Fehler, der in vielen internen Skripten steckt: Sie behandeln einen Lieferkettennachweis so, als müsse er sofort fertig sein.
Für Leser ohne tiefen GitHub- oder Supply-Chain-Kontext: GitHub erzeugt SBOMs aus dem Dependency Graph eines Repositories. Dabei wird der aktuelle Stand der bekannten Paket- und Abhängigkeitsbeziehungen als SPDX-JSON exportiert. Das hilft nicht nur Security-Teams, sondern auch Plattform-, DevOps- und Audit-Verantwortlichen, weil sich damit nachvollziehen lässt, was in einer Codebasis steckt und welche externe Software im Spiel ist.
Warum GitHub den Ablauf überhaupt geändert hat
GitHub beschreibt den Kern des Problems erstaunlich offen. Der frühere REST-Pfad /repos/{owner}/{repo}/dependency-graph/sbom lief mit einem fest eingebauten Timeout von zehn Sekunden. Für kleine Repositories war das oft genug. Für größere Codebasen mit komplexeren Abhängigkeitsbäumen aber nicht zuverlässig. Dazu kam ein zweites Problem: Wiederholte Anfragen starteten mehrere voneinander unabhängige Hintergrundprozesse, ohne Garantie, dass davon am Ende einer sauber den gewünschten Export liefert. Genau diese Art von Verhalten ist in Compliance- oder Incident-Situationen gefährlich. Ein Nachweis, der manchmal rechtzeitig kommt und manchmal nicht, ist kein belastbarer Prozess.
Der neue Ablauf trennt das deshalb sauber auf. Zuerst wird per generate-report ein Export angefordert. GitHub liefert darauf nicht direkt die fertige Datei zurück, sondern eine eindeutige Abruf-URL für diesen Job. Danach muss das aufrufende System den Status über fetch-report abfragen, bis der Report fertig ist. Laut GitHub kommt dabei solange ein Verarbeitungsstatus zurück, bis der fertige SBOM-Export per Redirect zum Download bereitsteht. Zusätzlich weist die Dokumentation darauf hin, dass der generierte Report bis zu eine Woche vorgehalten werden kann. Das ist kein kosmetischer Unterschied. Es verschiebt die Verantwortung vom „sofort fertig oder Fehler“ hin zu einem Job-Modell mit Polling, Wiederverwendung und explizitem Lebenszyklus.
Was in internen Automationen jetzt kaputtgehen kann
Viele Teams haben SBOM-Exporte nicht als eigenen, robusten Ablauf modelliert. Stattdessen hängen sie als kleiner Hilfsschritt in einem Shell-Skript, in einem Compliance-Job oder in einer Freigabepipeline. Dort gilt oft dieselbe Annahme: Ein HTTP-Request liefert sofort den Inhalt oder schlägt eben fehl. Mit der GitHub-Umstellung funktioniert dieses Denkmodell nicht mehr. Wer den alten Endpoint direkt aufruft, läuft in die Deprecation und später in den harten Bruch. Wer zwar auf den neuen Pfad wechselt, aber weiterhin nur eine Einmalanfrage ohne Polling baut, erzeugt denselben fachlichen Fehler in neuer Verpackung.
Operativ bedeutet das drei Dinge. Erstens muss der Export als asynchroner Job behandelt werden, nicht als synchroner Dateidownload. Zweitens braucht der aufrufende Prozess einen sauberen Umgang mit Wiederholungen, Wartefenstern und Abbruchbedingungen. Drittens müssen nachgelagerte Schritte verstehen, dass ein SBOM-Report ein eigener Artefaktstatus ist. Ein Freigabejob darf also nicht so tun, als läge die Datei schon vor, wenn tatsächlich erst der Generierungsauftrag bestätigt wurde. Genau an dieser Stelle scheitern viele Automationen nicht an SPDX oder an GitHub selbst, sondern an ihrer eigenen Zehn-Sekunden-Mentalität.
Warum das für ITSM, Audit und Freigaben relevant ist
Der Fall ist lehrreich, weil er ein bekanntes ITSM-Muster in die DevSecOps-Welt übersetzt. Ein Serviceprozess wird unzuverlässig, wenn sein Statusmodell zu grob ist. In klassischen Betriebsabläufen würde niemand einen Change gleichzeitig als „beantragt“, „genehmigt“ und „durchgeführt“ behandeln. Bei technischen Nachweisjobs passiert genau das aber ständig. Ein HTTP-200 wird schnell mit „Nachweis liegt vor“ verwechselt, obwohl eigentlich nur die Arbeit angenommen wurde.
Für Audit- und Governance-Sicht ist der Unterschied entscheidend. Wenn ein Kunde, ein interner Revisor oder ein Security-Incident kurzfristig einen SBOM-Nachweis verlangt, muss klar sein, wo der Report entsteht, wie lange er typischerweise braucht, wer auf das Ergebnis wartet und wann ein Fehler wirklich ein Fehler ist. GitHubs neue API erzwingt genau dieses sauberere Denken. Teams müssen explizit modellieren, ob ein Report angefordert, noch in Bearbeitung, fertig abrufbar oder tatsächlich fehlgeschlagen ist. Das ist kein unnötiger Formalismus, sondern die Voraussetzung dafür, dass Nachweise in hektischen Situationen nicht auseinanderfallen.
Wie ein sauberer Umstieg aussehen sollte
Pragmatisch betrachtet ist jetzt nicht die Zeit für hektische Einmal-Patches, sondern für einen kleinen Architekturcheck. Wer GitHub-SBOMs nutzt, sollte zuerst inventarisieren, wo der alte Endpoint überhaupt noch direkt aufgerufen wird: in CI-Skripten, internen Portalen, Compliance-Exporten oder Security-Bots. Danach gehört der Umstieg in einen klaren Ablauf. Der erste Schritt fordert den Report an und speichert die zurückgegebene Abruf-URL oder UUID. Der zweite Schritt pollt kontrolliert auf Fertigstellung. Der dritte Schritt behandelt den fertigen Download als eigenes Artefakt, das an Freigaben, Archivierung oder weitere Analysen übergeben wird.
Ebenso wichtig ist der Umgang mit Fristen. Die GitHub-Deprecation ist nicht abstrakt, sondern mit Datum versehen: 13. November 2026. Wer heute noch synchron denkt, hat damit einen klaren Endpunkt für den Altpfad. In größeren Organisationen lohnt es sich deshalb, die Änderung nicht nur an Entwicklerteams zu kommunizieren, sondern auch an Plattform-, Risiko- und Prozessverantwortliche. Denn sobald SBOM-Exports Teil formaler Nachweis- oder Freigabestrecken sind, ist der Umstieg kein reines Repo-Thema mehr, sondern ein Betriebsbaustein mit Schnittstellen in Audit, Security und Release Governance.
Unterm Strich zeigt GitHub hier etwas Grundsätzliches: Lieferkettennachweise scheitern oft nicht an fehlenden Standards, sondern an zu simplen Prozessannahmen. SPDX ist nicht das Problem. Das Problem beginnt dort, wo Unternehmen komplexe Nachweise behandeln wie einen kleinen Sofortdownload. Wer den neuen GitHub-Pfad richtig einbaut, gewinnt deshalb nicht nur API-Kompatibilität, sondern ein ehrlicheres Betriebsmodell für SBOMs.
