Ist Prävention im Grunde ein gelöstes Problem?

Das Verhindern, dass neue Sicherheitsprobleme in von Agenten generiertem Code bereitgestellt werden, ist „architektonisch“ gesehen ein gelöstes Problem. architektonisch, ein gelöstes Problem. Prävention bedeutet, zu verhindern, dass eine neue Schwachstelle im Code zu irgendeinem Zeitpunkt des Entwicklungs- und Release-Prozesses die Produktion erreicht – einschließlich, aber nicht beschränkt auf ihre Einführung in einem Feature-Branch. Im agentischen Entwicklungslebenszyklus gibt es klar abgegrenzte Punkte, an denen Sicherheit eingebracht werden kann; jeder eignet sich für eine andere Art von Kontrolle, und die Zuordnung zwischen ihnen ist gut verstanden. Diese Zuordnung innerhalb einer Organisation anzuwenden, während sich der Softwareentwicklungslebenszyklus aktiv verändert, ist jedoch schwierig.

Umfassend lässt sich das nicht durch Prompts lösen

Die idealisierte Version von Sicherheit in der agentischen Entwicklung ist eine einzige Anweisung: Man weist den Agenten an, sicheren Code zu schreiben, platziert dies im System-Prompt oder in der Harness-Konfiguration und lässt ihn arbeiten.

Abbildung 1. Die Anweisung, die sich wie eine Kontrolle anfühlt.

Anleitungen im Kontextfenster verändern zwar, was ein Agent erzeugt, und der Effekt ist real genug, um darauf aufzubauen – aber eine Anweisung ist keine Einschränkung. Sie verschiebt die Wahrscheinlichkeit dessen, was geschrieben wird, entscheidet aber nicht darüber. Das gilt für eine einzeilige Regel ebenso wie für ein sorgfältig formuliertes Skill. Es ist eine Eigenschaft der Funktionsweise dieser Modelle (sie berücksichtigen alle Eingaben und beurteilen deren relative Priorität), unabhängig von der Qualität Ihres Prompts.

KI-generierter Code bleibt für dieselben Klassen von Schwachstellen anfällig, die es bei von Menschen geschriebenem Code schon immer gab. Eine Anweisung allein ändert daran nichts, und auch noch so ausgefeilte Prompts werden das nicht tun. Die nützliche Frage lautet also, wohin der Rest gehört.

„Shift in“ ist das neue „Shift left“

Drei Kosten steigen, je weiter sich die Sicherheit vom Moment der Codeerstellung nach außen bewegt.

Abbildung 2. Alle drei steigen gemeinsam, wenn sich die Sicherheit nach außen bewegt.

Tokens sind der offensichtliche Faktor. Die Kosten eines deterministischen Scans sind neben einem Modellaufruf ein Rundungsfehler, und die Lücke wird jedes Mal größer, wenn man ein Modell auffordert, über mehr Teile der Codebasis hinweg zu schlussfolgern.

Die menschliche Aufmerksamkeit ist der zweite Faktor. Ein Problem, das erkannt wird, während ein Agent noch arbeitet, wird nie zu einem Ticket, muss nie priorisiert werden und unterbricht nie jemanden, der zwischen mehreren Aufgaben aufgeteilt ist.

Der dritte Faktor ist, die richtige Korrektur zu finden. Ein Agent, der in den inneren Schleifen arbeitet, verfügt noch über den ursprünglichen Prompt und die Spezifikation. Wenn er also etwas korrigiert, kann er bestätigen, dass das Ergebnis sowohl funktional intakt als auch sicher ist, weil er weiß, was der Code tun sollte. Verschiebt man denselben Fund nach außen, ist dieser Kontext verschwunden. Die Korrektheit muss von außen erneut hergestellt werden – durch Unit-, Smoke- und Integrationstests, die vor und während der CI ausgeführt werden.

Ein Agent, der bestehende Funktionalität erweitert, stützt sich in den inneren Schleifen ebenfalls auf die Testsuite, weil er wissen muss, dass er nichts beschädigt hat, was er nicht gesehen hat. Er verlässt sich jedoch weniger darauf, da er den Prompt noch kennt und nachvollziehen kann, was die Änderung bewirken sollte, anstatt die Absicht aus dem abzuleiten, was zufällig erfolgreich durchläuft. Je weiter eine Korrektur nach außen wandert, desto mehr dieser Last verlagert sich allein auf die Testabdeckung.

Das spricht dafür, Sicherheit nach innen zu verlagern. Der Grund, warum das nicht von selbst geschieht, ist, dass der Druck in die andere Richtung stärker ist.

Sicherheit ist Reibung

Nichts davon ist neu. Sicherheit kostet Zeit, und Zeit in den Arbeitsfluss von Entwicklern zu integrieren, war schon immer der schwierige Teil dieser Aufgabe. Deshalb hat Snyk vor zehn Jahren Shift Left in DevSecOps erfolgreich vorangetrieben.

Das agentische Zeitalter verstärkt diesen Effekt, statt ihn zu verändern. Organisationen unterlegen die Einführung von KI mit Multiplikatoren für die Produktivität von Entwicklern. Und wenn eine deutliche Steigerung des Durchsatzes erwartet wird, ist alles, was die Schleife verlangsamt, keine Frage des Abwägens. Es wird entfernt.

Die Frage lautet daher nicht, ob Sicherheitskontrollen ergänzt werden sollen, sondern wo jede einzelne sitzen kann, ohne mehr zu kosten, als sie einspart.

Der Lebenszyklus ist ein Stapel von Schleifen

Laurie Voss’ Schleifenmodell ist eine der klarsten Beschreibungen dafür, wie Software heute entwickelt wird: eine Reihe verschachtelter Schleifen, von denen jede durch ihr eigenes Signal abgeschlossen wird.

• Die Ausführungsschleife schließt eine Anweisung ab und endet mit Feedback aus der Umgebung – etwa einem Testergebnis, einer API-Antwort oder dem Inhalt einer Datei.

• Die Aufgabenschleife schließt eine Spezifikation ab.

• Die Produktschleife liefert aus.

• Die Systemschleife verbessert das gesamte System über Tage und Wochen hinweg.

• Die Aufsichtsschleife ist der Bereich, in dem ein Mensch Ziele festlegt, ein Budget zuweist und entscheidet, was wichtig ist.

Abbildung 3. Der Schleifenstapel, nach Laurie Voss’ What the hell is a loop, anyway?

Innerhalb der Ausführungs- und Aufgabenschleifen ist die Arbeit noch offen, und ein Fund kann noch vor Abschluss der Schleife ohne menschliches Eingreifen behoben werden. Ab der Produktschleife ist ein erhebliches Vertrauen in die Testabdeckung erforderlich; andernfalls ist eine menschliche Prüfung notwendig.

Bevor wir darauf aufbauen, gibt es zwei Einschränkungen. Erstens: Die Einführung ist uneinheitlich: Selbst innerhalb von Unternehmen gibt es ein Spektrum bei der Einführung agentischer Entwicklung. Viele Teams setzen nicht in jeder dieser Schleifen Agenten ein, und in vielen arbeiten noch Menschen weit innerhalb der inneren Schleifen statt ausschließlich auf der Aufsichtsebene. Die Schleifen gelten in beiden Fällen, denn sie beschreiben, wann ein Arbeitsabschnitt abgeschlossen wird, nicht, wer ihn abschließt.

Und zweitens: Wenn man das agentische Vokabular entfernt, entspricht vieles davon der Art, wie Software seit Langem entwickelt wird: Man iteriert über eine Änderung, schließt eine Arbeitseinheit ab, liefert aus, verbessert das System, und jemand entscheidet, was als Nächstes erledigt werden soll. Geändert haben sich die Geschwindigkeit und die Frage, wer (oder was) an der Tastatur sitzt.

Die Risiken, die sich im Voraus benennen lassen

Einige Risiken sind vollständig vorhersehbar: SQL-Injection, Cross-Site-Scripting, fest codierte Geheimnisse, schwache Standardwerte bei der Kryptografie und die häufigsten Fehlkonfigurationen von Infrastructure as Code. Wir wissen genau, wonach wir suchen, und einem Agenten kann man vor dem Schreiben der ersten Zeile sagen, wie er dies vermeiden soll.

Die Kontrolle besteht aus Anleitungen im Kontext des Agenten: System-Prompts, Harness-Konfiguration und Skills, die die Risiken abdecken, deren Erzeugung ein Team am dringendsten verhindern möchte. Sie ist die kostengünstigste verfügbare Kontrolle, weil die Kosten einmalig im Platz des Kontextfensters anfallen und nicht für jedes geprüfte Problem. Nichts wird ausgeführt und nichts bewertet; die Anleitung ist einfach vorhanden.

Ein Teil davon ist bereits vorhanden, ohne dass jemand etwas bereitstellt. Harnesses enthalten standardmäßig System-Prompts, die einige dieser Vorgaben enthalten. Beispielsweise dokumentiert Anthropic die System-Prompts jedes seiner Modelle. Darüber hinaus bauen viele Organisationen gemeinsame Skill-Register auf, teilweise mit anwendungsspezifischen Skills, die beschreiben, wie ihre eigenen Teams entwickeln. Ein Security-Skill ist daher keine neue Art von Artefakt, das verteilt werden muss. Er ist ein weiterer Eintrag in etwas, das bereits existiert.

Die Grenze liegt hier im Kontext. Jede Anweisung konkurriert mit den bereits im Fenster vorhandenen Anweisungen, und das Laden des gesamten Spektrums von Schwachstellenklassen in den Kontext eines Agenten verwässert die wichtigsten Hinweise zugunsten von Risiken, die selten auftreten. Man muss dosieren, und das bedeutet, dass etwas anderes auffangen muss, was man weglässt. Außerdem ist der Kontext nur die Hälfte der Einschränkung. Selbst bei unbegrenztem Platz lassen sich manche Risiken überhaupt nicht in eine Anweisung schreiben, weil zum Zeitpunkt ihrer Formulierung niemand wusste, dass sie existieren.

Die Probleme, von denen niemand dem Agenten hätte erzählen können

Wenn Entwickler oder Agenten ein Paket auswählen, nehmen sie häufig die neueste Version, weil sie aktuell ist und das tut, was sie benötigen. Wurde in derselben Woche eine Schwachstelle in dieser Version offengelegt, wüsste keiner von beiden davon. Das Modell wurde nicht damit trainiert. Kein Skill hätte sie abdecken können, weil die Offenlegung zum Zeitpunkt der Erstellung des Skills noch nicht existierte. Zu erwarten, dass Prävention durch Anweisungen damit umgeht, ist niemandem gegenüber eine vernünftige Forderung.

Dann gibt es noch alles, was in der vorherigen Phase aus der Dosierung herausgefallen ist. Die lange Risikoschwanzverteilung, die nicht in einen System-Prompt oder Skill passt, ohne den Kontext zu verunreinigen, aber vollkommen real und erkennbar ist. Aus der Perspektive des Agenten sind diese beiden Risikokategorien dasselbe Problem: Er wurde nie angewiesen, darauf zu achten.

Für beide braucht es einen Test, der erschöpfend statt selektiv läuft, während die Arbeit noch offen ist, und schnell genug Ergebnisse liefert, damit der Agent noch da ist, um darauf zu reagieren. Und er sollte nicht beim Finden aufhören. Wenn der Agent beheben kann, was der Test aufdeckt, und ihn anschließend erneut ausführt, wird die Schleife vollständig ohne menschliches Eingreifen geschlossen. Das ist die einzige Variante, die im praktischen Einsatz mit einem Team Bestand hat, das den Durchsatz misst.

Trusted Output Assurance (Teil von Evo Agentic Development Security) erledigt dies über Hooks und die CLI. Ein Scan wird ausgelöst, sobald Dateien geschrieben werden, und erneut, wenn der Agent seine geplante Arbeit beendet. So werden neu eingeführte Probleme erkannt und behoben, bevor die Spezifikation abgeschlossen ist – alles innerhalb der inneren Schleifen. Prüfungen des Paketstatus, Scans auf Secrets und Schutz vor bösartigem Code laufen über denselben Pfad.

Ein Agent, der alles behebt, was man ihm vorlegt, schreibt mitunter funktionierenden Code um, um einen Fund zu beheben, der nie real war. Das ist ein Grund dafür, dass diese Phase deterministischen statt probabilistischen Engines gehört, und es macht die Rate falsch positiver Ergebnisse zu einem Kriterium, das bei der Auswahl der Ausführung berücksichtigt werden muss. Man sollte außerdem verstehen, was geschieht, wenn Engine und Agent bei einem erkannten Fund unterschiedlicher Meinung sind. Snyk optimiert für beides. Eine Kontrolle verdient nur dann einen Platz in den inneren Schleifen, wenn sie oft genug richtig liegt, um unbeaufsichtigt darauf zu reagieren. Bei geringerer Zuverlässigkeit gehört der Fund weiter nach außen.

Eine solche Kontrolle ist genau so viel wert, wie sie genutzt wird, und gerade bei der Nutzung hatte die Sicherheit in den inneren Schleifen schon immer Schwierigkeiten, weil jeder Entwickler sie selbst einrichten musste. Dieser Teil ist jetzt unkompliziert. Organisationen verteilen Trusted Output Assurance per MDM auf die Rechner der Entwickler und integrieren sie in Sandbox-Vorlagen. So ist sie überall vorhanden, wo Code generiert wird, und zentral sichtbar, was auf welchem Rechner ausgeführt wird, statt dass man sich darauf verlassen muss.

Womit schnelle, deterministische Engines Schwierigkeiten haben

Autorisierungs- und Fehler in der Geschäftslogik sind ein anderes Problem. Fehlerhafte objektbasierte Autorisierung, IDOR, Verstöße gegen die Mandantentrennung und mehrstufiger Missbrauch. Diese Klassen sind gut verstanden, und regelbasierte Engines sind nachweislich schlecht darin, sie zu finden, weil der Fehler semantischer und nicht syntaktischer Natur ist. Im Code sieht nichts falsch aus. Falsch ist die Beziehung zwischen den Dingen.

Hier funktioniert ein LLM-basierter Scan der zusammengesetzten Codebasis. In der Praxis bedeutet das heute, dass eine Organisation ein Modell auffordert, gezielt zu suchen – entweder manuell oder als ausgelösten Agentenaufruf in einer Pipeline, manchmal über einen Anbieter und manchmal, indem sie ein Frontier-Modell direkt auf das Repository ansetzt.

Führt man dieselbe Sicherheitsprüfung fünfmal über denselben Code aus, taucht nahezu die Hälfte dessen, was das Modell eigenständig findet, nur in einem der fünf Durchläufe auf. Das ist Snyk VulnBench JS 1.0, gemessen über 300 Durchläufe derselben Prüfung.

Diese einmaligen Berichte sind nicht falsch, und VulnBench dokumentiert zahlreiche davon, die wie echte Lücken in der Abdeckung und nicht wie Rauschen aussehen. Ein einzelner Durchlauf ist jedoch keine Entscheidungsgrundlage. Vertrauen muss durch Wiederholung erworben werden. Deshalb wird an diesem Punkt die Kosten pro Fund erstmals zu einem echten Kostenfaktor statt zu einem Rundungsfehler.

Was sich in dieser Phase ändert, ist nicht die Dauer eines Scans, sondern das, was er betrachten muss. Jede vorherige Kontrolle ist inkrementell. Ein Skill wird ausgelöst, wenn der Agent nach einem Muster greift. Ein Scan deckt die gerade geschriebene Datei ab und nicht die Dutzenden Dateien, die während einer Sitzung bearbeitet wurden. Jede dieser Kontrollen wird in eine ohnehin stattfindende Arbeit integriert. Die semantische Analyse der zusammengesetzten Codebasis kann das nicht, denn erst wenn die einzelnen Teile zusammengeführt sind, gibt es überhaupt etwas, über das man schlussfolgern kann. Sie läuft daher als eigener Schritt, und ihre Kosten werden der Schleife hinzugefügt, statt darin aufzugehen. Die Zeit, die diese Schleife bereits benötigt hat, war Arbeitszeit des Agenten und keine freie Zeit zum Warten; ein vollständiger Durchlauf kann ihre Dauer problemlos verdoppeln. Das setzt ein sauberes Ergebnis voraus: Alles, was gefunden wird, muss behoben und die Analyse erneut ausgeführt werden, sodass sich die Kosten vervielfachen, statt sich lediglich zu addieren. Genau deshalb erfolgt dies erst, nachdem der Agent weitergezogen ist.

Jeder dieser Zyklen beansprucht außerdem die Testsuite stärker. Der Prompt ist zu diesem Zeitpunkt nicht mehr vorhanden, sodass die Abdeckung das Einzige ist, was zwischen einem Security-Fix und einem fehlerhaften Feature steht – und bei jedem erneuten Durchlauf muss sie diese Aufgabe wieder erfüllen. In den meisten Unternehmen liegt die Abdeckung nicht annähernd auf dem Niveau, auf dem ein Fix unbeaufsichtigt eingespielt werden kann, sodass am Ende jemand ihn prüfen muss.

Genau in diese Richtung entwickelt sich Snyk mit der Zukunft von agentischer AppSec. Dazu wird in naher Zukunft mehr zu erwarten sein.

Was erst unter einem (Pre-Production-)Angriff sichtbar wird

Die letzte Kategorie tritt erst zutage, wenn etwas läuft. Mehrstufige Exploit-Ketten, der Missbrauch von Workflows, Prompt Injection gegen einen bereitgestellten Agenten, Datenexfiltrationspfade, die nur deshalb existieren, weil drei Komponenten in Ihrer Umgebung zufällig miteinander interagieren.

Die entsprechende Kontrolle ist adversariales Testen: Pentesting und AI Red Teaming gegen eine echte Anwendung. Die Arten von Schwachstellen, nach denen gesucht wird, sind bekannt, aber die Arbeit ist explorativ. Die Anwendung ist der Ausgangspunkt, und die Grenzen werden nicht im Voraus festgelegt – sichtbar wird also, was das System letztlich zulässt.

Hier ist Evo Continuous Offensive Securityangesiedelt. Dabei lohnt es sich, genau zu benennen, was die Arbeit erledigt, denn es handelt sich nicht um einen Scanner, an den ein Modell angeflanscht wurde. Ein orchestrierender Pentest-Agent führt spezialisierte Sub-Agenten gegen ein Live-Ziel aus. Ein separater Validierungsagent hinterfragt die Meldungen der anderen und erstellt einen funktionsfähigen Exploit, um sie zu belegen. Dieser letzte Teil ist entscheidend, denn exploratives, modellbasiertes Testen erzeugt plausible klingende Befunde, sofern nichts sie zur Belastbarkeit zwingt. Deshalb wird jeder Befund als ausführbarer Proof of Concept und nicht als Hypothese ausgeliefert.

Drei dieser Sub-Agenten – für Business Logic, Zugriffskontrolle und Autorisierung sowie Exploit-Chaining – arbeiten an denselben semantischen Kategorien, die auch die vorherige Stufe benötigt. Diese und ähnliche Engines in die Workflows der vorherigen Stufe zu überführen, sobald sich diese Workflows etabliert haben, ist bereits in Arbeit.

Es kann gegen die Pre-Production als Release-Gate oder unmittelbar nach einem Release ausgeführt werden, um festzulegen, woran als Nächstes gearbeitet werden sollte. Historisch war dies eine jährliche oder halbjährliche Compliance-Übung. Unternehmen führen sie inzwischen deutlich häufiger durch – der richtige Ansatz, denn Angreifer halten sich nicht an einen Audit-Zeitplan.

Es gibt nichts anzugreifen, bevor etwas läuft – genau deshalb kann dies nicht früher geschehen.

Was der Agent wusste und wann er handeln konnte

Jede der oben beschriebenen Kontrollen hängt von denselben zwei Dingen ab: ob der Agent vor dem Schreiben des Codes informiert werden konnte und ob die Antwort eintrifft, solange er den Prompt noch vorliegen hat. Diese beiden Fragen ordnen alle vier Kontrollen ein und erklären, warum die Reihenfolge keine Frage der Präferenz ist. Jede Kontrolle fällt in eines der vier unten stehenden Felder.

Abbildung 4. Die vier Kontrollen in der Reihenfolge, die sich aus den beiden Antworten ergibt.

Warum dies in der Praxis schwieriger ist

Der Bauplan ist unkompliziert. Ihn in einem realen Unternehmen zu betreiben, ist es nicht – und die Gründe haben nur sehr wenig mit Sicherheit zu tun.

Die meisten Unternehmen verfügen noch nicht über einen etablierten agentischen Entwicklungslebenszyklus. Die Tools, Harnesses und Architekturen, auf die sie sich standardisieren, verändern sich noch – manchmal von Quartal zu Quartal. Die Anbieterlandschaft bewegt sich ebenso schnell. Selbst dort, wo eine Entscheidung gefallen ist, besteht daher verständlicherweise Zurückhaltung, sich auf etwas festzulegen, das einer Einbahnstraße ähnelt. All das zeigt sich in unklaren Zuständigkeiten, denn solange sich die Form des Lebenszyklus noch verändert, ist auch die Frage im Fluss, wer für welchen Teil verantwortlich ist. Autorisierungs- und Logikfehler gehören meist niemandem konkret, bis ein Vorfall sie jemandem zuweist.

Nichts davon erfordert einen Neustart auf der grünen Wiese – und genau das sollte man sich merken. Fast jedes Unternehmen verfügt bereits über ein Security-Gate vor dem Deployment, und dieses Gate leistet echte Arbeit. Es ist nicht das, was man herausreißen sollte, während man den Rest klärt. Diese Integrationspunkte bauen auf dem Bestehenden auf und können einzeln übernommen werden – in jeder Reihenfolge, die dem tatsächlich etablierten Stand Ihres Lebenszyklus entspricht. Deterministisches Scanning in den Ablauf einzubetten, setzt nicht voraus, dass bereits geklärt ist, wer für adversariales Testen zuständig ist.

Der zweite Punkt wird oft unterschätzt. In den inneren Schleifen hat eine Kontrolle bereits verloren, wenn sie die Arbeit an einen Menschen zurückgibt – ebenso wie eine Kontrolle, die eine Warteschlange von KI-generierten Pull Requests erzeugt, die jemand prüfen soll. Beides nimmt eine Sicherheitsprüfung und verwandelt sie in den Backlog von jemand anderem – genau dort werden Kontrollen stillschweigend abgeschaltet.

Je weiter außen im Prozess, desto schwieriger lässt sich ein Mensch vermeiden. Die Testabdeckung liegt in den meisten Unternehmen weit unter dem Niveau, auf dem man darauf vertrauen könnte, dass ein autonomer Fix eingespielt wird. Also prüft ihn jemand – und das ist heute der ehrliche Zustand, kein Versagen der Tools. Harnesses werden besser darin, die Testsuite ohne Prompt auszuführen, und die Abdeckung steigt auch dort, wo Agenten die Tests schreiben. Doch niemand sollte so planen, als sei eines von beidem bereits erreicht. Das ist ein weiterer Grund, möglichst viel abzufangen, solange der Agent den Prompt noch vorliegen hat – denn nur an dieser Stelle ist kein Mensch erforderlich.

Der erste und der dritte Punkt machen es möglich, all dies sicher zu beginnen, während sich die Rahmenbedingungen noch verändern. Eine Kontrolle, die sich an einem Nachmittag einrichten, zentral neu konfigurieren oder vollständig entfernen lässt, kann eingeführt werden, bevor feststeht, wie Ihr Lebenszyklus aussieht. Im Moment ist diese Eigenschaft mehr wert als jede einzelne Fähigkeit.

Trusted Output Assurance selbst wird über MDM verteilt und zentral konfiguriert. Wenn sich also ändert, was ausgeführt wird, müssen weder Jamf- oder Intune-Richtlinien bearbeitet noch Deployment-Skripte neu geschrieben werden. Continuous Offensive Security benötigt Ihre Anwendungs-URLs und eine Reihe von Zugangsdaten, sodass kein Ausbau erforderlich ist, bevor es Ergebnisse liefert. Keine der beiden Lösungen bindet Sie an eine Architektur, auf die Sie sich noch nicht festgelegt haben.

Jetzt verhindern, als Nächstes beheben

Prävention ist in dem entscheidenden Sinne gelöst. Die Ansatzpunkte existieren, die Kontrollen existieren, und es ist bekannt, welche Kontrolle wohin gehört. Doch die Umsetzung bedeutet Arbeit, und der (AI)SDLC entwickelt sich noch unter unseren Füßen weiter.

Bei der Behebung sieht es anders aus. Deterministisches Scanning innerhalb des Ablaufs hindert Sie daran, im Moment der Einführung ein Paket mit einer bekannten schädlichen Version zu übernehmen. Es hilft jedoch nicht bei dem Paket, das Sie vor acht Monaten (oder sogar acht Jahren) übernommen haben und das letzte Woche eine CVE erhalten hat. Dieser Rückstand wächst aus zwei Richtungen zugleich: aus jahrelang angesammelten Befunden, die nie behoben wurden, und aus einem kontinuierlichen Strom neuer Meldungen, die bereits in der Produktion befindlichen Code betreffen. Gute Prävention verkleinert ihn nicht, verhindert aber, dass er weiter wächst.

Dieses Problem verdient ein eigenes Gespräch. Bis dahin ist die Präventionsseite bereits verfügbar, und der erste Schritt ist kleiner, als er aussieht: Wählen Sie den stabilsten Punkt in Ihrem Lebenszyklus und fügen Sie die passende Kontrolle hinzu.