Ihr Schwachstellen-Backlog ist keine technische Schuld mehr, sondern eine Angriffsfläche

Jedes Security-Programm hat eine: eine Warteschlange mit einigen Tausend oder einigen Hunderttausend Findings, die niemand bearbeitet hat und von denen niemand erwartet, dass sie bearbeitet werden. Die meisten Teams verbuchen sie als technische Schulden – Kosten, die bewusst getragen und abgebaut werden, sobald dafür Kapazitäten frei sind, und die tolerierbar bleiben, solange der Zinssatz niedrig ist.

Diese Rechnung ging lange auf, weil sie auf einer einzigen Annahme beruhte: Fast nichts in der Warteschlange würde jemals von jemandem erreicht oder ausgenutzt werden. So vernünftig diese Annahme als technische Entscheidung auch war, sie ist zum schwächsten Teil des Modells geworden.

Der Backlog war eine Wette

Entwickler sind Security-Fachkräften zahlenmäßig überlegen, seit es beide Funktionen gibt. Unter dieser Bedingung war Triage die richtige und, offen gesagt, einzige Entscheidung: Findings priorisieren, einen Schweregrad-Schwellenwert festlegen, die darüber liegenden Findings bearbeiten und den Rest akzeptieren.

Den Rest zu akzeptieren, war eine Wette auf die Wahrscheinlichkeit einer Ausnutzung – nämlich darauf, dass ein Angreifer dieses spezifische Problem mittleren Schweregrads in diesem spezifischen Service nicht finden würde, bevor sich der umgebende Code ohnehin änderte. Die Findings galten als real; die Wette bestand darin, dass sie unbearbeitet bleiben würden.

Programme nutzen weiterhin die Instrumente dieser Wette: das Risikoregister, SLA-Stufen, Status wie „wird nicht behoben“ und „Risiko akzeptiert“, Ausnahme- und Waiver-Workflows sowie Schweregradgrenzen, unterhalb derer überhaupt keine Triage stattfindet. Jedes dieser Instrumente existiert, weil eine Organisation einen rationalen Kompromiss eingegangen ist und dafür eine Infrastruktur brauchte, um ihn im großen Maßstab umzusetzen.

Drei Einflussfaktoren haben sich gleichzeitig verändert

Eine Wette ist nur so gut wie die Quoten, zu denen sie abgeschlossen wurde – und drei dieser Quoten haben sich verändert.

1. Code entsteht schneller als jeder Review-Rhythmus

Die Zahl der Codezeilen pro Entwickler ist um 218 % gestiegen, wobei 62 % dieses Codes fehlerhaft oder unsicher sind. Stand Juni 2026 zeigen die eigenen Produktdaten von Snyk ungefähr sechs neu eingeführte Schwachstellen pro behobener Schwachstelle – und agentische Entwicklung vergrößert dieses Verhältnis weiter.

Die Richtung ist wichtiger als die Zahl: Wenn der Zufluss sechsmal schneller wächst als der Abfluss, nimmt der akzeptierte Rest in jedem Sprint zu, ohne dass jemand bewusst beschließt, ihn zu vergrößern. Jeder Schwellenwert, jedes SLA und jedes Staffing-Modell im Programm wurde auf Grundlage einer anderen Zuflussrate dimensioniert – und keines davon wurde neu verhandelt, als sich die Rate änderte.

2. Der Code kommt ohne Autor, den man fragen kann

„Fragen Sie den Autor“ ist das älteste Instrument im Code-Review. Es hat kein Gegenstück, wenn der Autor ein Agent ist, denn niemand hat die Abhängigkeit ausgewählt, über das Muster nachgedacht oder kann erklären, welchem Zweck die Änderung diente.

Reviewer genehmigen heute Code, den sie nicht geschrieben haben und nicht hinterfragen können. Die Überlegungen, die früher eine Änderung begleiteten, müssen daher aus der Änderung selbst rekonstruiert werden. Findings, die früher durch ein zweiminütiges Gespräch erledigt gewesen wären, landen stattdessen in der Warteschlange – und erhöhen den Zufluss ein weiteres Mal, aus Gründen, die nichts mit dem Codevolumen zu tun haben.

3. Angreifer haben ihre Seite automatisiert

Die Wette auf die Wahrscheinlichkeit einer Ausnutzung basierte auf Aufklärung in menschlicher Geschwindigkeit: Das Absuchen einer großen Angriffsfläche kostete einen Angreifer viele Stunden und lieferte größtenteils Rauschen. Automatisierung hat diese Rechnung verändert. Eine große Angriffsfläche abzulaufen, jedes schwache Signal zu katalogisieren und Kombinationen zu testen, für die kein Analyst einen ganzen Nachmittag aufgewendet hätte, ist heute kostengünstig.

Die Konsequenz ist konkret – und ebenso die Reaktion darauf. Jeder Eintrag in Ihrem Register wurde nach den alten Quoten bewertet, und die meisten wurden seit dem Tag ihrer Akzeptanz nicht erneut geprüft. Damit ist die Neubewertung dieses Registers eine Aufgabe, deren Umfang Sie in diesem Quartal festlegen und für die Sie einen Zeitplan erstellen können.

Findings mit niedrigem Schweregrad verbinden sich zu Pfaden mit hohem Schweregrad

Der Schweregrad bewertet ein Finding isoliert, während Angriffe Findings miteinander kombinieren.

Betrachten Sie drei Einträge, die jeweils bequem unterhalb der Triage-Grenze liegen: eine unsichere direkte Objektreferenz, die eine interne Objekt-ID preisgibt, eine ausführliche Fehlermeldung, die bestätigt, wann eine geratene ID gültig ist, und eine veraltete Serialisierungsbibliothek mit einem bekannten Deserialisierungsproblem. Für sich genommen ist jedes davon die Art von Finding, die ein Programm akzeptiert und nie wieder überprüft. In einer Kette bilden sie einen authentifizierten Pfad zur Remote-Code-Ausführung.

Dieser Mechanismus macht aus einem Backlog eine Angriffsfläche. Die Warteschlange fungiert als Inventar von Komponenten, die ein Angreifer zusammenfügen kann – und genau diese Zusammenstellung wird von keinem Schweregradmodell bewertet.

Der praktische Schritt besteht darin, das Register als Beschreibung dessen zu lesen, womit ein Angreifer arbeiten kann. Fragen Sie, welche akzeptierten Findings im selben Service liegen, eine Vertrauensgrenze teilen oder dieselben Daten berühren. Denn dort befinden sich die Risikobereiche – und sie bleiben in jeder Ansicht unsichtbar, die nach Schweregrad sortiert.

Priorisierung ordnet die Warteschlange, verkürzt sie aber nicht

Die naheliegende Reaktion auf einen wachsenden Backlog ist eine bessere Rangfolge: präziser bewerten, Erreichbarkeit gewichten, nach Ausnutzbarkeit sortieren und die Findings an der Spitze der Liste mit größerer Sicherheit bearbeiten.

Eine bessere Rangfolge erzeugt eine besser geordnete Warteschlange derselben Länge. Sobald der Zufluss den Abfluss übersteigt, bestimmt die Rangfolge, welche Findings dauerhaft unbearbeitet bleiben. Damit wird Priorisierung zum Instrument, das akzeptierte Risiken verwaltet. Ein besseres Instrument verbessert die Verwaltung eines Zustands, den das Programm eigentlich verlassen sollte.

Erreichbarkeit, Ausnutzbarkeit und die Historie von Behebungsergebnissen sind an anderer Stelle wertvoll. Richten Sie sie auf die Korrektheit und Reihenfolge der Behebungen, wo sie Fragen beantworten, die die Zahl tatsächlich verändern: Behebt diese Korrektur einen realen Pfad? Wird sie ausgeliefert, ohne den Build zu beschädigen? Und was lässt sich zuerst beseitigen? Um null zu erreichen, kommt es auf die Rate an – und die Rangfolge lässt diese Rate unverändert.

Was erforderlich ist, um den Backlog als Angriffsfläche zu behandeln

Bevor Sie etwas ändern, ermitteln Sie vier Zahlen. Die meisten Teams können sie innerhalb einer Woche liefern, und sie verändern das Gespräch meist schneller als jedes Argument.

1. Der tatsächliche Zufluss im Verhältnis zum tatsächlichen Abschluss über die vergangenen 90 Tage – wobei tatsächlich behobene Findings gezählt werden, nicht Findings, die lediglich einer Triage unterzogen wurden.

2. Die Anzahl der Einträge mit „Risiko akzeptiert“ und „wird nicht behoben“, zusammen mit dem Datum ihrer letzten erneuten Prüfung. Jedes Datum, das vor der Einführung von AI-Coding-Tools in Ihrer Organisation liegt, kennzeichnet einen Eintrag, der nach Quoten bewertet wurde, die sich inzwischen geändert haben.

3. Der Anteil des gemergten Codes mit einem menschlichen Autor, der Ihnen zeigt, wie viel Ihres Zuflusses noch von der Person erklärt werden kann, die ihn erzeugt hat.

4. Die Merge-Rate von Security-Fixes: Wie viele der im vergangenen Quartal eröffneten Fixes wurden ausgeliefert?

Die vierte Zahl überrascht die meisten Menschen, weil sie seit Jahren die tatsächliche Einschränkung darstellt, während die Aufmerksamkeit auf der Erkennung lag. Fixes werden erstellt, aber nie gemergt. Ein Programm, das mehr Findings erzeugt, ohne diese Rate zu steigern, erzeugt daher lediglich eine längere Warteschlange.

Ein Backlog geht zurück, wenn drei Dinge gleichzeitig gegeben sind: Prävention senkt den Zufluss in dem Moment, in dem der Code erstellt wird; der Abbau läuft, ohne dass für jedes Finding eine menschliche Entscheidung erforderlich ist; und Sie können der Korrektheit der Fixes vertrauen, ohne dass jemand jeden Diff lesen muss. Wenn diese drei Voraussetzungen erfüllt sind, kann Ihr Team das Risiko tatsächlich senken und mehr abbauen, als neu hinzukommt. Das Register beginnt zum ersten Mal seit seiner Eröffnung zu schrumpfen.

Ab diesem Punkt verändert sich die Aufgabe, denn die Arbeit liegt nicht mehr in der Warteschlange – sie wird zum Programm.