Vom Fund zum Fix zum Beweis: Wie wir Sicherheitskorrekturen wirklich abschließen

„Ist behoben" ist schnell gesagt. Ob es stimmt, ist eine andere Frage. Bei einer aktuellen internen Sicherheitsüberprüfung eines unserer eigenen Tools sind wir mehrere Funde durchgegangen — vom Code-Review bis zum Live-Deploy. Der eigentlich interessante Teil war aber nicht das Finden, sondern das Nachweisen: Woher wissen wir, dass ein Fix tatsächlich wirkt, und nicht nur gut aussieht?

Warum ein Fix ohne Beweis kein Fix ist

Eine Codezeile ändern ist der leichte Teil. Schwieriger ist die Frage: Verhält sich die Anwendung jetzt tatsächlich anders — und zwar genau so, wie es sein soll, ohne dass an anderer Stelle etwas kaputtgeht? Genau dafür braucht es Abschlusstests, die nicht nur prüfen „läuft die Seite noch", sondern gezielt das Vorher-Nachher des jeweiligen Problems nachstellen.

Schritt 1: Den Fehler zuerst nachstellen, dann erst reparieren

Bevor überhaupt etwas geändert wird, stellen wir das eigentliche Problem konkret nach — nicht in der Theorie, sondern als reproduzierbaren Testfall. Erst wenn klar ist, wie sich der Fehler tatsächlich zeigt, wird der Fix geschrieben. Danach läuft derselbe Testfall noch einmal — jetzt muss er anders ausfallen. Ohne dieses Vorher-Nachher weiß man nie, ob man das richtige Problem behoben hat oder nur zufällig etwas anderes verändert.

Schritt 2: Mit echten Daten testen, nicht nur mit Beispieldaten

Datenbankänderungen sind besonders tückisch — was mit einer leeren Testdatenbank funktioniert, kann an echten, gewachsenen Daten trotzdem scheitern. Deshalb testen wir strukturelle Änderungen grundsätzlich zuerst gegen eine Kopie der echten Daten: Bleiben alle bestehenden Einträge erhalten? Funktionieren neue Einträge danach noch korrekt? Erst wenn das zweifelsfrei bestätigt ist, geht die Änderung auf das Live-System.

Schritt 3: Nach dem Deploy nicht dem Code vertrauen, sondern der Antwort des Servers

Der letzte Schritt ist der wichtigste und wird am häufigsten übersprungen: nach dem Ausrollen tatsächlich gegen das Live-System prüfen, nicht nur gegen die lokale Kopie. Ein Konfigurationswert, der im Code richtig aussieht, kann durch eine vergessene Umgebungsvariable oder einen nicht neu gestarteten Dienst trotzdem folgenlos bleiben. Deshalb schauen wir uns nach jedem sicherheitsrelevanten Deploy die tatsächliche Antwort des Servers an — nicht die Annahme, sondern die Messung.

Was das in der Praxis bedeutet

Ein paar Beispiele aus der aktuellen Überprüfung, ohne ins technische Detail zu gehen: Bei einer Zugangsdaten-Änderung haben wir sowohl geprüft, dass der alte Zugang jetzt abgelehnt wird, als auch, dass der neue funktioniert — beides zu bestätigen ist wichtiger als nur eines von beidem. Bei einer Absicherung rund um Datei-Anhänge haben wir denselben Testfall, der vorher noch durchgekommen wäre, nach dem Fix erneut versucht — und die Ablehnung tatsächlich am System beobachtet, nicht nur im Code erwartet. Bei einer Änderung an der Absicherung von Anmelde-Sitzungen haben wir die Antwort des Servers direkt eingesehen, um zu sehen, welche Schutzmerkmale tatsächlich gesetzt werden — nicht nur, welche Zeile das im Code tun sollte.

Der eigentliche Punkt

„Wir haben das behoben" ist eine Behauptung. Ein nachvollziehbarer Test davor und danach, dokumentiert und gegen das echte System verifiziert, ist ein Beweis. Der Unterschied klingt klein, ist es aber nicht — gerade wenn es um Zugriffsschutz, Zugangsdaten oder Datenintegrität geht, wollen wir nicht „vermutlich richtig", sondern nachweisbar richtig arbeiten. Das ist der Maßstab, den wir auch an Kundenprojekte anlegen.