Der riskanteste Softwarelieferant ist der ohne sichtbaren Updateweg

Ein neuer Softwarelieferant wirkt im Einkauf oft sauber geprüft. Vertrag, Datenschutz, Preis und Funktionsumfang sind geklärt. Für den IT-Betrieb beginnt die eigentliche Risikofrage aber später: Wer sagt zuverlässig, wann eine kritische Schwachstelle vorliegt? Wie kommt ein Update kontrolliert in die Umgebung? Wer entscheidet, ob ein Patch sofort, geplant oder gar nicht eingespielt wird? Ohne diesen sichtbaren Updateweg wird selbst ein seriöser Anbieter zum Betriebsrisiko.

Kurz gesagt Softwarelieferkette bedeutet, dass ein IT-Service von Komponenten, Bibliotheken, Cloud-Diensten, Herstellern und Updatekanälen abhängt, die außerhalb des eigenen Betriebs entstehen. Ein Updateweg beschreibt, wie Informationen über Fehler und Sicherheitslücken in eine Organisation gelangen und wie daraus eine kontrollierte Änderung wird. Für ITSM-Generalisten ist das relevant, weil Ausfälle, Notfalländerungen und Service-Desk-Anfragen oft nicht am Produkt selbst hängen, sondern an unklaren Zuständigkeiten rund um Updates.

Die Europäische Kommission beschreibt den Cyber Resilience Act als Regelwerk für Produkte mit digitalen Elementen. Es soll dafür sorgen, dass Hersteller Cybersicherheitsanforderungen über den Lebenszyklus ihrer Produkte stärker berücksichtigen. NIST beschreibt im Secure Software Development Framework sichere Entwicklungspraktiken von der Vorbereitung über Schutzmaßnahmen bis zur Reaktion auf Schwachstellen. CISA fordert mit Secure by Design, dass Hersteller Sicherheitsverantwortung stärker in Produkte und Prozesse einbauen. Der CISA-Prozess zur koordinierten Schwachstellenmeldung zeigt außerdem, warum klare Melde- und Abstimmungswege wichtig sind. Für den Betrieb entsteht daraus eine einfache Leitfrage: Ist der Lieferant nur beschafft, oder ist er wirklich in die Betriebssteuerung eingebunden?

Beschaffung prüft Anbieter, Betrieb prüft Wege

Eine Lieferantenprüfung beantwortet häufig die Frage, ob ein Anbieter grundsätzlich geeignet ist. Der Betrieb braucht eine andere Antwort. Er muss wissen, wie sich dieser Anbieter im Alltag verhält, wenn etwas Dringendes passiert. Gibt es ein Sicherheitsportal? Gibt es feste Ansprechpartner? Werden Updates angekündigt, dokumentiert und klassifiziert? Ist erkennbar, welche Version betroffen ist? Gibt es einen Weg für Rückfragen, bevor ein kritischer Patch in produktive Systeme läuft?

Fehlt diese Ebene, entsteht eine gefährliche Lücke zwischen Governance und Realität. Auf dem Papier ist der Lieferant freigegeben. Im Störungsfall sucht der Service Desk aber in alten E-Mails, das Plattformteam wartet auf eine Herstellerantwort, Security drängt auf Tempo und Fachbereiche fragen nach Auswirkungen. Genau dann zeigt sich, ob ein Updateweg betrieblich tragfähig ist.

Ein Update ist erst dann beherrschbar, wenn der Servicebezug klar ist

Nicht jedes Update hat dieselbe Bedeutung. Ein Patch für ein internes Berichtswerkzeug braucht eine andere Behandlung als ein Sicherheitsupdate für ein System, das Kundenzugänge absichert. Deshalb reicht eine technische Versionsmeldung nicht aus. Der Betrieb muss den betroffenen Service, die Nutzerwirkung, die Kritikalität, mögliche Abhängigkeiten und ein Rückfallverfahren kennen.

Das klingt nach zusätzlicher Verwaltung, spart aber im Ernstfall Zeit. Wenn ein Herstellerhinweis direkt mit Servicekatalog, Verantwortlichen, Wartungsfenster und Change-Praxis verbunden ist, wird aus einer Warnung eine handhabbare Entscheidung. Ohne diese Verbindung landet dieselbe Warnung als unklare Aufgabe bei mehreren Teams. Dann entstehen Doppelarbeit, Verzögerung und manchmal widersprüchliche Maßnahmen.

Sicherheitslücken brauchen eine Betriebsübersetzung

Schwachstellenmeldungen sind oft technisch formuliert. Sie sprechen über betroffene Versionen, Angriffswege, Schweregrade oder mögliche Ausnutzung. Für den Betrieb ist das nur der Anfang. Die entscheidende Übersetzung lautet: Welche unserer Services nutzen die betroffene Komponente? Gibt es erreichbare Systeme? Gibt es Kompensationsmaßnahmen? Welche Frist ist angemessen? Welche Kommunikation braucht der Service Desk?

Diese Übersetzung sollte nicht jedes Mal improvisiert werden. Ein guter Lieferantenprozess legt fest, wer Herstellerhinweise bewertet, welche Informationsquellen verbindlich sind, welche Änderungsklasse greift und welche Eskalation bei kritischen Fällen ausgelöst wird. Dadurch wird aus Security-Druck kein unkontrollierter Aktionismus, sondern eine nachvollziehbare Betriebsentscheidung.

Der Service Desk darf nicht erst vom Nutzer lernen

Wenn ein Update zu Problemen führt, merkt der Service Desk die Folgen oft zuerst. Anrufe häufen sich, bekannte Funktionen ändern sich oder ein Cloud-Dienst reagiert anders als erwartet. Schlecht ist, wenn der Service Desk erst durch diese Meldungen erfährt, dass ein Herstellerupdate gelaufen ist. Dann fehlt Kontext, und jede Anfrage kostet unnötig Zeit.

Besser ist ein kurzer Vorlauf. Welche Änderung kommt? Welche Symptome wären plausibel? Was ist die offizielle Auskunft? Welcher Workaround ist erlaubt? Welche Informationen sollen an die zweite Supportstufe gehen? Diese Fragen müssen nicht jedes Update aufblähen. Sie sorgen aber dafür, dass der Kontakt mit Nutzern nicht vom Zufall abhängt.

Auch Herstellerautomatik braucht Grenzen

Automatische Updates können sinnvoll sein, besonders bei Cloud-Diensten oder verwalteten Produkten. Sie dürfen aber nicht bedeuten, dass der Betrieb die Kontrolle über Wirkung und Kommunikation verliert. Entscheidend ist, welche Updatearten automatisch laufen dürfen, welche vorab angekündigt werden müssen und welche Änderungen eine bewusste Freigabe brauchen.

Ein risikobasierter Ansatz hilft. Geringe Korrekturen können schnell und automatisiert durchlaufen. Änderungen an Zugängen, Schnittstellen, Datenflüssen oder kritischen Funktionen brauchen mehr Sichtbarkeit. Der Punkt ist nicht, jedes Update schwerfällig zu machen. Der Punkt ist, die wenigen wirklich betriebsrelevanten Änderungen rechtzeitig zu erkennen.

Was in die Lieferantenakte gehört

Eine praxistaugliche Lieferantenakte für den Betrieb enthält mehr als Vertragsdaten. Sie sollte Updatekanal, Sicherheitskontakt, Meldewege, betroffene Services, genutzte Versionen, Fristen für kritische Hinweise, Zuständigkeiten, Rückfalloptionen und Kommunikationsbausteine enthalten. Wichtig ist außerdem, wann diese Informationen zuletzt geprüft wurden. Veraltete Kontaktdaten sind im Ernstfall fast so schlecht wie keine Kontaktdaten.

Diese Akte muss nicht als neues Mammuttool entstehen. Oft reicht ein klar gepflegter Datensatz im Servicekatalog oder in der Configuration-Management-Praxis. Entscheidend ist, dass Service Desk, Betrieb, Security und Change-Verantwortliche dieselbe Sicht auf den Lieferanten haben. Nur dann wird die Lieferkette wirklich steuerbar.

Die bessere Prüffrage für den nächsten Anbieter

Vor der nächsten Freigabe sollte nicht nur gefragt werden, ob ein Produkt fachlich passt. Die stärkere Betriebsfrage lautet: Können wir einen kritischen Herstellerhinweis innerhalb eines Arbeitstages einem Service, einer Entscheidung und einer Kommunikation zuordnen? Wenn diese Antwort unklar bleibt, ist der Lieferant noch nicht betriebsreif eingebunden.

Softwarelieferanten werden nicht automatisch riskant, weil sie extern sind. Riskant werden sie, wenn ihre Änderungen, Hinweise und Verantwortlichkeiten im eigenen Betrieb unsichtbar bleiben. Ein guter Updateweg macht aus einem externen Produkt einen steuerbaren Bestandteil des Servicebetriebs. Genau dort entscheidet sich, ob Lieferkettenmanagement im Alltag hilft oder nur eine weitere Akte bleibt.

Stand der Quellenprüfung: 21.06.2026. Der Beitrag enthält keine konkreten Beträge oder Leistungssätze.