SASTWerkzeuge.
Static Application Security Testing analysiert Quellcode vor der Auslieferung auf bekannte Sicherheitsmuster und risikoreiche Datenflüsse. SAST verschiebt Funde nach links in die Entwicklung, kann Laufzeitverhalten und externe Abhängigkeiten aber nicht vollständig beurteilen.
Code früh prüfen.
SAST wird im IDE, Pull Request oder Build eingesetzt. Gute Einbindung verbindet Fund, Code-Stelle, Repository, Owner und Korrekturworkflow, statt ein separates Reporting-Silo zu schaffen.
SAST analysiert eigenen Code. SCA bewertet Drittkomponenten; DAST und Pentesting prüfen laufende Anwendungen. Kein einzelner Scan belegt die Sicherheit einer Anwendung.
Plattformen im Vergleich.
| Plattform | Geeignet für | Stärke | Vor Auswahl prüfen |
|---|---|---|---|
| Checkmarx SAST | Enterprise-AppSec und breite Sprachenlandschaft | Code-Analyse mit AppSec-Plattform | Triage-Workflow, Regelpflege und CI/CD |
| Veracode Static Analysis | Programmatische AppSec-Governance | SaaS-gestützte Static Analysis | Build-Modell, Sprachen und Entwicklererlebnis |
| Synopsys Coverity | Komplexe, langlebige Software | Tiefe statische Analyse | Tuning, Analysezeit und Betriebsaufwand |
| GitHub CodeQL | GitHub-zentrierte Entwicklung | Code Scanning im Repository-Workflow | Lizenz, Query-Abdeckung und Triage |
| Semgrep Code | Teams mit schneller Entwickler-Integration | Regelbasierte Analyse und Custom Rules | Regelqualität und Ownership der Regeln |
| SonarQube | Qualitäts- und Security-Gates im Build | Breite Entwicklerakzeptanz | Security-Tiefe gegenüber Qualitätsregeln |
| Snyk Code | Cloud-native Entwicklerteams | Code-Sicht im Snyk-Ökosystem | Abdeckung, Policies und Fehlalarm-Workflow |
| OpenText Fortify Static Code Analyzer | Regulierte und Enterprise-Umgebungen | Statische Analyse und Governance | Scan-Infrastruktur und Remediation-Prozess |
Vom Scan
zur Korrektur.
- Mit einem Kernrepository und den wichtigsten Sprachen starten; Regeln auf relevante Schwachstellenklassen (z. B. Injection, unsichere Deserialisierung) begrenzen.
- Funde im Pull Request anzeigen und nur neue kritische Funde als Merge-Blocker setzen.
- Altlasten separat priorisieren und mit Frist abbauen, statt sie zu ignorieren.
- Bewertete False Positives dokumentieren und bei Regeländerungen erneut prüfen.
- Anteil Repositories mit aktivem Scan im Pull Request
- Mittlere Zeit bis zur Korrektur kritischer Funde
- Quote der als False Positive markierten Funde je Regel
ISO/IEC 27001:2022 Annex A 8.25 (sicherer Entwicklungslebenszyklus), 8.28 (sicheres Programmieren) und 8.29 (Sicherheitstests).
Der Cyber Resilience Act verlangt ab Dezember 2027 für Produkte mit digitalen Elementen ein dokumentiertes Schwachstellenmanagement; SAST ist dafür ein Baustein, kein Nachweis der Konformität.
Null Funde heisst nicht sicher. SAST sieht nur die Muster, für die Regeln existieren, und keine Fehler in Logik, Konfiguration oder Betrieb.
Am Pull Request testen.
- Relevante Schwachstelle in einer unterstützten Sprache erkennen.
- Fund direkt in Code Review und Ticketing überführen.
- False Positives nachvollziehbar markieren und periodisch prüfen.
- Regeln für eigene sichere Coding-Standards ergänzen.
SAST gehört mit SCA, Secrets Scanning, IaC Scanning und DAST in einen AppSec-Prozess. Für CRA-relevante Produkte ist die Nachvollziehbarkeit der Korrektur ebenso wichtig wie der Fund.
Security Tool Navigator · Gebiet 07
Im Gebiet Application und Product Security einordnen.
Diese Werkzeugklasse gehört zum Gebiet Application und Product Security. Der Gebietshub zeigt, wie die Werkzeugklassen zusammenwirken, wo sie sich abgrenzen und welche Fragen CIO und CISO jeweils klären.