Was SAST tatsächlich tut
Eine SAST-Engine parst Quelldateien in einen abstrakten Syntaxbaum (AST) und wendet dann Regeln darauf an: Pattern-Matches für bekannt gefährliche Funktionsaufrufe, Taint-Tracking, das einen Wert von einer nicht vertrauenswürdigen Quelle (ein Request-Parameter, ein Formularfeld) bis zu einer gefährlichen Senke (eine SQL-Query, ein Shell-Befehl, ein Dateipfad) verfolgt, und bei fortgeschritteneren Engines dateiübergreifendes Dataflow, das eine Quelle in einer Datei mit einer Senke in einer anderen verbindet. Nichts wird ausgeführt. Genau das macht SAST nutzbar, bevor überhaupt eine Testumgebung existiert — es läuft auf einem Laptop, in einem CI-Job, oder gegen eine Codebasis, die noch nie deployed wurde.
SAST vs. DAST vs. IAST vs. SCA
Diese vier Akronyme werden im Anbieter-Marketing austauschbar verwendet. Sie testen unterschiedliche Dinge, zu unterschiedlichen Zeitpunkten, und keines ersetzt die anderen.
| Kategorie | Wann es läuft | Was es findet |
|---|---|---|
| SAST | Vor dem Build — auf Quellcode | Schwachstellenmuster im Code: Injection, hartkodierte Secrets, unsichere Kryptografie, unsichere Deserialisierung. |
| DAST | Gegen eine laufende Anwendung | Laufzeitverhalten: wie die App tatsächlich auf präparierte HTTP-Requests reagiert, Auth-Umgehung, fehlkonfigurierte Header. |
| IAST | Während der Testausführung, instrumentiert | Ein Hybrid — beobachtet echte Codepfade während Tests laufen und kombiniert Quellcode-Sichtbarkeit mit Laufzeit-Bestätigung. |
| SCA | Gegen den Abhängigkeitsbaum | Bekannte CVEs in Drittanbieter-Bibliotheken — nicht Ihr Code, sondern Code, den Sie importiert haben. |
Ein reifes Sicherheitsprogramm kombiniert mehrere dieser Schichten. SAST ist meist die erste, weil es am frühesten läuft — bevor es überhaupt etwas zu deployen oder anzugreifen gibt.
Was ein SAST-Tool tatsächlich abdecken sollte
Nicht jeder Scanner, der sich „SAST" nennt, deckt denselben Bereich ab. Eine kurze, konkrete Checkliste:
- ✅ Standard-Mapping — Findings mindestens mit CWE getaggt; OWASP-Top-10-, ISO-27001-, ASVS- oder NIST-CSF-Mapping, wenn Sie Compliance-Nachweise brauchen, nicht nur ein Schweregrad-Label.
- ✅ Sprachabdeckung, die zu Ihrem Stack passt — ein Tool, das 30 Sprachen abdeckt, aber nicht die, die Sie tatsächlich nutzen, deckt null Prozent Ihres Codes ab.
- ✅ Eine niedrig genug False-Positive-Rate, um nutzbar zu sein — ein Scanner, der das Triage mit Rauschen flutet, wird binnen eines Monats ignoriert, unabhängig von seiner rohen Finding-Anzahl.
- ✅ Ein Bericht, den jemand außerhalb des Security-Teams lesen kann — ein JSON-Dump reicht fürs CI-Gating, ist aber nutzlos, um ihn einem Auditor oder Kunden zu übergeben.
- ✅ CI/CD-Integration — SARIF-Export, Exit-Codes, oder eine native Action/Pipeline-Stufe, damit Scannen kein manueller Schritt ist, den jemand vergisst.
- ✅ Eine klare Antwort auf „wo geht mein Code hin" — Cloud-Upload-SAST und Offline-SAST sind unterschiedliche Risikoprofile, keine Fußnote. Siehe was Offline-SAST tatsächlich bedeutet.
Wo StaticCodeAudit einzuordnen ist
StaticCodeAudit ist ein kuratiertes, offline laufendes SAST: eine eigenständige Binary, die 8 Sprachen (Python, JavaScript/TypeScript, HTML, Java, C#, PHP, YAML, Dockerfile) mit 708 Regeln scannt, alle mindestens auf CWE gemappt, mit integrierten Matrizen für ISO 27001 Anhang A, OWASP ASVS v5.0, WCAG 2.1 und NIST CSF 2.0 — nicht nachträglich zusammengestellt. Es lädt niemals Quellcode irgendwohin hoch; der gesamte Scan läuft auf der Maschine, die die Binary ausführt.
Häufige Fragen
Ersetzt SAST manuelle Code-Reviews oder Penetrationstests?
Nein. SAST ist schnell, wiederholbar und erkennt bekannte Musterklassen in großem Maßstab — es wird keinen Business-Logic-Fehler finden, den ein menschlicher Reviewer entdecken würde („diese API lässt jeden Nutzer die Bestellung eines anderen stornieren"), und bestätigt keine Ausnutzbarkeit so, wie es ein Pentest gegen ein laufendes System tut. Es ist eine Schicht, meist die erste und günstigste zu implementierende.
Mit wie vielen False Positives muss ich rechnen?
Das hängt vollständig von der Engine und dem Regeldesign ab — es gibt keine universelle Zahl, und jeder Anbieter, der eine ohne benannten Benchmark nennt, rät. Fordern Sie einen veröffentlichten, reproduzierbaren Benchmark (OWASP Benchmark, NIST Juliet oder ähnlich) mit Precision/Recall/F1 pro Kategorie an, keine einzelne aggregierte „Genauigkeits"-Zahl. Siehe, wie das auf der Sprach-Benchmark-Seite gemessen wird.
Ist ein Linter dasselbe wie SAST?
Nein, auch wenn sie sich mechanisch überschneiden. Ein Linter (ESLint, Pylint, RuboCop) prüft hauptsächlich Stil und grundlegende Korrektheitsfehler. SAST-Regeln zielen speziell auf ausnutzbare Schwachstellenklassen — Injection, Deserialisierung, hartkodierte Secrets, kryptografische Schwächen — und werden meist auf CWE gemappt, damit Findings zu einer bekannten Schwächen-Taxonomie rückverfolgbar sind.
Braucht SAST Internetzugang zum Laufen?
Nicht von Natur aus — das ist eine Deployment-Entscheidung des Anbieters, keine Anforderung der statischen Analyse selbst. Cloud-SAST-Produkte laden Ihren Quellcode hoch, um die Analyse remote auszuführen; Offline-SAST-Produkte führen die gesamte Analyse, einschließlich der Regelauswertung, auf Ihrer eigenen Maschine aus. Siehe was Offline-SAST tatsächlich bedeutet und wie man es verifiziert.
Was bedeutet „708 Regeln" praktisch?
Es bedeutet 708 individuell gepflegte Erkennungsmuster, jedes auf mindestens ein CWE gemappt, über Kategorien wie Security (Injection, Secrets, Kryptografie), Architektur, Abhängigkeiten, CI/CD-Pipeline-Konfiguration und mehr. Die Zahl allein sagt wenig, ohne das Mapping und die gemessene Erkennungsrate pro Regel zu kennen — deshalb veröffentlicht StaticCodeAudit sowohl das vollständige Standard-Mapping als auch echte Precision/Recall-Benchmarks statt nur die Zahl.
Sehen Sie einen echten SAST-Bericht, kein Mockup
Öffnen Sie den Live-Demo-Bericht — auf einer echten Codebasis erzeugt, alle Charts interaktiv, vollständiges CWE-/ISO-/ASVS-/WCAG-Mapping inklusive.
Live-Bericht öffnen Offline-SAST-Leitfaden lesen