Es gibt mittlerweile vier grundlegend unterschiedliche Methoden, um nach Schwachstellen in einer Anwendung zu suchen, wobei jede davon etwas prüft, was die anderen strukturell 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 anderen Stellen im Repository interagiert, um „Code Security Audit“ (im Markt oft als„AI- SAST “bezeichnet), das die Logik einer Codebasis analysiert, ohne irgendwo bereitgestellt werden zu müssen, oder um „ KI-Penetrationstests“, das auf dieselbe Weise vorgeht, jedoch an einem live laufenden Ziel, und seine Ergebnisse durch den Versuch, die Schwachstelle auszunutzen, nachweist. Dieser Beitrag hilft Ihnen zu verstehen, welches Tool für welchen Anwendungsfall am besten geeignet ist.
TL;DR
Diese vier sind keine Konkurrenten. Sie funktionieren jeweils auf unterschiedliche Weise, nicht nur in unterschiedlichen Tiefen. „ SAST “ ist deterministisch: Derselbe Code liefert immer dasselbe Ergebnis, allerdings nur für Muster, die ihm bereits bekannt sind. „Deep PR Review“, „Code Security Audit“ und „AI Pentest“ analysieren stattdessen Logik und Absicht und decken so in unterschiedlichen Bereichen und an verschiedenen Punkten im Lebenszyklus Fehler 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: Code-Sicherheitsprüfung. Das gleiche Prinzip wie bei der „Deep PR Review“, jedoch auf das gesamte Repository angewandt und nicht nur auf einzelne Änderungen. Durch diesen umfassenden Anwendungsbereich 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 vorhanden ist.
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.
Bei einem Code-Sicherheitsaudit werden Absichten und Logik ohne Live-Umgebung geprüft.
Anstatt Muster abzugleichen, liest Code Security Audit (im Markt oft als „KI- 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 tun 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 ist lediglich der Zugriff auf das Repo erforderlich.
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 Überprüfung, die „Deep PR Review“ auf PR-Ebene anwendet, mit dem Unterschied, dass „Deep PR Review“ bei jeder Änderung Probleme aufdeckt, indem ein Pull-Request mit der gesamten Codebasis abgeglichen wird. Das „Code Security Audit“ hingegen überprüft 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 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. Code Security Audit bindet dasselbe Modell in eine Umgebung ein, die Erkundungen durchführt, parallel nach Fehlern sucht und jedes Repository unabhängig validiert – und genau diese Koordination macht den größten Teil des tatsächlichen Unterschieds bei der Anzahl der gefundenen Fehler aus.
Der Kompromiss zwischen dem herkömmlichen „ SAST “ und dem „Code Security Audit“ betrifft nicht nur die Kosten. Die Analyse einer gesamten Codebasis erfordert mehr Rechenleistung und Zeit als der Abgleich mit Mustern, und da keine laufende Anwendung zur Ausnutzung der Schwachstellen zur Verfügung steht, werden die Ergebnisse danach priorisiert, wie wahrscheinlich es ist, dass sie tatsächlich bestehen – und nicht danach, ob sie durch Ausführung bestätigt wurden. SAST Dank der Geschwindigkeit und des Determinismus von „Code Security Audit“ lässt sich das Tool direkt in CI/CD integrieren. Aus diesem Grund eignet sich „Code Security Audit“ am besten für bedeutende Änderungen und größere Releases und weniger für jeden einzelnen Commit. Doch die Kosten und die Effizienz agentbasierter 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 Aikido -Angriffe basieren auf demselben grundlegenden Ansatz wie Code-Sicherheitsaudits. Pentests gehen jedoch noch einen Schritt weiter, da sie an einer live laufenden Anwendung durchgeführt werden. Das bedeutet, dass sie tatsächliche Exploits versuchen können, indem Agenten echte Anfragen senden und eine reale Angriffsfläche abbilden.
Durch diese Validierung in Echtzeit lassen sich die meisten Fehlalarme beseitigen (darauf werden wir im nächsten Abschnitt noch näher eingehen). Bei einem Code-Security-Audit lässt sich anhand des Codes vermuten, dass ein Fehler in der Geschäftslogik wie IDOR vorliegt; bei einem Penetrationstest kann der Exploit am laufenden 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 – all dies ist für das „Code Security Audit“ nicht erforderlich, da es direkt aus dem Quellcode ausliest. 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 dem „ SAST “ als auch über dem „Code Security Audit“.
Ein KI-Penetrationstest ist zudem der einzige dieser drei Tests, der die Anforderungen der „ compliance “ für Rahmenwerke wie SOC 2 und ISO 27001 in Bezug auf einen Live-Penetrationstest erfüllt. Ein Code-Sicherheitsaudit kann einen Live-Penetrationstest nicht ersetzen, wenn dieser gemäß den „ compliance “ vorgeschrieben ist, doch die Durchführung im Vorfeld kann dennoch von Vorteil sein. Werden Logikfehler 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 Penetrationstest-Agenten (sogenanntes „Whitebox-Testing“) erhebliche Auswirkungen auf die Ergebnisse (und die damit verbundenen Kosten) hat. Bei mehr als 1.000 KI-Penetrationstests, 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 des Quellcodes im Rahmen des Code Security Audit und der Live-Ausnutzung über KI-Penetrationstests – erhalten Sie also ein umfassenderes Bild als bei jeder einzelnen Methode für sich. Dies lässt sich in der Benutzeroberfläche für den „ Aikido -Angriff“ ganz einfach durch Auswahl von „Whitebox“ 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
Code Security Audit analysiert Ihren Code, ohne ihn auszuführen. Es erkennt, dass eine Anfrage eine gefährliche Operation erreicht und dass es auf dem Weg dorthin keine Schutzmaßnahmen gibt, und kennzeichnet dies als ausnutzbar. Da es auf der Quellcode-Ebene und nicht auf einem Live-Ziel arbeitet, wird sich bei einigen der von ihm markierten Stellen herausstellen, dass sie durch Maßnahmen geschützt sind, die 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 durchführt, wird die Lücke in beide Richtungen geschlossen. Das Code-Sicherheitsaudit erreicht Code, den ein Penetrationstest niemals berührt, wie beispielsweise alles, was hinter einem Feature-Flag oder einer Admin-Route ohne Anmeldedaten liegt. Ein Penetrationstest bestätigt, was das Code-Sicherheitsaudit 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 das Code-Sicherheitsaudit eine solide und kosteneffiziente Grundlage, indem es den bestehenden Code überprüft, um bisher unbemerkt gebliebene Schwachstellen aufzudecken. Es muss zunächst keine Umgebung eingerichtet und keine Authentifizierung konfiguriert werden, wodurch diese Ebene bereits dann Risiken abdecken kann, wenn noch nichts anderes eingerichtet ist. Durch die anschließende Einbindung von „Deep PR Review“ wird sichergestellt, dass diese Basis auch bei der Bereitstellung neuen Codes nicht vernachlässigt wird, sodass bei jedem Pull-Request Probleme in der Geschäftslogik erkannt werden, ohne dass eine Live-Umgebung oder ein planmäßiger Penetrationstestzyklus 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 auf diesem Weg, wobei die eigentliche Frage die Abgrenzung ist: Welche Repos und Releases rechtfertigen einen geplanten Penetrationstest, und welche können durch ein Code-Sicherheitsaudit und eine gründliche PR-Prüfung im Tagesgeschäft abgedeckt werden? Die Analyse der logischen Ebenen zuerst durchzuführen und Abhilfemaßnahmen bereits vor dem Penetrationstest zu ergreifen, ist eine Möglichkeit, diese Ausgaben effizienter zu nutzen, da ein „saubereres“ Ziel weniger Befunde beim Penetrationstest bedeutet – Befunde, die sich auf Probleme beziehen, die bereits im Vorfeld kostengünstiger behoben werden konnten.
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 Funktionen je nach Ihren aktuellen Anforderungen gemeinsam eingesetzt werden. „ SAST “ deckt jeden Commit und jeden Pull-Request ab und läuft kontinuierlich. „Deep PR Review“ analysiert bei jeder Änderung die Geschäftslogik, sobald diese eingespielt wird, noch bevor sie zusammengeführt wird. „Code Security Audit“ erweitert diese Analyse auf das gesamte Repository bei wesentlichen Änderungen, noch bevor etwas überhaupt bereitgestellt wird, und kann Fehlkonfigurationen oder umgebungsspezifische Einstellungen aufspüren, 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, die auch von „ compliance “-Frameworks erwartet wird. Für Teams, deren Sicherheitslage eine kontinuierliche Validierung anstelle von Prüfungen in festgelegten Intervallen erfordert, steht „Continuous Pentest“ zur Verfügung. Die stärksten Sicherheitsprogramme setzen alle vier Komponenten mehrschichtig ein, anstatt sich zwischen ihnen entscheiden zu müssen.
