Deterministische Sicherheitstools sind mittlerweile so selbstverständlich geworden, dass wir lange Zeit keine Alternativen in Betracht gezogen haben. Da KI mit probabilistischen Modellen zu einer Kernkomponente der Sicherheit geworden ist, ist es an der Zeit, den Determinismus zu überdenken und sich darüber klar zu werden, wofür er benötigt wird. Warum sollten wir nicht einfach alles durch KI ersetzen?
Kurz gesagt, wir brauchen Determinismus wegen seiner Vorhersagbarkeit und Effizienz. Deterministische Tools wie SAST jedes Mal, wenn Sie sie auf dasselbe Objekt anwenden, dasselbe Ergebnis – und das auf effiziente Weise. Daher sind sie in einer CI/CD-Pipeline nützlich, in einem compliance vertretbar und bilden die Grundlage für alles andere. KI ist hervorragend für logisches Denken geeignet, sollte aber aufgrund ihrer Unvorhersehbarkeit am besten für Fälle reserviert werden, in denen Sie keine wiederholbaren Ergebnisse benötigen.
Da immer mehr probabilistische Tools auf den Markt kommen, möchten wir aufschlüsseln, wie Determinismus nachhaltige Sicherheitspraktiken schafft, wie KI neue Möglichkeiten eröffnet und wie beide kombiniert werden können, um eine maximale Wirkung zu erzielen.
Wenn Sicherheitstools vorhersehbar sein müssen
Einige Sicherheitsaufgaben erfordern vor allem Konsistenz und Überprüfbarkeit. Wir sehen diesen Bedarf an Vorhersehbarkeit im gesamten Sicherheits-Workflow.
Wenn ein Scanner einen Befund meldet, muss ein Entwickler diesem Befund so weit vertrauen, dass er um 23 Uhr entsprechend handeln kann. Wenn eine CI/CD-Pipeline eine Bereitstellung blockiert, muss diese Blockierung einer genauen Prüfung standhalten. In einer Pipeline wird Ihr Scanner bei jedem Commit oder Pull-Request ausgeführt. Wenn er am Montag 12 Probleme und am Dienstag 9 Probleme bei identischem Code meldet, ist das nicht gut. Die Ergebnisse Ihrer Pipeline sind nicht mehr vertrauenswürdig. Entwickler beginnen, Warnmeldungen zu ignorieren, weil die Signale inkonsistent sind, und Sie können die Scan-Ergebnisse nicht mehr als aussagekräftiges Kriterium für Merges verwenden.
Ebenso hängt das Regressionstesten 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 bei diesem Durchlauf übersehen hat. Auch die Basis- und Drift-Erkennung hängt davon ab, da sie wissen müssen, ob eine neue Entdeckung eine echte Änderung in der Codebasis widerspiegelt oder nur eine Abweichung im Scanner.
Vorhersehbarkeit ist auch für compliance erforderlich. Auditoren wünschen sich konsistente, nachvollziehbare Ergebnisse über einen längeren Zeitraum hinweg, mit einer klaren Aufzeichnung dessen, was wann und warum entdeckt wurde. Ein Scanner, der bei verschiedenen Durchläufen unterschiedliche Ergebnisse liefert, kann dies nicht gewährleisten.
Die praktischen Kosten der Unzuverlässigkeit im Bereich Sicherheit untergraben langsam das Vertrauen in die Tools selbst, bis niemand mehr die Ergebnisse ernst nimmt. Reproduzierbarkeit, Überprüfbarkeit und niedrige Falsch-Positiv-Raten müssen die Grundlage sein, auf die sich ein Sicherheitsteam verlassen kann.
Deterministische Sicherheitstools
SAST ein typisches deterministisches Sicherheitstool, das nach bekannten Mustern und Schwachstellen sucht. Denken Sie dabei an fest codierte secrets, bekannte CVEs, Abhängigkeitsschwachstellen und Injektionsmuster. Es funktioniert, indem es Code in einen abstrakten Syntaxbaum zerlegt und verfolgt, wie benutzergesteuerte Daten durch die Anwendung von den Einstiegspunkten bis zu ihrem Verwendungsort wandern. Ein Fundstück lässt sich auf eine bestimmte Regel zurückführen, die von einem Menschen geschrieben und überprüft wurde, und die Regel passt entweder oder sie passt nicht. Wenn Sie denselben Scanner tausend Mal auf denselben Code anwenden, erhalten Sie dieselben Ergebnisse.
Wiederholbarkeit ist das, was deterministische Tools für den Anfang einer Pipeline so gut geeignet macht (sie sind konsistent). Sie sind überprüfbar, weil die Regeln von Menschen geschrieben wurden, und man kann sie bei jedem Commit ausführen, ohne sich Gedanken darüber machen zu müssen, dass dies zu teuer wird.
Auch DAST am deterministischen Ende des Spektrums. Es führt eine definierte Reihe von Angriffssimulationen gegen eine Live-Anwendung durch und liefert konsistente, wiederholbare Ergebnisse. Es handelt sich um eine nützliche Basisprüfung, da sie KI-Penetrationstests derzeit) schneller und kostengünstiger ist als KI-Penetrationstests . Wie jedes deterministische Tool findet es jedoch nur das, wofür es einen Test hat.
Wir behaupten keineswegs, dass deterministische Sicherheit oder auch nur vorhersehbare Ergebnisse immer besser sind. Die Kehrseite dessen, was deterministische Tools zuverlässig macht, ist auch ihre Grenze. Sie finden nur das, wofür sie eine Regel haben. Neuartige Angriffsmuster, nuancierte Logikfehler und Schwachstellen, die ein Verständnis des Geschäftskontexts erfordern, liegen daher außerhalb des Erfassungsbereichs eines deterministischen Scanners.
Deterministische Tools allein können Ihnen auch nicht sagen, welche Probleme im Kontext wichtiger sind. Einige deterministische Tools umfassen Erreichbarkeitsanalyse grundlegende Erreichbarkeitsanalyse im Wesentlichen statische Call-Graph-Verfolgung), mit der bestätigt werden kann, ob eine anfällige Funktion tatsächlich aufgerufen wird. Aber wenn wir wissen möchten, ob diese Erkenntnis in unserer spezifischen Anwendung angesichts unserer Datenflüsse und Geschäftslogik ausnutzbar ist? Nun, diese Art der Erreichbarkeitsanalyse Priorisierung erfordert eine über das Pattern Matching hinausgehende Argumentationsebene.
Probabilistische Sicherheitswerkzeuge
Dank des Aufkommens von LLMs verfügen wir nun über neue KI-gestützte Sicherheitstools wie KI-Scanner, automatisierte triage und agentenbasiertes Pentesting, die von Natur aus probabilistisch sind. Probabilistische Tools (oder modellorientierte Tools) arbeiten nicht nach festen Regeln. Stattdessen behandeln sie Code als Text und analysieren ihn.
Da sie nicht an feste Muster gebunden sind, folgt eine KI der Logik über Funktionen hinweg, leitet Absichten ab und kann Schwachstellen aufdecken. Um Fehler in der Geschäftslogik zu erkennen, muss man verstehen, was der Code zu leisten versucht, und nicht nur, was er wörtlich aussagt. Probabilistische Tools sind darin besonders gut, und die KI wird immer besser. KI kann neue Klassen von Schwachstellen und kontextabhängige Fehler finden, für deren Entdeckung bisher die Überprüfung durch einen erfahrenen Menschen erforderlich war.
Aufgrund ihrer Natur sind diese probabilistischen Modelle jedoch unvorhersehbar und inkonsistent. Die Ergebnisse können (und werden wahrscheinlich) zwischen den Durchläufen variieren. LLMs generieren Ergebnisse, indem sie das wahrscheinlichste nächste Token auf der Grundlage von Wahrscheinlichkeitsverteilungen über ihre Trainingsdaten vorhersagen. Das bedeutet, dass dieselbe Eingabe je nach Temperatur, Sampling-Verhalten und dem, was sich sonst noch im Kontextfenster befindet, zu unterschiedlichen Ergebnissen führen kann. Diese Variation ist für Pentests und die Suche nach neuen Schwachstellen in Ordnung, sogar hilfreich. Für Ihre CI/CD-Pipelines ist sie es jedoch nicht.
Es gibt auch ein Kostenproblem, wenn man versucht, ein probabilistisches Schlussfolgerungsmodell als pauschalen Code-Scanner für jeden Commit zu verwenden. James Berthoty von Latio führte einige informelle Tests durch, die zeigten, dass ein probabilistisches KI-Modell 17 Minuten und 155.000 Token benötigte, um ein Problem aufzudecken, das Opengrep, eine deterministische SAST , in 30 Sekunden gefunden hatte. Bei jedem Pull-Request in einer aktiven Codebasis ist dieser Tausch nicht sinnvoll.
Warum wir beides brauchen
Wenn man jedoch deterministische und probabilistische Modelle kombiniert und die Stärken jeder Methode nutzt, erhält man eine Sicherheitspipeline, deren Ganzes größer ist als die Summe ihrer Teile. In der Praxis möchte man, dass bei jedem Commit ein deterministischer Scan durchgeführt wird, der bekannte Schwachstellenklassen schnell und konsistent erkennt, und dass dann die KI-Logik darüber liegt und triage den Kontext übernimmt.
Zusammen decken sie das Spektrum von „was wir als gefährlich kennen“ bis hin zu „was wir noch nicht zu suchen gewagt haben“ ab. Wir gehen davon aus, dass die letztere Kategorie wachsen wird. Da KI zunehmend in Codebasen eingebettet wird und Angreifer Zugang zu denselben Denkfähigkeiten erhalten, werden für viele Schwachstellen noch keine Regeln geschrieben sein, sodass wir Tools benötigen, die damit Schritt halten können.
Ein weiterer Grund, warum Sie beide Tools benötigen, ist, dass sie dieselben Probleme auf unterschiedlichen Ebenen abdecken. DAST KI-Penetrationstests arbeiten beispielsweise auf verschiedenen Ebenen desselben Problems. DAST für schnelle, deterministische Überprüfungen, die kontinuierlich durchgeführt werden müssen. Sie müssen so schnell wie möglich wissen, ob Sie offensichtliche offene Ports oder Seiten haben, die nicht öffentlich sein sollten. KI-Penetrationstests langsamer und kosten pro Durchlauf mehr, arbeiten jedoch auf einer grundlegend anderen Ebene. Ein IDOR, für dessen Erreichen drei authentifizierte Schritte erforderlich sind, wird in einem DAST nicht angezeigt, aber in einem guten KI-Penetrationstest. Mit DAST können Sie die einfachen Dinge schnell aus dem Weg räumen, während KI-Penetrationstests um die komplexeren Dinge KI-Penetrationstests .
Wie Aikido beides Aikido
Wir haben Aikido der Prämisse aufgebaut, dass deterministisches und KI-gestütztes Scannen unterschiedliche Probleme auf verschiedenen Ebenen des Stacks lösen. Von Anfang an haben wir uns dafür entschieden, das Tool zu verwenden, das bei jedem Schritt die besten Ergebnisse lieferte.
Die deterministische Grundlage bildet Opengrep, die Open-Source-Codeanalyse-Engine, die Aikido und wartet. 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 Störungen zu verursachen.
Was wir an probabilistischer Sicherheit lieben, ist die Möglichkeit, diese Daten zu interpretieren. KI-Argumentationen basieren auf deterministischen Grundlagen und lösen Probleme, die sich nicht durch Regeln abbilden lassen. Bei Aikido geschieht dies durch AutoTriage, das nach SAST zum Einsatz kommt und Entscheidungen über die Ausnutzbarkeit und Schwere von Sicherheitslücken trifft, die eine Regel-Engine allein nicht treffen kann.
AutoTriage läuft in zwei Stufen ab. Zunächst filtert die Erreichbarkeits-Engine Aikido Fehlalarme heraus, bevor ein LLM den Code überhaupt überprüft. Sie prüft, ob anfällige Codepfade tatsächlich erreichbar sind, ob zwischen Quelle und Senke eine Bereinigung stattfindet und ob die betroffene Abhängigkeit in der Produktion oder nur in Tools oder Pipelines verwendet wird. Allein dieser erste Schritt unterdrückt im Vergleich zu einem durchschnittlichen SAST einen erheblichen Teil der Warnmeldungen.
Bei komplexen Fällen, die diesen Filter passieren, kommen Argumentationsmodelle zum Einsatz, die die Kontroll- und Datenflüsse im Kontext bewerten. Intern haben wir festgestellt, dass dieser Ansatz bei komplexen Fällen etwa doppelt so viele Fehlalarme korrekt identifiziert wie Ansätze ohne Argumentation. Ein SQL-Injection-Befund kann sicher herabgestuft werden, da die Eingabe aus einer vertrauenswürdigen vorgelagerten Quelle stammt. Eine NoSQL-Injection an einem Login-Endpunkt wird auf kritisch hochgestuft, da der Angriffspfad trivial und die Auswirkungen direkt sind.
Der Grund dafür ist die Kontextsteuerung. Wenn man ein LLM über eine gesamte Codebasis laufen lässt und es auffordert, Schwachstellen zu finden, führt dies zu inkonsistenten Ergebnissen. Das Modell verliert den Faden, erweitert seine Vermutungen und die Fehlalarmquote steigt. Der Ansatz Aikido schränkt das ein, was die KI sieht, bevor sie überhaupt zu einer Schlussfolgerung kommt. Die Taint-Analyse verfolgt, wie benutzergesteuerte Daten durch die Anwendung fließen, und die Endpunkt-Erkennung liefert dem Modell den vollständigen Stack-Trace und die Absicht des Codes. Handelt es sich um eine Web-API? Ein Befehlszeilentool? Was soll es tun? Mit diesem festgelegten Kontext muss die KI nicht raten. Sie bewertet eine spezifische, begrenzte Frage. So erhalten Sie die Schlussfolgerungsfähigkeit der KI, ohne die Reproduzierbarkeit aufzugeben.
Da KI-Modelle sich gut dafür eignen, komplexe und logikbasierte Angriffsmuster zu finden, haben wir festgestellt, dass sie für Penetrationstests sehr effektiv sind. Aikido ist KI-Penetrationstests probabilistisches Denken auf die Live-Anwendung anwendet. Agenten führen Tests innerhalb von Stunden statt Wochen durch und finden regelmäßig tiefere Logikfehler, darunter IDORs, Authentifizierungsumgehungen und Fälschungen von elektronischen Signaturen, von denen einige sogar menschlichen Testern entgehen. Und jetzt, mit Aikido , können Agenten jedes Release pentesten.
Bei bestätigten echten Positiven, die durch SAST Pentesting ermittelt wurden, nutzt Aikido KI, um die Lösung zu begründen. AutoFix generiert einen gezielten Patch und öffnet einen Pull-Request, eine weitere KI-Funktion, die Begründungen und Kontext erfordert.
Bei Aikido sorgt Determinismus für vorhersehbare Abdeckung in großem Maßstab. KI übernimmt die Entscheidungen, die Regeln nicht treffen können.
Was kommt als Nächstes?
Sicherheit erfordert sowohl deterministische Zuverlässigkeit als auch KI-Kreativität. Determinismus liefert konsistente, überprüfbare und vertrauenswürdige Ergebnisse in großem Maßstab, während KI die Tiefe, Kreativität, Ausdauer und Argumentationskraft bietet, um Fehlalarme zu beseitigen, Störsignale zu reduzieren und ungewöhnliche Schwachstellen zu finden. Sowohl probabilistische als auch deterministische Tools haben ihre Grenzen, aber das eigentliche Problem entsteht, wenn sie am falschen Ort eingesetzt werden. Es kommt zu Problemen, wenn Sie eine Schlussfolgerungs-Engine für eine Aufgabe einsetzen, die einen Musterabgleicher erfordert (oder umgekehrt).
Die allgemeine Richtung ist klarer als jede einzelne Produktkategorie. Deterministische Tools werden immer besser, da sie nun durch KI ergänzt werden, die Priorisierungen, triage und Korrekturen übernimmt, die mit Regeln allein nicht möglich wären. Probabilistische Tools werden immer besser darin, komplexe Logikfehler und neuartige Angriffswege zu finden, und mit der Zeit werden sie auch kosteneffizienter werden. Für kontinuierliche Basisüberprüfungen bleibt jedoch die Wirtschaftlichkeit deterministischer Scans bestehen. Sie benötigen etwas Schnelles, Konsistentes und Kostengünstiges, das bei jedem Commit ausgeführt wird, und das ist nach wie vor ein Mustervergleicher.
Die Teams, die die robusteste Sicherheitsstrategie entwickeln, sind diejenigen, die sowohl deterministische als auch probabilistische Tools in der richtigen Reihenfolge und an den richtigen Stellen einsetzen, anstatt sich auf eines davon zu verlassen.
