Gestern war’s noch sicher, oder?

Security als Zeitpunkt gedacht

Wenn ein Team ein eigenes Produkt betreibt, taucht früher oder später ein bestimmtes Muster auf. Sicherheit wird wie ein Zeitpunkt behandelt, an dem man einmal hinschaut und dann weiterarbeitet. Geprüft wird beim Release, beim Einbau eines neuen Features oder wenn jemand bewusst etwas ändert. Dazwischen gilt das System als sicher, weil sich ja nichts bewegt hat.

Diese Sicht wirkt logisch, weil sich Risiko für uns nach Veränderung anfühlt. Solange niemand Code anfasst, scheint auch nichts passieren zu können. Genau an dieser Stelle führt uns die Intuition in die Irre, denn Sicherheit hängt nicht nur davon ab, was wir zuletzt geändert haben.

Nicht der Code bewegt sich, das Wissen

Ein großer Teil der Risiken entsteht nicht dadurch, dass heute neuer Code geschrieben wird, sondern dadurch, dass sich unser Wissen über längst ausgelieferte Abhängigkeiten verändert. Der Code auf dem Server liegt still, während die Wissenslage über ihn weiterläuft. Was gestern noch unauffällig aussah, ist heute ein dokumentiertes Finding, und was heute niemand kennt, wird irgendwann als CVE, Advisory oder ganze Exploit-Klasse sichtbar.

Damit verschiebt sich die eigentliche Frage. Sie lautet nicht, ob wir seit dem letzten Release etwas geändert haben, sondern ob unser Bild von den eingesetzten Bibliotheken noch dem entspricht, was inzwischen öffentlich über sie bekannt ist. Dieser Abstand wächst von allein, auch wenn niemand am Code arbeitet.

Eine Zeitreise durch drei Lockfiles

Um das greifbar zu machen, habe ich eine kleine Security-Zeitreise für ein Node.js-Projekt gefahren. Ich habe mir die letzte `package-lock.json` aus drei aufeinanderfolgenden Jahren genommen, also die Stände von Ende 2023, Ende 2024 und Ende 2025, und diese Snapshots anschließend im Jahr 2026 mit `npm audit` gegen den heutigen Stand geprüft.

Der Trick dabei ist, dass sich an den alten Lockfiles nichts ändert. `npm audit` gleicht den festgeschriebenen Abhängigkeitsbaum gegen die aktuelle Advisory-Datenbank ab, sodass jede Prüfung dasselbe alte System betrachtet, nur mit dem Wissen von heute. Ich messe also nicht, wie sich der Code verändert hat, sondern wie sich unser Wissen über denselben Code verändert hat. Nebeneinandergestellt ergeben die drei Snapshots das folgende Bild.

Was die Zahlen wirklich sagen

Der interessante Teil ist nicht, dass die Zahlen zum jüngeren Snapshot hin kleiner werden, sondern was sie über unsere Wahrnehmung verraten. Der naheliegende Schluss wäre, dass ein System mit der Zeit unsicherer wird. Präziser ist das Gegenteil, denn die 73 Lücken im 2023er-Stand waren von Anfang an vorhanden. Es hat nur gedauert, bis sie entdeckt, reproduzierbar beschrieben und in einer Datenbank verwertbar gemacht wurden. Ein CVE ist deshalb seltener ein neues Problem als vielmehr eine neue Erkenntnis über eine alte Realität.

Sicherheit ist ein Attribut des Betriebs

Genau hier liegt der Haken an einer Sicherheitsarbeit, die nur beim Release ansetzt. Sie behandelt Sicherheit als Eigenschaft des Builds, obwohl sie mindestens genauso eine Eigenschaft des Betriebs ist. Wer ausschließlich beim Release prüft, misst nicht, ob das System sicher ist, sondern ob es mit dem damaligen Wissensstand unauffällig war. In Produktion läuft dasselbe System aber Tag für Tag gegen den Wissensstand von heute.

Das erklärt auch, warum sich Sicherheitsarbeit manchmal wie ein Fass ohne Boden anfühlt. Der Grund ist nicht, dass ständig neue Fehler entstehen, sondern dass ständig neue Wahrheiten über die vorhandenen sichtbar werden. Wer diesen Mechanismus akzeptiert, hört auf, sich über den nächsten Fund zu wundern, und richtet den Betrieb darauf ein.

Was das konkret heißt

Praktisch bedeutet das, Abhängigkeiten regelmäßig zu prüfen und zu aktualisieren, statt nur bei Releases, ein Auge auf die eingesetzten Versionen zu behalten und Updates als laufende Betriebsaufgabe zu verstehen und nicht als Projekt, das man einmal abschließt. Die letzte Zeile der Zeitreise ist kein Beweis, dass man je fertig ist, sondern nur, dass kontinuierliche Pflege den Snapshot nah am aktuellen Wissensstand hält.

Und genau dieser wachsende Abstand zwischen dem, was in den eigenen Abhängigkeiten steckt, und dem, was inzwischen darüber bekannt ist, ist das, was Security Debt in der Praxis bedeutet. Er häuft sich leise an, solange niemand hinschaut, und schrumpft nur, wenn man ihn regelmäßig abträgt.

Wenn du für dein eigenes Produkt einmal ehrlich einordnen möchtest, wie groß dieser Abstand gerade ist, hilft ein strukturierter Blick von außen. Genau dafür gibt es unser kostenloses, anonymes Security Self-Assessment auf secure-vibe-coding.de, das dir zeigt, wo du stehst und welche Schritte sich als Nächstes lohnen.