Der 0-Euro-Warenkorb: warum Ihr durchgehend grüner SAST-Report Sie belügt

Ich habe kürzlich die Codebasis eines Kunden auditiert. Die CI/CD-Pipeline war eine Schönheit. Snyk machte SAST. Dependabot übernahm SCA. Alle Anzeigen grün. Null kritische Schwachstellen. „Wir sind sicher", sagte mir der Lead Dev.

Zehn Minuten später hatte ich das gesamte Lager für 0 € gekauft.

Ich habe keinen Buffer Overflow benutzt. Ich habe kein SQL injiziert. Ich habe lediglich den Ablauf manipuliert.

Artikel in den Warenkorb legenRequest abfangenMenge = -1Zur Kasse gehenSumme: 0 €

Die Logik zog den Preis von der Summe ab. Die Syntax des Codes war einwandfrei, also sah SAST nichts. Die Bibliotheken waren aktuell, also sah SCA auch nichts. Aber die Geschäftslogik war falsch.

Das Eisberg-Problem

Klassische Scanner (SAST und DAST) sind Syntaxprüfer. Sie suchen Muster im Code, Aufrufe von eval() oder unbereinigte Eingaben. Aber sie verstehen nicht, was der Code tun soll.

Über der Oberfläche, für SAST und SCA sichtbar

• Syntaxfehler und unbereinigte Eingaben
• Bekannte CVEs in Drittanbieter-Bibliotheken
• Fest im Code hinterlegte Secrets

Unter der Oberfläche, die unsichtbaren 30 %

Zahlung umgehen

Den Kauf abschließen, ohne wirklich zu zahlen.

Coupon-Missbrauch

50 Gutscheine mit „10 % Rabatt" stapeln, bis es gratis ist.

Rechteausweitung

user_id=123 → user_id=1 ändern und Admin sein.

Ablaufmanipulation

Pflichtschritte einer Transaktion überspringen.

Das sind keine Programmierfehler. Das sind Logikfehler. Der Scanner sieht eine gültige Zahlungsfunktion, die korrekt arbeitet. Ein Angreifer sieht den Weg, die Zahlung komplett zu überspringen. Und bislang fanden das nur menschliche Pentester, zu 5.000 € pro Woche.

Auftritt BLSA: die nächste Grenze

Bei CybeDefend glauben wir, dass die Zukunft der AppSec nicht darin liegt, mehr Syntaxfehler zu finden, sondern Kontext zu verstehen. Wir bauen die erste Business Logic Security Analysis (BLSA) der Branche.

Über agentische Workflows liest unser Scanner nicht nur Code, er versteht Abläufe. Er verschränkt den Datenpfad mit der Nutzerrolle, mit dem Transaktionszustand, mit dem Preisfeld, und fällt das Urteil, bevor die Zeile gemergt wird.

Wir gehen von statischer Analyse zu intelligenter Analyse. Nicht nur Code lesen, sondern darüber nachdenken, was er schützen soll.

Die Wirkung auf Ihr Budget

Diese Fehler zu ignorieren ist nicht nur ein Sicherheitsrisiko, es ist eine finanzielle Entscheidung. Eine Schwachstelle in Produktion zu beheben kostet rund 60-mal mehr als in der Entwicklung (Branchen-Daumenregel, nach Pressmans Software Engineering und dem NIST Planning Report 02-3 von 2002). Wenn Sie warten, bis ein Pentester einen Logikfehler in Produktion findet, haben Sie den Pentest (über 10.000 €) schon bezahlt und die Behebung kommt obendrauf.

Richtwerte, eher orientierend als exakt; die zugrunde liegende Kurve (die Kosten eines Defekts wachsen von etwa 6 auf etwa 30 vom PR bis zur Produktion, ein Vorfall legt eine weitere Größenordnung darauf) ist in der Literatur breit belegt.

Fangen Sie es im PR mit einem automatischen Werkzeug ab, kostet es Sie 0 €. Erreicht es Produktion, zahlen Sie die Incident Response, den Hotfix, die Ausfallzeit und die Support-Tickets. Und das bevor Sie den Pentest einplanen, den Sie früher hätten machen sollen.

Wie Sie Ihre Logik noch heute prüfen

Solange unser vollständiges BLSA-Release in Alpha ist, sollte jedes Engineering-Team sofort Folgendes tun:

1. Zeichnen Sie Ihre kritischen Abläufe. Scannen Sie nicht nur Dateien: malen Sie Ihre Zahlungs- und Auth-Flows an ein Whiteboard. Suchen Sie Abkürzungen, jeden Schritt, der übersprungen werden könnte.
2. Misstrauen Sie Ihren grünen Builds. Findet Ihr Scanner nichts, werden Sie skeptisch. Wahrscheinlich hat er die Logikfehler übersehen und nicht bewiesen, dass es keine gibt.
3. Probieren Sie CybeDefend. Wir verbinden SAST, SCA und IaC mit unserer Cross-Analysis-Engine. Wir korrelieren Befunde, um den Lärm um 70 % zu senken, damit Ihr Team Zeit für die Logikprobleme hat, auf die es wirklich ankommt.