Bildquelle: extern
Ein Softwareupdate sieht im IT-Alltag oft wie ein normaler Arbeitsschritt aus: Paket einspielen, Test prüfen, Störung vermeiden. Heikel wird es, wenn später niemand mehr sauber erklären kann, aus welcher Quelle dieses Paket stammt, welcher Build es erzeugt hat und welche Freigabe es wirklich durchlaufen hat.
Software Supply Chain bedeutet die Lieferkette einer Software: Quellcode, Bibliotheken, Build-Systeme, Paketregister, Signaturen, Freigaben und Auslieferung. Sie ist für ITSM-Generalisten wichtig, weil ein Update nicht nur eine technische Datei ist, sondern ein Betriebsereignis mit Risiko, Zuständigkeit und Nachweispflicht. Frameworks wie das NIST Secure Software Development Framework und SLSA beschreiben deshalb, wie Software nachvollziehbarer gebaut und ausgeliefert werden kann. Im Alltag geht es aber zuerst um eine einfache Frage: Kann der Betrieb belegen, woher ein Update kommt?
Der Download ist nicht der Nachweis
Ein Paket aus einem bekannten Repository wirkt vertrauenswürdig. Das reicht aber nicht. Ein Repository kann falsch befüllt werden, ein Build kann auf einem unsauberen Runner entstehen, ein Token kann zu breit berechtigt sein oder eine manuelle Ausnahme kann den eigentlichen Freigabeweg umgehen. Für den Betrieb zählt deshalb nicht nur, wo eine Datei liegt, sondern wie sie dorthin gekommen ist.
Der praktische Nachweis beginnt bei drei Punkten: Quelle, Build und Freigabe. Die Quelle zeigt, aus welchem Code und welchen Abhängigkeiten das Paket entstanden ist. Der Build zeigt, welches System daraus ein Artefakt gebaut hat. Die Freigabe zeigt, welche Prüfung vor der Auslieferung stattfand. Fehlt einer dieser Punkte, bleibt im Störungs- oder Sicherheitsfall eine Lücke. Dann kann niemand sicher sagen, ob ein Update wirklich dem erwarteten Stand entspricht.
Nachvollziehbarkeit muss vor der Störung geklärt sein
In ruhigen Zeiten wirkt diese Nachweisarbeit oft übertrieben. Im Ernstfall wird sie sehr konkret. Wenn ein Hersteller ein kompromittiertes Paket meldet, eine Schwachstelle in einer Bibliothek auftaucht oder ein Rollback nötig wird, braucht der Service Desk schnelle Antworten. Welche Version läuft auf welchem Service? Wurde sie aus dem offiziellen Build erzeugt? Welche Abhängigkeit steckt darin? Wer hat die Freigabe erteilt? Welche Systeme haben das Paket bereits übernommen?
Ohne diese Antworten entsteht ein Suchlauf zwischen Entwicklung, Plattformteam, Security, Betrieb und Fachbereich. Das kostet Zeit und schwächt Entscheidungen. Der Betrieb kann dann nicht sauber priorisieren, ob ein Update sofort gestoppt, zurückgerollt oder kontrolliert weitergeführt werden sollte. Nachvollziehbarkeit ist deshalb kein Spezialthema für Entwickler. Sie ist ein Teil der Betriebsfähigkeit.
Softwarelisten helfen nur mit Betriebsbezug
Eine Software Bill of Materials, kurz SBOM, listet Bestandteile einer Software auf. Sie kann helfen, betroffene Bibliotheken schneller zu finden. Für den ITSM-Alltag reicht eine reine Liste aber nicht. Entscheidend ist, ob die Liste einem konkreten Service, einer produktiven Version und einem verantwortlichen Team zugeordnet werden kann.
Eine SBOM ohne Servicebezug beantwortet zwar, was theoretisch in einem Paket steckt. Sie beantwortet aber nicht, welche Anwendung im Unternehmen wirklich betroffen ist, ob eine Version produktiv läuft, welcher Kunde oder Fachbereich berührt ist und wer den Change verantwortet. Darum sollten Softwarelisten mit CMDB, Servicekatalog, Release-Dokumentation oder einer anderen verlässlichen Betriebsübersicht verbunden werden. Erst dann wird aus technischer Transparenz eine nutzbare Entscheidungsgrundlage.
Signaturen ersetzen keine Freigabe
Digitale Signaturen sind wichtig. Sie können zeigen, dass ein Paket seit der Signatur nicht verändert wurde und von einem bestimmten Schlüssel stammt. Sie beweisen aber nicht automatisch, dass der Inhalt fachlich korrekt, sicher geprüft und betrieblich freigegeben ist. Ein sauber signiertes falsches Paket bleibt ein Problem.
Darum braucht der Betrieb klare Rollen. Wer darf Builds signieren? Wer verwaltet Schlüssel? Wer prüft Ausnahmen? Wer darf ein Paket trotz Warnung freigeben? Wer dokumentiert, warum eine Version zurückgezogen wurde? Diese Fragen sollten nicht erst gestellt werden, wenn ein Sicherheitsvorfall läuft. Sie gehören in den normalen Release- und Change-Prozess.
Der wichtigste Kontrollpunkt liegt im Übergang
Besonders riskant ist der Moment, in dem aus einem Build ein produktives Update wird. Dort treffen Entwicklung, Automatisierung, Paketregister, Deployment und Betrieb zusammen. Genau an dieser Stelle sollten Teams prüfen, ob Nachweise mitwandern. Ein Artefakt sollte nicht nur ausgeliefert werden, sondern seine Herkunft, Version, Prüfergebnisse und Freigabeinformationen nachvollziehbar mitbringen.
Für ITSM-Verantwortliche muss das nicht bedeuten, jede Pipeline technisch zu administrieren. Es bedeutet, Mindestfragen in den Prozess einzubauen. Welche Artefakte dürfen produktiv werden? Welche Nachweise müssen vorliegen? Wie wird ein Notfallupdate nachträglich dokumentiert? Wo sieht der Service Owner, welche Version wirklich läuft? Wie wird verhindert, dass ein manuell hochgeladenes Paket denselben Vertrauensstatus erhält wie ein geprüfter Build?
Eine einfache Prüfliste reicht als Start
Der Einstieg kann pragmatisch sein. Für kritische Services sollte jedes produktive Update mindestens eine Quelle, eine Build-ID, eine Paketversion, eine Freigabe, eine verantwortliche Rolle und einen Rückweg haben. Zusätzlich sollte klar sein, wo Abhängigkeiten dokumentiert sind und wie der Service Desk im Vorfall an diese Informationen kommt.
Diese Liste ist kein Ersatz für ein vollständiges Supply-Chain-Programm. Sie verhindert aber, dass Nachvollziehbarkeit nur als Security-Projekt behandelt wird. Sobald Updates als Betriebsobjekte verstanden werden, werden Zuständigkeiten klarer. Der Service Desk fragt nicht nur nach der Versionsnummer, Security fragt nicht nur nach der Schwachstelle und Entwicklung spricht nicht nur über den Build. Alle sehen denselben Weg vom Code bis zum laufenden Service.
Die entscheidende Frage bleibt deshalb bewusst einfach: Woher kommt dieses Update wirklich? Wer sie vor dem Go-live beantworten kann, gewinnt im Ernstfall Zeit. Wer sie erst nach einem Vorfall stellt, sucht nicht nur eine Datei, sondern den ganzen Weg dorthin.
Quellen und Einordnung: NIST SP 800-218 Secure Software Development Framework, SLSA Specification 1.1, CISA Secure Software Development Attestation Form, OWASP Software Component Verification Standard. Stand der Quellenprüfung: 30.06.2026.
