Es gibt mittlerweile vier grundlegend unterschiedliche Methoden, um nach Schwachstellen in einer Anwendung zu suchen, wobei jede Methode etwas prüft, was die anderen aufgrund ihrer Struktur nicht leisten können. Das Spektrum reicht vom musterbasierten Abgleich (bekannt als traditionelles „ SAST “, bei dem Code anhand bekannter Muster überprüft wird) bis hin zu tiefgreifenden agentischen Überprüfungen. Bei diesen agentenbasierten Überprüfungen handelt es sich entweder um „Early Signals“ (Deep PR Reviews), die analysieren, wie eine Änderung mit Code an anderer Stelle im Repository interagiert, um „ KI-Codeanalyse “ (im Markt oft als„AI- SAST “bezeichnet), die die Logik einer Codebasis analysieren, ohne irgendwo bereitgestellt werden zu müssen, oder um„ KI-Penetrationstests“, die auf dieselbe Weise vorgehen, jedoch an einem live laufenden Ziel, und ihre Ergebnisse durch den Versuch, die Schwachstelle auszunutzen, nachweisen. Dieser Beitrag hilft Ihnen dabei, zu verstehen, welches Tool für welchen Anwendungsfall am besten geeignet ist.
TL:DR
Diese vier sind keine Konkurrenten. Jedes funktioniert anders, nicht nur in unterschiedlichen Tiefen. „ SAST “ ist deterministisch: Der gleiche Code liefert immer das gleiche Ergebnis, allerdings nur für Muster, die ihm bereits bekannt sind. „Deep PR Review“, „ KI-Codeanalyse “ und „AI Pentest“ hingegen analysieren Logik und Absicht und decken so in unterschiedlichen Bereichen und an verschiedenen Punkten im Lebenszyklus Probleme auf, die „ SAST “ strukturell nicht erkennen kann.
Abdeckung: SAST. Umfassend, kontinuierlich und kostengünstig. Es wird bei jedem Commit, Pull-Request und bekannten Muster ausgeführt. Dies ist Ihr Tor. Es ist auch in der IDE sehr wertvoll, wo es ausgeführt werden kann, während der Entwickler oder Agent Code erstellt, sodass Sie Feedback erhalten, noch bevor Code überhaupt committet wird.
Frühwarnsignal: Gründliche PR-Prüfung. Erläuterungen zur Geschäftslogik bei jedem Pull-Request, Erkennung von IDORs ( fehlerhafte Zugriffskontrolle) und anderen Schwachstellen, die sowohl von „ SAST “ als auch bei einer schnellen manuellen Überprüfung übersehen werden. Dabei wird jede Änderung unmittelbar nach ihrer Eröffnung überprüft und analysiert, welche Auswirkungen diese Änderung an anderen Stellen im Code hat.
Vertrauen: KI-Codeanalyse. Die gleiche Vorgehensweise wie bei der „Deep PR Review“, jedoch auf das gesamte Repository angewendet statt auf einzelne Änderungen. Durch diese Reichweite eignet sich diese Ebene besonders für bedeutende Änderungen und schwer zu testende Ziele, da sie echte Logikfehler aufdeckt, lange bevor überhaupt ein Live-Ziel zum Testen vorliegt.
Beweis: KI-Penetrationstest. Dieselbe Argumentation, validiert anhand eines Live-Systems durch echte Exploitation. Dies liefert eindeutige Beweise statt einer Schätzung, weshalb es auch die Anforderungen des „ compliance “ erfüllt.
Zusammen decken sie den gesamten Lebenszyklus ab: jeden Commit, jede wesentliche Änderung und jede Version, die einer Überprüfung bedarf. Im Folgenden wird erläutert, was die einzelnen Ebenen in der Praxis abdecken, beginnend mit der Basisebene.
Was „ SAST “ testet: bekannte Muster, deterministisch
Statische Anwendungssicherheitstests Erkennt Muster, beispielsweise einen fehlerhaften Parameter, der in einen Datenbankaufruf gelangt. Wenn Sie denselben Code zweimal durch das Tool laufen lassen, erhalten Sie genau dasselbe Ergebnis.
Die Einschränkung besteht darin, dass sie nicht in der Lage ist, Schlussfolgerungen zu ziehen. Eine Regel-Engine verfügt über kein Modell davon, was die Anwendung tatsächlich tut. Stattdessen liest sie den Code Zeile für Zeile durch, gleicht ihn mit bereits bekannten Mustern ab und kann vertrauenswürdige Daten nicht von nicht vertrauenswürdigen unterscheiden, während diese Daten durch die Anwendung fließen.
Nehmen wir das klassische Beispiel einer SQL-Injection: Eine Benutzereingabe, die direkt in eine Abfrage eingefügt wird. Das kommt zwar immer noch vor, sieht in ausgereiftem Code aber selten so „sauber“ aus. Nicht vertrauenswürdige Daten gelangen in der Regel an einer harmlosen Stelle ins System, beispielsweise über einen „ “-Request-Header, und durchlaufen dann mehrere, nicht miteinander in Zusammenhang stehende Funktionen, bevor sie eine Zielstelle erreichen und dort – oft mehrere Ebenen weiter unten – gefährlich werden. Ein auf Musterabgleich basierender Scanner kann diesem Pfad nicht folgen. Er kann vertrauenswürdige Daten nicht von nicht vertrauenswürdigen trennen, während sich die Daten weiterbewegen, und markiert daher alles, was einer Injection ähnelt – unabhängig davon, ob ein Angreifer diese Stelle jemals erreichen könnte oder nicht. Diese Markierungen für unerreichbare Stellen sind die Ursache für das Rauschen und der Grund, warum der Musterabgleich dem „ SAST “ seinen Ruf für Fehlalarme eingebracht hat.
Das bedeutet jedoch nicht, dass „ SAST “ nicht genutzt werden sollte. Wenn „ SAST “ am Montag zwölf Probleme und am Dienstag neun Probleme bei identischem Code meldet, verlieren die Entwickler das Vertrauen in das Tool. Untersuchungen zeigen, dass 65 % der Teams angeben, dass Fehlalarme sie zu riskantem Verhalten zwingen – sei es das Aufschieben von Fehlerbehebungen, das Ignorieren von Warnmeldungen oder das Umgehen von Prüfungen –, obwohl die AutoTriage-Funktion von Aikido speziell darauf ausgelegt ist, solche Störsignale herauszufiltern, bevor sie einen Entwickler erreichen. Selbst mit diesem Aufwand lässt sich SAST immer noch kostengünstig genug betreiben, um jeden Commit zu überprüfen – und genau das ist es, was CI/CD, Regressionstests und compliance benötigen.
Deep PR prüft die Gründe für eine Änderung, bevor sie übernommen wird
Wenn man einen Diff nur für sich betrachtet, übersieht man, wie sich diese Änderung verhält, sobald sie auf den Rest der Anwendung trifft. Deep PR Review (in der Branche oft als „AI Code Review“ bezeichnet) wurde entwickelt, um über den Diff hinauszuschauen. Anstatt eine Änderung isoliert zu beurteilen, analysiert das Tool, wie diese Änderung mit Code an anderen Stellen im Repository interagiert, einschließlich gemeinsam genutzter Bibliotheken und Dienste in verknüpften Repos. Im Grunde ist das genau das, was man von einem erfahrenen Entwickler erwarten würde, wenn dieser die Kapazität hätte, tatsächlich jede Abhängigkeit nachzuverfolgen, bevor er einen PR genehmigt (Wunschdenken). Auf diese Weise lassen sich Fehler wie „Crossover-Datenlecks“ oder „ fehlerhafte Zugriffskontrolle “ aufdecken – Fehler in der Geschäftslogik, die weder durch eine schnelle manuelle Überprüfung noch durch ein Tool zum Musterabgleich erkannt werden könnten, da sie allein anhand der geänderten Zeilen nicht sichtbar sind.
Dies sind in der Regel genau die Art von Befunden, die sonst erst bei einem Penetrationstest oder in der Produktion auftauchen würden – Wochen oder Monate nach der Erstellung des Codes, wenn der Autor bereits das Unternehmen verlassen hat und den Kontext nicht mehr kennt, um die Entscheidung zu erklären. Deep Review verlagert diese Befunde in eine frühere Phase, nämlich direkt in den Pull-Request selbst, sodass sich der Autor der Änderung noch daran erinnert, warum er den Code so geschrieben hat. Feedback kann direkt im PR gegeben werden, sodass Angaben wie „Das ist beabsichtigt“ oder „Das ist ein Fehlalarm“ für Klarheit sorgen, ohne dass man das Tool wechseln oder die Überprüfung verlassen muss.
KI-Codeanalyse prüft die Absicht und die Logik, ohne eine Live-Umgebung
Anstatt Muster abzugleichen, liest „ KI-Codeanalyse “ (im Markt oft als „AI- SAST “ bezeichnet) Ihren Quellcode und analysiert ihn so, wie es ein erfahrener Entwickler bei einer Code-Prüfung tun würde. Es verfolgt Verweise über Dateien hinweg, verfolgt eine Anfrage vom Route-Handler bis hinunter zur Datenbankabfrage und prüft, ob der Code das tut, was er soll. Dies ist sowohl für ein einzelnes Repository als auch für mehrere miteinander verbundene Repositories möglich, einschließlich Monorepos, die Frontend, Backend und Infrastructure-as-Code umfassen. Dazu benötigt es lediglich Zugriff auf das Repo.
Durch logisches Schlussfolgern lassen sich Fehler in der Geschäftslogik aufdecken – etwas, wozu „ SAST “ nicht in der Lage ist. IDORs sind hierfür ein gutes Beispiel, da logisches Schlussfolgern erforderlich ist, um zu erkennen, ob ein Endpunkt auf den anfragenden Benutzer beschränkt sein sollte oder nicht. Das Ändern einer Benutzer-ID, um das öffentliche Profil einer Person anzuzeigen, könnte ein erwartetes Verhalten sein. Das Ändern derselben ID, um deren private Nachrichten oder Kontoeinstellungen einzusehen, stellt hingegen eine Sicherheitsverletzung dar. Diese Unterscheidung hängt davon ab, was der Endpunkt durchsetzen soll, und nicht von der Ressource selbst – etwas, wofür man keine statische Regel schreiben kann.
Dafür ist auch kein Live-Ziel erforderlich. Sie müssen keine Staging-Umgebung einrichten (d. h. kein konfigurierter Authentifizierungsablauf), da die Überprüfung direkt am Code-Repo durchgeführt wird. Dadurch kann sie auf Bereiche zugreifen, die bei einem Live-Penetrationstest nicht erreichbar sind, wie beispielsweise Code hinter einem Feature-Flag, Routen, die nur für Administratoren zugänglich sind und für die keine Anmeldedaten angegeben werden, sowie Denial-of-Service-Muster, deren Ausführung auf einem Produktionssystem nicht sicher wäre. Die gleiche Argumentation lässt sich auf mobile Apps, Smart Contracts, Desktop-Anwendungen und im Grunde jede Programmiersprache anwenden, einschließlich älterer oder Nischen-Sprachen, für deren Unterstützung ein regelbasierter Scanner nie entwickelt wurde.
Dies ist dieselbe Art der Analyse, die „Deep PR Review“ auf PR-Ebene anwendet, mit dem Unterschied, dass „Deep PR Review“ bei jeder Änderung Probleme aufdeckt, indem es einen Pull-Request mit der gesamten Codebasis abgleicht. „ KI-Codeanalyse “ hingegen analysiert die gesamte Codebasis auf einmal, weshalb es sich am besten für größere Änderungen und vollständige Releases eignet (es ist der empfohlene „Erste Schritte“-Schritt), während „Deep PR Review“ anschließend die fortlaufende Analyse auf PR-Ebene übernimmt.
Man sollte sich darüber im Klaren sein, warum dies nicht dasselbe ist, wie ein Modell direkt zu bitten, den Code zu überprüfen. Ein direkt befragtes Modell liefert lediglich eine allgemeine Überprüfung, die eher dem flüchtigen Überfliegen durch einen Entwickler auf offensichtliche Fehler gleicht als einer gründlichen Überprüfung. „ KI-Codeanalyse “ bindet dasselbe Modell in ein Framework ein, das eine Erkundung durchführt, parallel nach Fehlern sucht und jedes Repository unabhängig validiert – und genau diese Koordination ist für den Großteil des Unterschieds bei der Anzahl der tatsächlich gefundenen Fehler verantwortlich.
Der Kompromiss zwischen herkömmlichen „ SAST “ und „ KI-Codeanalyse “ betrifft nicht nur die Kosten. Das Durchdenken einer gesamten Codebasis erfordert mehr Rechenleistung und Zeit als der Musterabgleich, und da keine laufende Anwendung zur Verfügung steht, werden die Ergebnisse danach priorisiert, wie wahrscheinlich es ist, dass sie tatsächlich zutreffen, anstatt durch Ausführung bestätigt zu werden. Die Geschwindigkeit und der Determinismus von „ SAST “ ermöglichen es, diese Funktion direkt in CI/CD zu integrieren, weshalb „ KI-Codeanalyse “ sich am besten für bedeutende Änderungen und größere Releases eignet und nicht für jeden einzelnen Commit. Doch die Kosten und die Effizienz agentenbasierter Funktionen verbessern sich kontinuierlich, sodass all diese KI-Fähigkeiten für Unternehmen bald zur Selbstverständlichkeit werden.
KI-Penetrationstests liest Ihren Code und führt ihn in Ihrer App aus
KI-Penetrationstests, worum es sich bei „ Aikido -Attack“ handelt, basiert auf demselben grundlegenden Ansatz wie „ KI-Codeanalyse “. Pentesting geht jedoch noch einen Schritt weiter, indem es gegen eine live laufende Anwendung durchgeführt wird. Das bedeutet, dass es tatsächliche Exploits versuchen kann, indem Agenten echte Anfragen senden und eine reale Angriffsfläche abbilden.
Durch diese Validierung in Echtzeit wird das Problem der Fehlalarme größtenteils beseitigt (darauf werden wir im nächsten Abschnitt näher eingehen). „ KI-Codeanalyse “ kann anhand des Codes erkennen, dass offenbar ein Fehler in der Geschäftslogik wie IDOR vorliegt; bei einem Penetrationstest kann der Exploit gegen das laufende System getestet und bestätigt werden, ob er tatsächlich funktioniert.
Ein Penetrationstest erfordert eine stabile Umgebung, eine funktionierende Authentifizierung und bereits eingerichtete, realistische Benutzerrollen – allesamt Voraussetzungen, die KI-Codeanalyse nicht benötigt, da es direkt aus der Quelle liest. Sobald diese Umgebung vorhanden ist, läuft der Test selbst schnell ab, doch die Verarbeitung von Live-Datenverkehr und die Ermittlung der tatsächlichen Auswirkungen einer bestimmten Interaktion verursachen pro Durchlauf immer noch höhere Kosten als die Analyse von Text. Aus diesem Grund liegt ein Penetrationstest hinsichtlich der Rechenkosten sowohl über SAST als auch über KI-Codeanalyse .
Ein KI-Penetrationstest ist zudem der einzige dieser drei Tests, der die Anforderungen der „ compliance “ für Rahmenwerke wie SOC 2 und ISO 27001 hinsichtlich eines Live-Penetrationstests erfüllt. Ein „ KI-Codeanalyse “ kann einen Live-Penetrationstest nicht ersetzen, wenn dieser gemäß „ compliance “ vorgeschrieben ist, doch kann seine Durchführung im Vorfeld dennoch von Vorteil sein. Werden logische Schwachstellen bereits vor dem auditierten Penetrationstest beseitigt, führt dies zu weniger Befunden, die beim Live-Test aufgedeckt werden müssen, und damit zu geringeren Kosten pro Auftrag.
Es ist außerdem erwähnenswert, dass die Gewährung von Zugriff auf den Quellcode für einen Pentest-Agenten (sogenanntes Whitebox-Testing) erhebliche Auswirkungen auf die Ergebnisse (und die damit verbundenen Kosten) hat. Bei mehr als 1.000 KI-Pentests, die auf der Plattform von Aikidodurchgeführt wurden, ergaben Tests mit Codezugriff (Whitebox) im Median siebenmal mehr schwerwiegende und kritische Befunde als Tests ohne Codezugriff (Greybox) – und das bei etwa der Hälfte der Rechenkosten pro Befund. Beim Greybox-Testing waren 31 Agent-Starts erforderlich, um eine einzige Schwachstelle aufzudecken, gegenüber 15 beim Whitebox-Testing. Durch die effektive Kombination beider Ansätze – der Analyse anhand des Quellcode-Zugriffs unter KI-Codeanalyse und der Live-Ausnutzung unter KI-Penetrationstests – erhalten Sie somit ein umfassenderes Bild als bei der alleinigen Anwendung einer der beiden Methoden. Dies lässt sich ganz einfach über die Auswahl „Whitebox“ in der Benutzeroberfläche für den „ Aikido -Angriff“ einstellen.
Wenn Sie sich nicht sicher sind, wie Sie Produkte für KI-basierte Penetrationstests bewerten sollen, lesen Sie unseren Einkaufsratgeber.
Warum es zu mehr Fehlalarmen kommt
KI-Codeanalyse Es kann Ihren Code analysieren, ohne ihn auszuführen. Es erkennt, dass eine Anfrage eine gefährliche Operation erreicht und dass nichts auf dem Weg dorthin diese stoppt, und kennzeichnet dies als ausnutzbar. Da es mit dem Quellcode statt mit einem Live-Ziel arbeitet, wird sich bei einigen der von ihm markierten Stellen herausstellen, dass sie durch etwas geschützt sind, das das Modell allein anhand des Repositorys nicht erkennen konnte.
Ein Penetrationstest ergänzt diese Argumentation um die Ausnutzung in einer Live-Umgebung. Dabei wird die vermutete Schwachstelle gegen die laufende Anwendung ausgenutzt und es wird berichtet, was tatsächlich erfolgreich war – weshalb die Ergebnisse nicht auf Schätzungen beruhen, sondern durch Beweise untermauert sind.
Wenn man beides ausführt, wird die Lücke in beide Richtungen geschlossen. KI-Codeanalyse erreicht Code, den ein Penetrationstest niemals berührt, wie beispielsweise alles, was sich hinter einem Feature-Flag oder einer Admin-Route ohne Anmeldedaten befindet. Ein Penetrationstest bestätigt, was KI-Codeanalyse aufdeckt, sobald ein live geschaltetes Ziel zum Testen vorliegt.
Welches brauchst du?
Ausgaben an das Risiko anpassen
Das Budget und die Risikotoleranz bestimmen, welchen Anteil Ihres Vermögens die einzelnen Anlageinstrumente abdecken sollen.
Ein kleines Team erhält allein durch „ KI-Codeanalyse “ eine solide und kosteneffiziente Basis, die gegen bestehenden Code ausgeführt wird, um bisher unbemerkt gebliebene Fehler aufzudecken. Es muss zunächst keine Umgebung eingerichtet und keine Authentifizierung konfiguriert werden, wodurch diese Ebene bereits Risiken abdecken kann, noch bevor andere Komponenten bereitstehen. Durch die anschließende Einbindung einer gründlichen PR-Prüfung wird sichergestellt, dass diese Basis auch bei der Veröffentlichung neuen Codes nicht vernachlässigt wird, sodass Probleme in der Geschäftslogik bei jedem Pull-Request erkannt werden, ohne dass eine Live-Umgebung oder ein planmäßiger Penetrationstest-Zyklus erforderlich ist.
Ein KI-Pentest (Aikido -Attack) erfolgt oberhalb der Schlussfolgerungsebenen als regelmäßige Live-Validierung, in der Regel jährlich oder bei größeren Releases, und überprüft dabei die gesamte Umgebung und Konfiguration und nicht nur den Code. Die meisten Unternehmen führen KI-Pentests in diesem Rhythmus durch, oft um Anforderungen im Rahmen von „ compliance “ wie SOC 2 oder ISO 27001 zu erfüllen. Kontinuierliche „ KI-Penetrationstests “ (Aikido Infinite) bilden darüber hinaus eine separate Ebene für Teams, deren Sicherheitslage eine fortlaufende Überprüfung der Ausnutzbarkeit erfordert – und nicht nur in festgelegten Intervallen –, unabhängig von der Unternehmensgröße.
Die meisten Teams befinden sich irgendwo in diesem Entwicklungsprozess, wobei die eigentliche Frage im Scoping liegt: Welche Repos und Releases rechtfertigen einen geplanten Penetrationstest, und welche können durch „ KI-Codeanalyse “ und „Deep PR Review“ im Tagesgeschäft abgedeckt werden? Die vorrangige Durchführung der Analysephasen und die Behebung von Schwachstellen vor dem Penetrationstest ist eine Möglichkeit, den Aufwand effizienter zu nutzen, da ein „saubereres“ Ziel weniger Befunde im Penetrationstest bedeutet – denn Probleme, die bereits im Vorfeld kostengünstiger behoben wurden, müssen nicht erneut untersucht werden.
Betrachten Sie dies als Ausgangswert, den die Teams entsprechend ihrem eigenen Risikoprofil anpassen.
Zusammenfassend lässt sich sagen, dass
In der Praxis bedeutet eine Abdeckung des gesamten Lebenszyklus, dass alle vier Komponenten je nach Ihren aktuellen Anforderungen gemeinsam eingesetzt werden. „ SAST “ deckt jeden Commit und jeden Pull-Request ab und läuft kontinuierlich. „Deep PR Review“ überprüft bei jeder Änderung die Geschäftslogik, sobald diese eingespielt wird, noch bevor sie zusammengeführt wird. „ KI-Codeanalyse “ erweitert diese Überprüfung auf das gesamte Repository bei wesentlichen Änderungen, noch bevor etwas überhaupt bereitgestellt wird, und kann Fehlkonfigurationen oder umgebungsspezifische Einstellungen aufdecken, die bei einem Live-Test möglicherweise übersehen würden. „AI Pentest“ deckt die regelmäßige Live-Validierung ab – die gründlichste verfügbare Prüfung und genau die, die „ compliance “-Frameworks erwarten. „Continuous Pentest“ steht Teams zur Verfügung, deren Sicherheitslage eine solche Validierung kontinuierlich und nicht nur in festgelegten Intervallen erfordert. Die stärksten Sicherheitsprogramme setzen alle vier Komponenten mehrschichtig ein, anstatt sich zwischen ihnen entscheiden zu müssen.
