Der heulende Wolf in der Cybersicherheit
Der Junge, der Wolf rief, geht auf eine Fabel zurück, in der sich ein Hirtenjunge über die anderen Dorfbewohner lustig machte, indem er ihnen erzählte, dass ein Wolf die Herde angreift. Die Dorfbewohner glaubten ihm zunächst, aber er machte sich nur über sie lustig. Als der Hirtenjunge seinen Scherz wiederholte, begannen die Dorfbewohner, ihn zu ignorieren, und irgendwann kam ein echter Wolf und griff die Schafe an. Der Junge "heulte wie ein Wolf", aber niemand glaubte ihm mehr.
Cybersicherheits-Tools haben sich als Hirtenjungen erwiesen: Sie neigen dazu, viele Fehlalarme auszulösen, was die Entwickler ermüdet, ihnen Aufmerksamkeit zu schenken. Dadurch verlieren die Entwickler Zeit und das Vertrauen in die Tools. Um effizient und effektiv im Bereich der Cybersicherheit arbeiten zu können, braucht man einen guten Filter, um diese Fehlalarme zu vermeiden. Genau das tut AutoTriage für SAST-Schwachstellen.
Echtes Positivbeispiel
Im Folgenden finden Sie ein Beispiel für einen SAST-Befund. SAST steht für Static Application Security Testing, frei übersetzt: Erkennen gefährlicher Muster im Quellcode, ohne den Code auszuführen. Es ist eine leistungsfähige Methode, um viele verschiedene Arten von Schwachstellen zu erkennen.
In diesem Beispiel sieht man, wie AutoTriage ein Beispiel als "mit sehr hoher Priorität zu beheben" markiert. Der SAST-Fund weist auf eine potenzielle NoSQL-Schwachstelle hin. Der Code stellt einen Login-Endpunkt dar, an dem Benutzer einen Namen und ein Passwort angeben können. Es erfolgt ein Aufruf an die Datenbank, um nach einem passenden Datensatz für Name und Passwort zu suchen.
The problem here is that NoSQL allows you to insert objects like { $ne: undefined }. In that case, the match will be based on anything that is different from undefined. Imagine that an attacker would upload something like this:
{
name: LeoIVX,
password: { $ne: undefined }
}
In diesem Fall wäre der Angreifer in der Lage, sich als Papst anzumelden (wenn der Papst ein Konto mit diesem Benutzernamen auf dieser Softwareplattform hätte), da das Passwort immer mit der Abfrage übereinstimmt.

In diesem Fall war der SAST-Fund ein echter Positivbefund. AutoTriage leistet hier mehr als nur eine Bestätigung: Es erhöht auch die Priorität, da diese Schwachstelle leichter auszunutzen ist und einen höheren Schweregrad hat als der durchschnittliche SAST-Fund.
Wenn ein Problem wie dieses gemeldet wird, sollten Sie es so schnell wie möglich beheben. Es gibt keine schnellere Methode als die Verwendung des AutoFix-Tools von Aikido. Damit wird mit einem Klick ein Pull Request (oder Merge Request) erstellt. In diesem Fall ist das Ergebnis:

AutoFix schlägt immer die einfachste Lösung vor, die die Schwachstelle adäquat behebt. In diesem Fall reicht es aus, sowohl den Namen als auch das Kennwort zu ändern, um den Endpunkt zu sichern und der Absicht des Entwicklers zu entsprechen.
Bitte beachten Sie, dass Passwörter niemals direkt verglichen werden sollten und stattdessen Passwort-Hashes verwendet werden sollten - dieses Beispiel wurde der Einfachheit halber verwendet. Der von AutoFix verwendete LLM ist ausdrücklich angewiesen, keine anderen Probleme als die gemeldete Schwachstelle zu beheben, so dass Pull-Requests die bewährte Praxis befolgen, ein Problem nach dem anderen zu lösen.
Falsches positives Beispiel
Wie bereits erwähnt, besteht das eigentliche Problem der SAST-Tools in der Anzahl der Fehlalarme, die sie produzieren. Ein Beispiel dafür ist unten zu sehen. Es gibt eine potenzielle SQL-Injektion, bei der ein "Produktname" in eine SQL-Abfrage injiziert wird. Außerdem stammt dieser "Produktname" aus dem Text der Anfrage, ist also benutzergesteuert. Glücklicherweise gibt es eine Erlaubnisliste, die prüft, ob productName entweder "iPhone15", "Galaxy S24", "MacBook Pro" oder "ThinkPad X1" ist. Dies garantiert, dass productName keinen Angriffs-Payload wie productName = "iPhone15'; DROP TABLE products; - - " enthalten kann.

Eine Zulässigkeitsliste wie die in diesem Beispiel ist eine wirksame Gegenmaßnahme gegen SQL-Injection. Aber Legacy-Scanner wie Semgrep können die Wirksamkeit solcher Zulassen-Listen nicht beurteilen.
Große Sprachmodelle (LLMs) bieten hier eine große Chance: Sie können viel mehr Kontext des Quellcodes verstehen und solche Beispiele herausfiltern.
Aikidos "No Bullsh*t Security"-Narrativ
Wenn Softwareunternehmen nach AppSec-Anbietern suchen, vergleichen sie oft verschiedene auf dem Markt verfügbare Lösungen. Eine typische Art und Weise, wie weniger erfahrene Unternehmen Anbieter vergleichen, ist das Zählen der in ihrem Quellcode gefundenen Schwachstellen. Es wird nicht überraschen, dass sie dazu neigen, zu glauben, dass mehr Schwachstellen gleichbedeutend mit besseren Werkzeugen sind. Manchmal wählen sie ihren Anbieter auf der Grundlage dieser falschen Einschätzung aus. Folglich zögern einige AppSec-Unternehmen, Falschmeldungen herauszufiltern, da sie bei diesem oft gesehenen Vergleich schlechter abschneiden würden.
Bei Aikido verfolgen wir einen anderen Ansatz. Unser "No Bullsh*t"-Ansatz bedeutet, dass wir unseren Kunden so gut wie möglich helfen wollen, auch wenn dies kurzfristig ein paar verlorene Geschäfte bedeutet. AI AutoTriage ist ein klares Beispiel dafür, denn diese Funktion hebt das Angebot von Aikido von anderen auf dem Markt ab.
Verfügbarkeit
Wir haben diese Funktion für 50 SAST-Regeln in verschiedenen Sprachen aktiviert, darunter javascript/ typescript, python, java, .NET und php. Weitere Regeln werden in schnellem Tempo hinzugefügt.
Diese Funktion ist für alle aktiviert, auch für kostenlose Konten. Das bedeutet, dass kostenlose Konten die maximale Anzahl von LLM-Anrufen recht leicht erreichen können.
CI-Torsteuerung
CI Gating ist der Prozess, bei dem Aikido bei jeder Pull-Anfrage nach Schwachstellen sucht. AI AutoTriage ist jetzt auch für diese Funktion aktiviert, was den Arbeitsablauf viel bequemer macht.
Stellen Sie sich vor, Sie haben in einer Pull-Anfrage eine Schwachstelle für Pfadüberquerungen eingeführt und einen AutoFix angewendet. Dieser Fix würde normalerweise eine Denyliste von Mustern verwenden, bevor die Datei gelesen oder geschrieben wird. Da Denylisten bei hartkodierten Mustern schwer zu interpretieren sind, würde selbst die behobene Version noch als Problem gekennzeichnet werden. Dies ist nun dank der Anwendung unserer AutoTriage direkt in der CI-Pipeline behoben.
Schlussfolgerung
Wir haben eine leistungsstarke Funktion zum Herausfiltern von falsch-positiven SAST-Ergebnissen veröffentlicht, die auch bei der Priorisierung der wirklich positiven Proben hilft. Sie ist für jeden zum Testen verfügbar, auch für kostenlose Konten. Diese Funktion ist ein großer Schritt nach vorn, um den "Cry Wolf"-Effekt in der Cybersicherheit zu reduzieren und Entwicklern zu helfen, sich auf das zu konzentrieren, was wirklich wichtig ist: die Behebung echter Schwachstellen und mehr Zeit für die Entwicklung von Funktionen für ihre Kunden.