Deterministische Security-Tools sind inzwischen so fester Bestandteil der Sicherheit geworden, dass wir lange Zeit keine Alternativen in Frage gestellt haben. Da KI mit probabilistischen Modellen zu einem Kernbestandteil der Sicherheit wird, ist es an der Zeit, den Determinismus neu zu bewerten und klarzustellen, wofür er benötigt wird. Andernfalls, warum sollten wir nicht einfach alles durch KI ersetzen?
Kurz gesagt, wir benötigen Determinismus wegen seiner Vorhersehbarkeit und Effizienz. Deterministische Tools wie SAST liefern jedes Mal das gleiche Ergebnis, wenn sie auf dasselbe angewendet werden, und das effizient. Sie sind daher nützlich in einer CI/CD-Pipeline, verteidigbar in einem Compliance-Audit und bilden eine Grundlage für alles andere. KI ist hervorragend im logischen Denken, sollte aber aufgrund ihrer Unvorhersehbarkeit am besten für Fälle aufbewahrt werden, in denen keine wiederholbaren Ergebnisse erforderlich sind.
Da immer mehr probabilistische Tools auf den Markt kommen, möchten wir aufschlüsseln, wie Determinismus nachhaltige Sicherheitspraktiken schafft, wie KI neue Möglichkeiten bietet und wie beide für maximale Wirkung kombiniert werden können.
Wenn Security-Tools vorhersehbar sein müssen
Einige Security-Aufgaben erfordern vor allem Konsistenz und Auditierbarkeit. Dieser Bedarf an Vorhersehbarkeit zeigt sich im gesamten Security-Workflow.
Wenn ein Scanner einen Befund meldet, müssen Entwickelnde ihm genug vertrauen, um um 23 Uhr darauf zu reagieren. Wenn eine CI/CD-Pipeline eine Bereitstellung blockiert, muss diese Blockade einer genauen Prüfung standhalten. In einer Pipeline läuft Ihr Scanner bei jedem Commit oder Pull Request. Wenn er am Montag 12 und am Dienstag 9 Probleme bei identischem Code meldet, ist das nicht gut. Ihre Pipeline-Ergebnisse sind nicht mehr vertrauenswürdig. Entwickelnde beginnen, Warnungen zu ignorieren, weil das Signal inkonsistent ist, und Sie können die Scan-Ausgabe nicht als sinnvolles Gate für Merges verwenden.
Ähnlich hängt Regressionstesting von der Reproduzierbarkeit ab. Wenn Sie eine Schwachstelle beheben und erneut scannen, muss ein sauberes Ergebnis bedeuten, dass sie tatsächlich behoben ist, und nicht, dass das Modell sie in diesem Durchlauf übersehen hat. Auch die Baseline- und Drift-Erkennung hängt davon ab, da sie wissen müssen, ob ein neuer Befund eine echte Änderung in der Codebasis widerspiegelt oder nur eine Varianz im Scanner.
Vorhersehbarkeit ist auch für die Compliance notwendig. Auditoren wünschen sich konsistente, erklärbare Befunde über die Zeit, mit einer klaren Aufzeichnung dessen, was wann und warum erkannt wurde. Ein Scanner, der bei verschiedenen Durchläufen unterschiedliche Ergebnisse liefert, kann dies nicht bieten.
Die praktischen Kosten der Unzuverlässigkeit in der Sicherheit untergraben langsam das Vertrauen in die Tools selbst, bis niemand mehr Befunde ernst nimmt. Reproduzierbarkeit, Auditierbarkeit und niedrige Fehlalarmraten müssen die Basis sein, auf die sich ein Security-Team verlassen kann.
Deterministische Security-Tools
SAST ist ein Paradebeispiel für ein deterministisches Security-Tool, das nach bekannten Mustern und Schwachstellen scannt. Denken Sie an fest codierte Secrets, bekannte CVEs, Abhängigkeitsschwachstellen und Injektionsmuster. Es funktioniert, indem es Code in einen abstrakten Syntaxbaum parst und verfolgt, wie benutzergesteuerte Daten von den Einstiegspunkten bis zu ihrer Verwendung durch die Anwendung fließen. Ein Befund lässt sich auf eine spezifische Regel zurückführen, die ein Mensch geschrieben und überprüft hat, und die Regel stimmt entweder überein oder nicht. Führen Sie denselben Scanner tausendmal auf demselben Code aus, und Sie erhalten dieselben Befunde.
Wiederholbarkeit macht deterministische Tools gut geeignet für den Anfang einer Pipeline (sie sind konsistent). Sie sind auditierbar, weil ein Mensch die Regeln geschrieben hat, und Sie können sie bei jedem Commit ausführen, ohne dass es zu teuer wird.
DAST befindet sich ebenfalls am deterministischen Ende des Spektrums. Es führt eine definierte Reihe von Angriffssimulationen gegen eine Live-Anwendung aus und liefert konsistente, wiederholbare Ergebnisse. Es ist eine nützliche Baseline-Prüfung, da es schneller und kostengünstiger ist als KI-Penetrationstests (vorerst). Wie jedes deterministische Tool findet es jedoch nur das, wofür es einen Test hat.
Wir sagen sicherlich nicht, dass deterministische Sicherheit oder auch nur eine vorhersehbare Ausgabe immer besser ist. Die Kehrseite dessen, was deterministische Tools zuverlässig macht, ist auch ihre Begrenzung. Sie finden nur das, wofür sie eine Regel haben, sodass neuartige Angriffsmuster, nuancierte Logikfehler und Schwachstellen, die ein Verständnis des Geschäftskontexts erfordern, außerhalb dessen liegen, was ein deterministischer Scanner erfassen kann.
Deterministische Tools allein können Ihnen auch nicht sagen, welche Probleme im Kontext wichtiger sind. Einige deterministische Tools beinhalten eine grundlegende Erreichbarkeitsanalyse (im Wesentlichen statisches Call-Graph-Tracing), die bestätigen kann, ob eine anfällige Funktion tatsächlich aufgerufen wird. Aber wenn wir wissen wollen, ob dieser Befund in unserer spezifischen Anwendung, angesichts unserer Datenflüsse und Geschäftslogik, ausnutzbar ist? Nun, diese Art von Erreichbarkeitsanalyse und Priorisierung erfordert eine zusätzliche Reasoning-Schicht jenseits des Pattern-Matching.
Probabilistische Security-Tools
Dank des Aufkommens von LLMs verfügen wir nun über neue KI-gestützte Security-Tools wie KI-Scanner, automatisierte Triage und agentisches Pentesting, die von Natur aus probabilistisch sind. Probabilistische Tools (oder modellbasierte Tools) arbeiten nicht mit festen Regeln. Stattdessen behandeln sie Code als Text und führen darüber logische Schlussfolgerungen durch.
Da sie nicht an feste Muster gebunden sind, folgt eine KI der Logik über Funktionen hinweg, leitet Absichten ab und kann Schwachstellen aufdecken. Geschäftslogikfehler erfordern ein Verständnis dessen, was der Code zu tun versucht, nicht nur dessen, was er wörtlich aussagt. Probabilistische Tools sind darin hervorragend, und die KI verbessert sich ständig. KI kann neuartige Schwachstellenklassen und kontextabhängige Bugs finden, die zuvor eine geschickte menschliche Überprüfung erfordert hätten.
Ihrer Natur nach sind diese probabilistischen Modelle jedoch unvorhersehbar und inkonsistent. Die Ausgaben können (und werden wahrscheinlich) zwischen den Durchläufen variieren. LLMs generieren Ausgaben, indem sie das wahrscheinlichste nächste Token basierend auf Wahrscheinlichkeitsverteilungen über ihre Trainingsdaten vorhersagen, was bedeutet, dass dieselbe Eingabe unterschiedliche Ausgaben erzeugen kann, abhängig von Temperatur, Sampling-Verhalten und dem, was sich sonst noch im Kontextfenster befindet. Diese Variation ist in Ordnung, sogar hilfreich, für Pentesting und das Finden neuer Schwachstellen. Aber für Ihre CI/CD-Pipelines ist sie es nicht.
Es gibt auch ein Kostenproblem, wenn Sie versuchen, ein probabilistisches Reasoning-Modell als umfassenden Code-Scanner bei jedem Commit einzusetzen. James Berthoty von Latio führte informelle Tests durch, die zeigten, dass ein probabilistisches KI-Modell 17 Minuten und 155.000 Tokens benötigte, um ein Problem aufzudecken, das Opengrep, eine deterministische SAST-Engine, in 30 Sekunden fand. Bei jedem Pull Request in einer aktiven Codebasis ist dieser Kompromiss nicht sinnvoll.
Warum wir beides brauchen
Wenn man jedoch deterministische und probabilistische Modelle kombiniert und jede Methode entsprechend ihrer Stärken einsetzt, erhält man eine Security-Pipeline, deren Ganzes größer ist als die Summe ihrer Teile. In der Praxis sollte deterministisches Scanning bei jedem Commit ausgeführt werden, um bekannte Schwachstellenklassen schnell und konsistent zu erkennen. Darüber hinaus übernimmt KI-Reasoning die Triage und den Kontext.
Gemeinsam decken sie das Spektrum von „was wir als gefährlich kennen“ bis „was wir noch nicht in Betracht gezogen haben“ ab. Wir gehen davon aus, dass die letztere Kategorie wachsen wird. Da KI in immer mehr Codebasen integriert wird und Angreifer Zugang zu denselben Reasoning-Fähigkeiten erhalten, wird es viele Schwachstellen geben, für die noch keine Regel existiert. Daher werden wir Tools benötigen, die mithalten können.
Ein weiterer Grund, warum beide Tools benötigt werden, ist, dass sie dieselben Probleme auf unterschiedlichen Ebenen abdecken. DAST und KI-Penetrationstests beispielsweise arbeiten auf verschiedenen Schichten desselben Problems. DAST zeichnet sich durch schnelle, deterministische Prüfungen aus, die kontinuierlich laufen müssen. Man muss so schnell wie möglich wissen, ob offensichtlich offene Ports oder Seiten vorhanden sind, die nicht öffentlich sein sollten. KI-Penetrationstests sind langsamer und pro Lauf teurer, arbeiten aber auf einer grundlegend anderen Tiefe. Eine IDOR, die drei authentifizierte Schritte erfordert, um erreicht zu werden, wird in einem DAST-Scan nicht auftauchen, aber in einem guten KI-Penetrationstest. Mit DAST lassen sich die einfachen Dinge schnell erledigen, und anschließend kümmern sich KI-Penetrationstests um die komplexeren Fälle.
Wie Aikido beides nutzt
Wir haben Aikido auf der Prämisse aufgebaut, dass deterministisches und KI-gestütztes Scanning unterschiedliche Probleme auf verschiedenen Ebenen des Stacks lösen. Vom ersten Tag an haben wir uns dafür entschieden, das Tool zu verwenden, das in jedem Schritt die besten Ergebnisse lieferte.
Die deterministische Grundlage ist Opengrep, die Open-Source-Codeanalyse-Engine, die Aikido mitentwickelt und pflegt. Darüber hinaus haben wir eine Taint-Analyse und kuratierte Regelsätze entwickelt, die präzise genug sind, um direkt in CI/CD-Pipelines integriert zu werden, ohne Rauschen zu erzeugen.
Wo wir probabilistische Sicherheit schätzen, ist die Interpretation dieser Daten. KI-Reasoning sitzt auf der deterministischen Grundlage und löst Probleme, die Regeln nicht abbilden können. In Aikido geschieht dies durch AutoTriage, das nach den SAST-Scans ansetzt und Entscheidungen über Ausnutzbarkeit und Schweregrad trifft, die eine Regel-Engine allein nicht treffen kann.
AutoTriage läuft in zwei Phasen ab. Zuerst filtert Aikidos Reachability-Engine False Positives heraus, bevor ein LLM den Code überhaupt betrachtet. Es prüft, ob anfällige Codepfade tatsächlich erreichbar sind, ob eine Sanitisierung zwischen Source und Sink existiert und ob die betroffene Abhängigkeit in der Produktion oder nur in Tools oder Pipelines verwendet wird. Dieser erste Schritt allein unterdrückt einen erheblichen Teil der Alerts im Vergleich zu einem durchschnittlichen SAST-Scanner.
Für die komplexen Fälle, die diesen Filter überleben, kommen Reasoning-Modelle zum Einsatz und bewerten die Kontroll- und Datenflüsse im Kontext. Intern haben wir festgestellt, dass dieser Ansatz bei komplexen Fällen etwa doppelt so viele False Positives korrekt identifiziert wie nicht-reasoning-basierte Ansätze. Ein SQL-Injection-Befund könnte sicher herabgestuft werden, da die Eingabe von einer vertrauenswürdigen Upstream-Quelle stammt. Eine NoSQL-Injection an einem Login-Endpunkt wird auf kritisch hochgestuft, da der Angriffspfad trivial und der Impact direkt ist.
Der Grund, warum dies funktioniert, ist die Kontextkontrolle. Ein LLM über eine gesamte Codebasis laufen zu lassen und es nach Schwachstellen suchen zu lassen, führt zu inkonsistenten Ergebnissen. Das Modell verliert den Faden, weitet seine Vermutungen aus, und die False-Positive-Rate steigt. Aikidos Ansatz grenzt ein, was die KI sieht, bevor sie überhaupt Schlussfolgerungen zieht. Die Taint-Analyse verfolgt, wie benutzergesteuerte Daten durch die Anwendung fließen, und die Endpunkt-Awareness liefert dem Modell den vollständigen Stack-Trace und die Absicht des Codes. Ist dies eine Web-API? Ein Kommandozeilen-Tool? Was soll es tun? Mit diesem fest verankerten Kontext rät die KI nicht. Sie bewertet eine spezifische, begrenzte Frage. So erhält man KI-Reasoning-Leistung, ohne die Reproduzierbarkeit aufzugeben.
Schließlich haben wir festgestellt, dass KI-Modelle, da sie sich gut eignen, um komplexe und logikbasierte Angriffsmuster zu finden, für Pentesting äußerst effektiv sind. Aikido Attack ist KI-Penetrationstests, das probabilistisches Reasoning auf die Live-Anwendung anwendet. Agenten führen Tests in Stunden statt Wochen durch und finden regelmäßig tiefere Logikfehler, einschließlich IDORs, Auth-Bypasses und E-Signatur-Fälschungen, von denen einige sogar menschlichen Testern entgehen. Und jetzt, mit Aikido Infinite, können Agenten jede Release pentesten.
Für bestätigte True Positives, sei es aus SAST oder Pentesting, nutzt Aikido auch KI, um über die Lösung zu resonieren. AutoFix generiert einen gezielten Patch und öffnet einen Pull Request – eine weitere KI-Fähigkeit, die Reasoning und Kontext erfordert.
Bei Aikido sorgt der Determinismus für eine vorhersehbare Abdeckung in großem Maßstab. Die KI trifft die Ermessensentscheidungen, die Regeln nicht treffen können.
Was kommt als Nächstes?
Sicherheit benötigt sowohl deterministische Zuverlässigkeit als auch KI-Kreativität. Determinismus liefert konsistente, auditierbare und vertrauenswürdige Ergebnisse in großem Maßstab, während KI die Tiefe, Kreativität, Persistenz und das Reasoning bietet, um False Positives zu beseitigen, Rauschen zu reduzieren und ungewöhnliche Schwachstellen zu finden. Sowohl probabilistische als auch deterministische Tools haben Einschränkungen, aber das eigentliche Problem entsteht, wenn sie am falschen Ort eingesetzt werden. Es wird zu Problemen kommen, wenn man eine Reasoning-Engine für eine Aufgabe einsetzt, die einen Pattern-Matcher erfordert (oder umgekehrt).
Die übergeordnete Richtung ist klarer als jede einzelne Produktkategorie. Deterministische Tools werden besser, weil KI jetzt darüber sitzt und Priorisierung, Triage und Behebungen übernimmt, die Regeln allein nicht leisten könnten. Probabilistische Tools werden besser darin, komplexe Logikfehler und neuartige Angriffspfade zu finden, und mit der Zeit werden sie auch kosteneffizienter. Aber für kontinuierliche Baseline-Checks wird die Wirtschaftlichkeit des deterministischen Scannings nicht verschwinden. Man möchte etwas Schnelles, Konsistentes und Günstiges, das bei jedem Commit läuft, und das ist immer noch ein Pattern-Matcher.
Die Teams, die die robusteste Sicherheitslage aufbauen, sind diejenigen, die sowohl deterministische als auch probabilistische Tools in der richtigen Reihenfolge und an den richtigen Stellen einsetzen, anstatt nur auf eines zu setzen.
