Falscher Alarm in der Cybersicherheit

Die Geschichte vom Hirtenjungen, der Wolf rief, geht auf eine Fabel zurück, in der ein Hirtenjunge die anderen Dorfbewohner verspottete, indem er ihnen erzählte, ein Wolf greife die Herde an. Die Dorfbewohner glaubten ihm zuerst, aber er lachte nur mit ihnen. 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 'rief Wolf', aber niemand glaubte ihm mehr.

Cybersicherheitstools haben sich wie Hirtenjungen verhalten: Sie neigen dazu, viele Fehlalarme zu geben, was Entwickelnde ermüdet, ihnen Aufmerksamkeit zu schenken. Dies führt dazu, dass Entwickelnde Zeit verlieren und das Vertrauen in die Tools einbüßen. Um in der Cybersicherheit effizient und effektiv arbeiten zu können, benötigt man einen guten Filter, um diese Fehlalarme zu vermeiden. Genau das leistet AutoTriage für SAST-Schwachstellen.

Beispiel für einen True Positive

Das Folgende ist ein Beispiel für ein SAST-Ergebnis. SAST steht für Statische Anwendungssicherheitstests, frei übersetzt: gefährliche Muster im Quellcode erkennen, ohne den Code auszuführen. Es ist eine leistungsstarke Methode, um viele verschiedene Arten von Schwachstellen zu kennzeichnen.

In diesem Beispiel sehen wir, wie AutoTriage ein Sample als „sehr hohe Priorität zur Behebung“ kennzeichnet. Der SAST-Befund weist auf eine potenzielle NoSQL-Schwachstelle hin. Der Code repräsentiert einen Login-Endpunkt, an dem Benutzer einen Namen und ein Passwort angeben können. Es erfolgt ein Datenbankaufruf, um einen übereinstimmenden Datensatz für Namen 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 könnte sich der Angreifer als Papst anmelden (falls der Papst ein Konto mit diesem Benutzernamen auf dieser Softwareplattform hätte), da das Passwort immer der Abfrage entsprechen würde.

In diesem Fall war der SAST-Befund ein echter Positivbefund. AutoTriage tut hier mehr als nur zu bestätigen: Es erhöht auch die Priorität, da diese Schwachstelle leichter auszunutzen ist und eine höhere Schwere aufweist als der durchschnittliche SAST-Befund.

Wenn ein solches Problem gemeldet wird, sollten Sie es so schnell wie möglich beheben. Es gibt keine schnellere Methode als die Verwendung von Aikidos AutoFix-Tool. Dies erstellt mit einem Klick einen Pull Request (oder Merge Request). In diesem Fall ist das Ergebnis:

AutoFix schlägt immer die einfachste Behebung vor, die die Schwachstelle adäquat löst. In diesem Fall genügt das Casting sowohl des Namens als auch des Passworts, um den Endpunkt zu sichern und der Absicht der Entwickelnden zu entsprechen.

Bitte beachten Sie, dass Passwörter niemals direkt verglichen werden sollten und stattdessen Passwort-Hashes verwendet werden sollten – dieses Beispiel diente der Vereinfachung. Das von AutoFix verwendete LLM ist explizit angewiesen, keine anderen Probleme als die gemeldete Schwachstelle zu beheben, sodass Pull Requests der Best Practice folgen, jeweils nur ein Problem zu lösen.

Beispiel für False Positive

Wie bereits erwähnt, ist das eigentliche Problem von SAST-Tools die Anzahl der Fehlalarme, die sie produzieren. Ein Beispiel hierfür finden Sie unten. Es besteht eine potenzielle SQL-Injection, bei der ein „productName“ in eine SQL-Abfrage injiziert wird. Darüber hinaus stammt dieser „productName“ aus dem Request-Body und ist somit Benutzergesteuert. Glücklicherweise gibt es eine Allowlist, die prüft, ob productName entweder „iPhone15“, „Galaxy S24“, „MacBook Pro“ oder „ThinkPad X1“ ist. Dies garantiert, dass productName keine Angriffsnutzlast wie productName = „iPhone15‘; DROP TABLE products; - - “ enthalten kann.

Eine Allowlist wie die in diesem Beispiel gegebene ist eine wirksame Gegenmaßnahme gegen SQL-Injection. Doch Legacy-Scanner wie Semgrep versagen dabei, die Wirksamkeit solcher Allowlists zu bewerten.

Large Language Models (LLMs) bieten hier eine große Chance: Sie können viel mehr Kontext von Quellcode 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 Methode, wie weniger erfahrene Unternehmen Anbieter vergleichen, ist das Zählen der im Quellcode gefundenen Schwachstellen. Es wird nicht überraschen, dass sie dazu neigen zu glauben, dass mehr Schwachstellen gleich bessere Tools bedeuten. Manchmal wählen sie ihren Anbieter basierend auf dieser schlechten Bewertung. Folglich zögern einige AppSec-Unternehmen, False Positives herauszufiltern, da sie bei diesem häufig beobachteten Vergleich schlechter abschneiden würden.

Bei Aikido verfolgen wir einen anderen Ansatz. Unser „No Bullsh*t“-Narrativ bedeutet, dass wir Kunden so weit wie möglich helfen wollen, auch wenn dies kurzfristig einige verlorene Geschäfte bedeutet. AI AutoTriage ist ein klares Beispiel dafür, da diese Funktion Aikidos Angebot von anderen auf dem Markt abhebt.

Verfügbarkeit

Wir haben diese Funktion für 91 SAST-Regeln in verschiedenen Sprachen aktiviert, darunter JavaScript/TypeScript, Python, Java, .NET und PHP. Weitere Regeln werden schnell hinzugefügt.

Diese Funktion ist für alle aktiviert, einschließlich kostenloser Konten. Allerdings können kostenlose Konten die maximale Anzahl von LLM-Aufrufen recht leicht erreichen.

CI Gating

CI-Gating ist der Prozess, bei dem Aikido bei jedem Pull Request nach Schwachstellen scannt. AI AutoTriage ist jetzt auch für diese Funktion aktiviert, was den Workflow wesentlich komfortabler macht.

Stellen Sie sich vor, Sie haben eine Path Traversal Vulnerability in einem Pull Request eingeführt und einen AutoFix angewendet. Dieser Fix würde typischerweise eine Denylist von Mustern verwenden, bevor die Datei gelesen oder geschrieben wird. Da Denylists mit hartcodierten Mustern schwer zu interpretieren sind, würde selbst die gefixte Version immer noch als Problem markiert werden. Dies ist nun dank der Anwendung unseres AutoTriage direkt in der CI-Pipeline gelöst.

Fazit

Wir haben eine leistungsstarke Funktion zur Filterung von False-Positive-SAST-Befunden und zur Unterstützung bei der Priorisierung von True-Positive-Samples veröffentlicht. Sie steht jedem zum Testen zur Verfügung, auch für kostenlose Konten. Diese Funktion ist ein großer Fortschritt bei der Reduzierung des „Cry-Wolf-Effekts“ in der Cybersicherheit und hilft Entwickelnden, sich auf das Wesentliche zu konzentrieren: die Behebung echter Schwachstellen und mehr Zeit für die Entwicklung von Funktionen für ihre Kunden.