Bildquelle: extern
Software braucht Herkunftsnachweise, sonst bleibt die Lieferkette blind
Grundlagen für ITSM- und IT-Management-Generalisten: Eine Software-Lieferkette umfasst alle Schritte, über die Code, Abhängigkeiten, Build-Systeme, Artefakte und Deployment-Pfade vom Entwicklerarbeitsplatz bis in den Betrieb gelangen. Ein Herkunftsnachweis, oft als Provenance bezeichnet, dokumentiert nachvollziehbar, welches Artefakt aus welchem Quellstand, mit welchem Workflow und unter welchen Bedingungen gebaut wurde. SLSA ist ein offenes Sicherheitsframework, das solche Lieferketten schrittweise gegen Manipulation, unklare Builds und schwache Nachweise absichern soll.
Der gefährliche Moment in einer Software-Lieferkette sieht selten dramatisch aus. Ein Container-Image liegt im Registry, ein Paket ist gebaut, eine Pipeline meldet grün, ein Release-Ticket wartet auf Freigabe. Für den Betrieb wirkt das zunächst wie ein normaler Übergang von Entwicklung zu Produktion. Genau dort entsteht aber ein blinder Fleck: Wenn niemand belegen kann, wie dieses Artefakt entstanden ist, wer den Build ausgelöst hat, welche Quelle verwendet wurde und ob der Weg manipulationsgeschützt war, hängt die Service-Freigabe an Vertrauen statt an Nachweis.
Für ITSM-Verantwortliche ist das keine reine Security-Spezialfrage. Ein Incident, der durch ein manipuliertes Paket, eine unklare Abhängigkeit oder einen nicht reproduzierbaren Build ausgelöst wird, landet schnell im normalen Betriebsprozess. Dann fragt das Management nicht nach schönen Pipeline-Dashboards, sondern nach Verantwortlichkeiten, Rückverfolgbarkeit und Wiederanlauf. Wer an diesem Punkt nur sagen kann, dass der Build erfolgreich war, hat das eigentliche Risiko nicht gesteuert. Erfolgreich gebaut ist nicht dasselbe wie nachweisbar sauber gebaut.
Warum Provenance mehr ist als ein Zusatzfeld im Release
Provenance bedeutet im Softwarekontext: Der Ursprung und die Entstehung eines Artefakts werden maschinenlesbar und prüfbar dokumentiert. Dazu gehören typischerweise der Quellcode-Stand, der Build-Workflow, die Build-Umgebung, Zeitpunkte, Identitäten und Signaturen. GitHub beschreibt Artifact Attestations beispielsweise als Möglichkeit, für erzeugte Artefakte kryptografisch signierte Nachweise zu erstellen. SLSA ordnet diesen Gedanken in ein Reifemodell ein: von einfachen, dokumentierten Builds bis zu stärker gehärteten, nachvollziehbaren und gegen Manipulation geschützten Lieferketten.
Der Punkt für Generalisten ist: Provenance ersetzt nicht das Change- oder Release-Management, sondern liefert ihm ein belastbareres Beweisstück. Ein CAB, ein Service Owner oder ein Plattformteam muss nicht jedes Detail eines Build-Systems verstehen, um die entscheidende Betriebsfrage zu stellen: Gibt es einen vertrauenswürdigen Nachweis, dass dieses Artefakt aus dem freigegebenen Quellstand stammt und nicht unterwegs verändert wurde? Ohne diesen Nachweis bleibt jede Freigabe eine Plausibilitätsentscheidung.
Die Schwachstelle liegt oft zwischen Plattform und Prozess
In der Praxis entstehen Lieferkettenrisiken selten nur durch einen einzelnen Fehler. Häufig treffen mehrere Lücken aufeinander: Build-Jobs laufen mit zu breiten Berechtigungen, manuelle Artefakt-Uploads umgehen die Pipeline, Secrets liegen an zu vielen Stellen, externe Abhängigkeiten werden nicht sauber bewertet, und Release-Freigaben sehen nur ein Ticket, aber keine technischen Nachweise. Für das Plattformteam ist jeder Einzelpunkt erklärbar. Für den Servicebetrieb entsteht daraus aber ein System ohne klare Belegkette.
Genau deshalb sollte Software Supply Chain Security nicht als isoliertes Spezialprogramm neben ITSM laufen. Sie gehört in die Schnittstellen von Change Enablement, Release Management, Configuration Management, Risikoanalyse und Supplier-Steuerung. Wenn eine Organisation Software selbst baut, einkauft oder über Dienstleister betreiben lässt, muss sie wissen, welche Artefakte produktiv werden dürfen und welche Nachweise dafür erforderlich sind. Das gilt für interne Plattformen genauso wie für SaaS-Erweiterungen, Container-Images oder Automatisierungsskripte.
SLSA hilft als Gesprächsrahmen, nicht als magischer Schutzschild
SLSA, ausgeschrieben Supply-chain Levels for Software Artifacts, ist nützlich, weil es die Diskussion aus dem Bauchgefühl holt. Statt allgemein zu fordern, dass Pipelines sicher sein sollen, fragt das Framework nach konkreten Eigenschaften: Wird der Build durch ein kontrolliertes System erzeugt? Ist die Herkunft nachvollziehbar? Werden Nachweise erzeugt? Sind Manipulationen am Build-Pfad erschwert? Diese Fragen lassen sich in Anforderungen, Kontrollen und Betriebsroutinen übersetzen.
Trotzdem wäre es falsch, SLSA als Zertifikat-Ersatz oder reines Tool-Label zu behandeln. Ein hoher Reifegrad auf Papier hilft wenig, wenn Service Owner nicht wissen, welche Nachweise sie vor einem kritischen Release erwarten dürfen. Ebenso wenig reicht ein Attestation-Feature in der Entwicklungsplattform, wenn niemand prüft, ob die Nachweise im Freigabeprozess auftauchen, archiviert werden und im Incident-Fall auffindbar sind. Entscheidend ist die Verbindung aus technischer Signatur, Prozessentscheidung und operativer Nachvollziehbarkeit.
Was ITSM-Teams jetzt konkret klären sollten
Erstens braucht jede produktionsnahe Plattform eine klare Regel, welche Artefakte ohne Provenance nicht mehr akzeptiert werden. Das kann schrittweise beginnen, etwa bei besonders kritischen Services, Images mit Internet-Exposition oder Komponenten mit regulatorischer Relevanz. Wichtig ist, dass die Regel nicht als Entwicklerbürokratie formuliert wird, sondern als Betriebsanforderung: Ohne Herkunftsnachweis kein kontrollierter Produktivpfad.
Zweitens müssen Verantwortlichkeiten sauber getrennt werden. Plattformteams können technische Attestations erzeugen und Verifikationspunkte in Pipelines einbauen. Security kann Anforderungen an Signaturen, Schlüssel, Abhängigkeiten und Policies definieren. ITSM und IT-Management müssen aber festlegen, an welcher Stelle ein fehlender Nachweis ein Release stoppt, eskaliert oder nur mit dokumentierter Ausnahme erlaubt wird. Diese Entscheidung gehört nicht in ein einzelnes Build-Skript.
Drittens sollte die Organisation den Incident-Fall rückwärts denken. Wenn morgen ein Paket als verdächtig gilt, muss schnell sichtbar sein, welche Services betroffen sind, welche Versionen produktiv laufen, aus welchem Build sie stammen und ob ein verifizierter Nachweis vorliegt. Damit wird Provenance zu einem Asset- und Configuration-Thema. Ohne Verbindung zu CMDB, Service-Katalog oder mindestens zu einer belastbaren Artefaktinventur bleibt der Nachweis im Ernstfall zu weit weg vom Betrieb.
Viertens gehört der Lieferantenblick dazu. Bei externer Software reicht die Frage nach einem SBOM oder einem Sicherheitsfragebogen allein nicht mehr. Interessanter wird, ob ein Anbieter nachvollziehbare Build- und Signaturprozesse besitzt, wie er Artefakte veröffentlicht, wie Updates geprüft werden und welche Nachweise Kunden im Audit oder Incident bekommen. Das verschiebt Provider Management weg von allgemeinen Zusicherungen hin zu überprüfbaren Lieferkettenfähigkeiten.
Der Betriebsnutzen liegt in besseren Entscheidungen
Der größte Wert von Herkunftsnachweisen besteht nicht darin, jedes Risiko zu verhindern. Der Wert liegt darin, dass Entscheidungen weniger blind werden. Ein Release kann schneller freigegeben werden, wenn die Herkunft maschinenlesbar belegt ist. Ein verdächtiges Artefakt kann gezielter isoliert werden, wenn seine Entstehung nachvollziehbar ist. Eine Ausnahme kann bewusster akzeptiert werden, wenn klar dokumentiert ist, welcher Nachweis fehlt und wer das Risiko trägt.
Für ITSM-Generalisten ist das die entscheidende Einordnung: Software Supply Chain Security ist kein Randthema der Entwicklungsabteilung. Sie verändert, was eine saubere Freigabe, ein belastbarer Rollback, ein auditierbarer Provider-Nachweis und ein guter Incident-Start bedeuten. Wer nur auf erfolgreiche Builds schaut, sieht den grünen Haken. Wer auf Herkunftsnachweise schaut, sieht, ob dieser Haken im Betrieb wirklich etwas wert ist.
Die nächste Reifestufe besteht deshalb nicht darin, überall sofort perfekte Lieferketten zu versprechen. Sie besteht darin, die kritischen Pfade zu markieren, Provenance dort verbindlich zu machen und die Nachweise in Release-, Change- und Incident-Prozesse einzubauen. Dann wird aus einem technischen Sicherheitskonzept ein handhabbarer Betriebsstandard.
