KI-Sicherheit braucht eine zweite Meinung

KI schreibt Software schneller, als wir sie absichern können. Kommst du noch mit?

Bis du diesen Satz zu Ende gelesen hast, werden Entwickler und ihre KI-Agenten ein paar tausend Code-Commits eingereicht haben. Um diese Zeit im vergangenen Jahr wären es etwa 150 gewesen.

Im vergangenen Jahr hat sich die Entwicklung KI-generierter Software in atemberaubendem Tempo beschleunigt. GitHub verzeichnete allein im September 2026 7,38 Milliarden Commits – mehr als fünfmal so viele wie im gesamten Vorjahr. Die Auswirkungen dieser Explosion auf die Sicherheit sind gravierend. Jeder einzelne dieser Commits enthält Code, den jemand verstehen, warten und absichern soll. Die Cloud Security Alliance stellte fest, dass Entwickler, die KI einsetzen, bei Fortune-50-Unternehmen drei- bis viermal so viele Codeänderungen einreichen wie ihre Kollegen, während die monatlichen Sicherheitsbefunde um etwa das Zehnfache zunahmen.

Wer muss nun mit diesem Anstieg umgehen? Das Team des CISO ist genauso groß wie vor einem Jahr, der Rückstand jedoch nicht. Die Zahl der gemeldeten Schwachstellen steigt, die monatlichen Behebungen gehen zurück und die Zahl der ungelösten kritischen Schwachstellen nimmt zu. Kein Wunder, dass Gartner sagt, Burnout bei CISOs entwickle sich zu einem kritischen operativen Risiko.

Die Verlockung des neuesten Modells

Bei einer so hohen Zahl liegt es nahe, einer noch größeren Zahl nachzujagen: mehr Befunde, größere Abdeckung, mehr Scans. Doch das ist, als würde man Wasser aus einem sinkenden Boot schöpfen und nach einem größeren Eimer verlangen, obwohl man eigentlich das Leck finden muss. Ein Sicherheitsprogramm wird nicht daran gemessen, wie viel es findet. Entscheidend ist, wie viele der gefundenen Probleme tatsächlich vorliegen und wie viele der kritischsten Befunde tatsächlich behoben werden.

Frontier-KI-Modelle sind bemerkenswert gut darin, mithilfe probabilistischer Schlussfolgerungen neuartige Exploits und bislang nicht katalogisierte Schwachstellen zu finden. Die Ergebnisse variieren jedoch. Laut einer Untersuchung von Checkmarx stimmen die Befunde bei fünf Durchläufen desselben Scans mit demselben Code nur in etwa einem Drittel der Fälle überein.

Diese Inkonsistenz zeigt, warum regelbasierte Analysen weiterhin wichtig sind. Sie sind weniger flexibel als Frontier-KI, wenden aber bewährte Logik jedes Mal auf dieselbe Weise an. So können Teams den Ergebnissen vertrauen und sie überprüfen. KI erkennt, was Regeln übersehen – etwa bekannte Schwachstellen in ungewohnter Form oder Fehler, die erst ausnutzbar werden, wenn verschiedene Teile des Codes miteinander interagieren. Zusammen decken KI und regelbasierte Analysen mehr relevante Probleme auf und lösen dabei weniger Fehlalarme aus.

Nichts davon ist ein Argument gegen KI. Es ist vielmehr ein Argument dafür, dass Sicherheit eine zweite Meinung braucht. Welches System du auch wählst, es muss sich an drei Fragen messen lassen.

Frage eins: Zuverlässigkeit

Wenn der Scanner einen Fehler meldet, ist es dann deine Zeit wert, dich darum zu kümmern?

Zuverlässigkeit schafft Vertrauen. Ein Befund, der sich als falsch herausstellt, kostet Entwickler einen Nachmittag und die Sicherheitsteams zusätzlich Glaubwürdigkeit. In großem Maßstab sorgen falsch-positive Ergebnisse dafür, dass Teams nicht mehr zuhören. Die Warnmeldungen sind dann nur noch „Der Wolf ist da!“ und gehen im Hintergrundrauschen unter.

Hier kommt es auf Konsistenz an. Eine deterministische Analyse liefert für denselben Code jedes Mal dieselbe Antwort. Das schafft Vertrauen und macht die Ergebnisse überprüfbar.

Frage zwei: Genauigkeit

Findest du die vollständige Menge der wichtigsten Probleme?

Die Zuverlässigkeit sagt dir, ob ein Befund deine Zeit wert ist, aber nicht, was der Scanner übersehen hat. Wir verwenden eine in der Datenwissenschaft verwurzelte Messgröße, den F1-Wert. Er bewertet die Leistung auf einer Skala von 1 bis 0 anhand zweier Faktoren:

• Präzision: der Anteil der gemeldeten Befunde, die tatsächlich vorliegen. Eine hohe Präzision bedeutet weniger Fehlalarme.
• Trefferquote: der Anteil der tatsächlichen Schwachstellen, die der Scanner findet. Bei einer hohen Trefferquote bleibt nur wenig unentdeckt.

Ein Scanner kann präzise wirken, indem er fast nichts meldet, oder gründlich, indem er alles meldet – in beiden Fällen kann der F1-Wert niedrig sein. Der Branchendurchschnitt liegt bei etwa 0,20. Wir arbeiten intensiv an dieser Herausforderung und haben Ergebnisse erzielt, die eine drei- bis viermal so hohe Genauigkeit aufweisen wie ein herkömmlicher Scanner.

Eine höhere Genauigkeit erleichtert Entwicklern alle nachgelagerten Arbeitsschritte. Dein Team verbringt weniger Zeit mit der Überprüfung und mehr Zeit mit der Behebung.

Frage drei: ROI

Wie holen wir das Maximum aus unseren Investitionen und Ressourcen heraus?

Diese Frage wird in Pilotprojekten am häufigsten übersprungen und muss im Produktivbetrieb am schmerzhaftesten beantwortet werden.

Frontier-Modelle rechnen pro Token ab, und Tokens werden verbraucht, unabhängig davon, ob ein Scan etwas findet. Der Scan eines Repositorys mit einer Million Codezeilen kostet zu den derzeit veröffentlichten Preisen mehr als tausend Dollar. Auch der Tokenverbrauch unterscheidet sich je nach Modell erheblich: Der Preis variiert je nach gewähltem Modell und danach, wie viel Schlussfolgerungsarbeit es leisten muss, um deine Aufgabe abzuschließen.

Hochgerechnet auf jeden Commit, jeden Pull Request und jedes Repository in einem Unternehmen summieren sich die Kosten. Uber, das jährlich 3,4 Milliarden Dollar für Forschung und Entwicklung ausgibt, soll sein gesamtes KI-Budget für 2026 bereits wenige Monate nach der Einführung von KI-Codierungstools aufgebraucht haben.

Wir nennen das die Tokensteuer. Das ist, als würde man mit einem Ferrari Lebensmittel einkaufen: Man bezahlt für Leistung, die man für diese Fahrt nicht braucht. Fest im Code hinterlegte Zugangsdaten und SQL-Injection sind vorhersehbare Muster, die sich mit deterministischer Analyse zuverlässig erkennen lassen.

Die Anwendungssicherheit muss sich weiterentwickeln

Das ist der Grundgedanke hinter der Architektur von Checkmarx Fusion. Regelbasierte Engines schaffen reproduzierbar eine verlässliche Grundlage – und das kostengünstiger als eine tokenbasierte Analyse. Modernste Modelle richten sich auf das, was Regeln nicht vorhersehen können: neuartige Muster, komplexe Logik und die Ausnutzbarkeit im jeweiligen Kontext. Anschließend führt eine Ebene zur Analyse der Ergebnisse die Befunde zu einem einzigen vertrauenswürdigen Gesamtbild zusammen.

Deterministische Analyse schafft Gewissheit. KI sorgt für größere Reichweite. Abdeckung und Vertrauen steigen gemeinsam. Im Vergleich zu einem allein arbeitenden LLM erreichen wir eine bis zu viermal höhere Ergebnistreue, eine zwei- bis viermal so hohe Genauigkeit und etwa ein Drittel der Kosten.

Probleme zu finden, ist nur der Anfang. Dieselbe Logik gilt für die Prävention. Betrachten wir ein Beispiel. Wenn wir Entwickler direkt bei der Entstehung unterstützen – in der IDE, in der sie den Code schreiben –, können wir Probleme verhindern, bevor sie überhaupt entstehen. Und wenn Schwachstellen doch durchrutschen: Warum sollten wir Entwicklern nicht sofort zusammenführbare Korrekturen für die wichtigsten davon bereitstellen? Genau an diesen Herausforderungen arbeiten wir. Unser Ziel ist es, den bestehenden Rückstand schrittweise abzubauen und mit möglichst geringem Aufwand so schnell wie möglich Wirkung zu erzielen.

Der Code läuft bereits. Können Sie Schritt halten?

KI hat Angreifern einen Geschwindigkeitsvorteil verschafft. Diese Lücke schließt man nicht mit noch einem weiteren Tool. Entscheidend ist vielmehr, wie die gesamte Organisation Software entwickelt und absichert. Der Code, der heute geschrieben wird, wird Ihr Unternehmen noch jahrelang am Laufen halten. Für Sicherheitsverantwortliche lautet die Frage nicht mehr, wie viel schneller KI die Entwicklung macht. Entscheidend ist, ob Ihre Programme mit dem Schritt halten können, was KI hervorbringt.

Verlieren Sie sich also nicht in den Zahlen. Stellen Sie bei jedem Programm drei Fragen: Kann ich den Ergebnissen vertrauen? Findet es genug von dem, was wirklich wichtig ist? Lässt es sich in meiner gesamten Organisation realistisch umsetzen? Wer deterministische Präzision mit modernstem Schlussfolgern verbindet, hat die besten Chancen, alle drei Fragen mit Ja zu beantworten.

Die Softwareentwicklung verlangsamt sich nicht. Unsere Aufgabe ist es nun, die Risikolücke zu schließen: den Abstand zwischen der Geschwindigkeit, mit der Software entsteht, und der Geschwindigkeit, mit der Risiken erkannt und behoben werden.