Systeme, die sich selbst warten: messen, korrigieren, aktualisieren, freigeben

Die meisten Softwareprojekte enden mit einer Übergabe. Ab dann altert das System: Abhängigkeiten bekommen Sicherheitslücken, Messwerte driften, und Fehler fallen erst auf, wenn ein Kunde sie meldet.

Selbstwartung heißt nicht, dass ein System unbeaufsichtigt an sich selbst arbeitet. Es heißt, dass die Arbeit der Wartung vorbereitet ist, bevor ein Mensch sie anstoßen muss, und dass die Entscheidung bei Ihnen bleibt.

Health Checks, Telemetrie und Evaluation zeigen laufend, ob das System tut, was es soll. Gemessen werden Latenz, Fehler und Kosten und bei einem Assistenten auch die Qualität der Antworten: Sind sie belegt, und lehnt er dort ab, wo er ablehnen soll? Ein offener Standard wie OpenTelemetry hält die Messdaten unabhängig von einem einzelnen Werkzeug.

Weicht ein Messwert ab oder meldet ein Scan einen Sicherheitsbefund, startet eine kontrollierte Korrektur. Sie durchläuft dieselben Tests und Sicherheitsprüfungen wie jede andere Änderung. Schlägt etwas fehl, geht das System auf den letzten guten Stand zurück.

Das setzt Tests voraus, die wirklich prüfen. Eine Testsuite kann vollständig grün sein, während einzelne Tests nichts prüfen. Mutationstests brechen den Code absichtlich und zeigen, ob der zuständige Test anschlägt.

Abhängigkeiten und Container werden laufend geprüft. Grundlage ist eine Stückliste der Software (SBOM), etwa im Format CycloneDX, die festhält, welche Komponenten in welcher Version enthalten sind. Gegen sie werden neu bekannt gewordene Schwachstellen abgeglichen; Container- und Secret-Scanning ergänzen das.

Wird eine Lücke bekannt, wird das Update automatisch vorbereitet und getestet. Ob es eingespielt wird, entscheiden Sie.

Jede Änderung wartet mit nachvollziehbarem Nachweis auf Ihre Freigabe: was sich ändert, welche Prüfungen bestanden sind und wie die Änderung zurückgenommen wird. Automatisch vorbereitet, von Ihnen freigegeben.

Die Freigabe ist kein Formalismus. Sie hält die Verantwortung dort, wo sie hingehört, und macht jede Änderung im Nachhinein nachvollziehbar.

Dieses Vorgehen deckt sich mit anerkannten Empfehlungen für sichere Softwareentwicklung, etwa dem Secure Software Development Framework des NIST (SP 800-218), und mit der Erwartung, Schwachstellen über den ganzen Lebenszyklus eines Produkts zu behandeln. Für Produkte mit digitalen Elementen schreibt die EU-Verordnung über Cyberresilienz (Verordnung (EU) 2024/2847) das künftig ausdrücklich vor.