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 auszulösen, was die Entwickler ermüdet, ihnen Beachtung zu schenken. Dadurch verlieren Entwickler Zeit und das Vertrauen in die Tools. Um im Bereich Cybersicherheit effizient und effektiv arbeiten zu können, benötigen Sie einen guten Filter, um diese Fehlalarme zu vermeiden. Genau das leistet AutoTriage für SAST .

Beispiel für einen True Positive

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

In diesem Beispiel sehen wir, dass AutoTriage eine Probe als „sehr hohe Priorität zur Behebung“ markiert. Der SAST weist auf eine potenzielle NoSQL-Sicherheitslücke hin. Der Code stellt einen Login-Endpunkt dar, an dem Benutzer einen Namen und ein Passwort eingeben können. Es erfolgt ein Aufruf an die Datenbank, um nach einem übereinstimmenden 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 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 das SAST tatsächlich ein echtes positives Ergebnis. 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 aufweist als das durchschnittliche SAST .

Wenn ein solches Problem gemeldet wird, sollten Sie es so schnell wie möglich beheben. Es gibt keine schnellere Methode als die Verwendung des AutoFix-Tools Aikido. Damit erstellen Sie 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, besteht das eigentliche Problem von SAST in der Anzahl der Fehlalarme, die sie auslösen. Ein Beispiel hierfür finden Sie unten. Es besteht eine potenzielle SQL-Injection, bei der ein „productName” in eine SQL-Abfrage eingefügt wird. Darüber hinaus stammt dieser „productName” aus dem Request-Body und wird somit vom Benutzer kontrolliert. Glücklicherweise gibt es eine Allowlist, die überprüft, ob „productName” entweder „iPhone15”, „Galaxy S24”, „MacBook Pro” oder „ThinkPad X1” lautet. Dadurch wird sichergestellt, dass „productName” keine Angriffs-Payload wie „productName = „iPhone15’; DROP TABLE products; - - ” enthalten kann.

Eine Whitelist wie die in diesem Beispiel ist eine wirksame Gegenmaßnahme gegen SQL-Injection. Aber ältere Scanner wie Semgrep können die Wirksamkeit solcher Zulassungslisten nicht beurteilen.

Large Language Models (LLMs) bieten hier eine große Chance: Sie können viel mehr Kontext von Quellcode verstehen und solche Beispiele herausfiltern.

Aikido„No Bullsh*t Security“-Erzählung

Wenn Softwareunternehmen nach AppSec suchen, vergleichen sie häufig verschiedene auf dem Markt verfügbare Lösungen. Eine typische Methode, wie weniger erfahrene Unternehmen Anbieter vergleichen, besteht darin, die Anzahl der in ihrem Quellcode gefundenen Schwachstellen zu zählen. Es überrascht nicht, dass sie dazu neigen zu glauben, dass mehr Schwachstellen gleichbedeutend mit besseren Tools sind. Manchmal wählen sie ihren Anbieter auf der Grundlage dieser mangelhaften Bewertung aus. Infolgedessen zögern einige AppSec , Fehlalarme herauszufiltern, da sie bei diesem häufig anzutreffenden Vergleich schlechter abschneiden würden.

Bei Aikido verfolgen wir einen anderen Ansatz. Unser Motto „No Bullsh*t“ bedeutet, dass wir unseren Kunden so gut 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 das Angebot Aikidovon anderen auf dem Markt unterscheidet.

Verfügbarkeit

Wir haben diese Funktion für 91 SAST in verschiedenen Sprachen aktiviert, darunter JavaScript/TypeScript, Python, Java, .NET und PHP. Weitere Regeln werden in rascher Folge 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 jede Pull-Anfrage auf Schwachstellen Aikido . AI AutoTriage ist nun auch für diese Funktion aktiviert, was den Arbeitsablauf wesentlich vereinfacht.

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 veröffentlicht, mit der sich falsch-positive SAST herausfiltern lassen und die außerdem bei der Priorisierung der echt-positiven Ergebnisse hilft. Sie steht allen Nutzern zum Testen zur Verfügung, auch für kostenlose Konten. Diese Funktion ist ein wichtiger Schritt, um den „Wolf-Rufe“-Effekt in der Cybersicherheit zu reduzieren, und hilft Entwicklern, sich auf das Wesentliche zu konzentrieren: die Behebung echter Schwachstellen und mehr Zeit für die Entwicklung von Funktionen für ihre Kunden.