Statische vs. dynamische Analyse
Statische Analyse liest Code; dynamische Analyse führt ihn aus. Ein statischer Analyzer parst eine Datei in einen abstrakten Syntaxbaum (AST) und prüft diese Struktur gegen Regeln — kein Server, keine Testdaten, keine Ausführungsumgebung nötig, weshalb er in Sekunden gegen eine Codebasis laufen kann, die noch nie deployed wurde. Dynamische Analyse (Tests, Fuzzer, DAST-Scanner) beobachtet tatsächliches Laufzeitverhalten — was eine Funktion für eine gegebene Eingabe zurückgibt, wie ein laufender Server auf einen präparierten Request reagiert — was statische Analyse per Definition nicht sehen kann, da nichts ausgeführt wird. Keine ersetzt die andere; sie beantworten unterschiedliche Fragen.
Was statische Analyse tatsächlich prüft — über Security hinaus
Security dominiert das Marketing, aber statische Analyse ist eine allgemeine Technik, um jede strukturelle Eigenschaft von Code zu prüfen. Die 708 Regeln von StaticCodeAudit decken diese Kategorien ab:
Security
SQL-Injection, XSS, SSRF, Path Traversal, hartkodierte Secrets, unsichere Deserialisierung, schwache Kryptografie, Command Injection, LDAP-Injection, unsichere Cookies, DSGVO-Compliance-Muster.
Architektur
Schutz von Admin-Routen, in Routern eingebettete Datenbanklogik, direkte unparametrisierte Queries, N+1-Query-Muster, überdimensionierte Dateien.
Interface / UI
Inline-Styles, manuelle createElement-Nutzung, Event-Listener-Lecks, DOM-Manipulation in Schleifen.
Barrierefreiheit / UX
Fehlende ARIA-Labels, fehlender Alt-Text, Fokus-Management, Autoplay-Missbrauch, i18n-Probleme, Toast-/Benachrichtigungsmuster, verbliebene console.log-Aufrufe.
Wartung
Ungelöste TODO/FIXME/HACK/XXX-Markierungen, veraltete APIs, catch-all-Exception-Handling, Debug-Anweisungen, Error-Suppressoren.
Abhängigkeiten
Scanning auf bekannte CVEs bei installierten Paketen (Äquivalente zu pip-audit, npm audit), nicht fixierte Versionsbereiche, Lizenz-Compliance.
CI/CD
Fehlkonfiguration von GitHub Actions und GitLab CI, Expression Injection, übermäßige Workflow-Berechtigungen, nicht fixierte Drittanbieter-Actions.
Wie Findings auf veröffentlichte Standards gemappt werden
Ein Finding ohne Standard-Referenz ist nur eine Meinung. StaticCodeAudit taggt jede Regel mindestens mit einer CWE-ID (MITREs Schwächen-Taxonomie) oder einem WCAG-2.1-Erfolgskriterium und legt darüber, wo anwendbar, OWASP-Top-10-, ISO/IEC-27001-Anhang-A-, OWASP-ASVS-v5.0- und NIST-CSF-2.0-Mappings — damit ein Finding auf eine externe, auditierbare Referenz rückverfolgbar ist statt auf ein vom Anbieter erfundenes Schweregrad-Label.
Vollständige Standard-Abdeckung ansehen →Häufige Fragen
Ist statische Codeanalyse dasselbe wie SAST?
SAST (Static Application Security Testing) ist statische Analyse, die spezifisch auf Sicherheitslücken beschränkt ist. Statische Codeanalyse ist die breitere Technik — derselbe Parsing- und Regelabgleich-Mechanismus gilt für Architektur, Barrierefreiheit, Wartbarkeit und Abhängigkeitsprüfungen, nicht nur für ausnutzbare Schwachstellen. Siehe den eigenen SAST-Leitfaden für den sicherheitsspezifischen Anwendungsfall.
Kann statische Analyse Bugs finden, die nur zur Laufzeit auftreten?
Nicht direkt — alles, was von tatsächlichen Eingabewerten, Timing oder Umgebungszustand zur Laufzeit abhängt, liegt per Definition außerhalb dessen, was statische Analyse beobachten kann. Taint-Analyse verkleinert diese Lücke, indem sie verfolgt, wie nicht vertrauenswürdige Daten durch den Code fließen könnten, ohne ihn auszuführen — aber das ist Inferenz, keine Beobachtung. Dafür ist dynamisches Testen da.
Warum deckt StaticCodeAudit UI und Barrierefreiheit ab, nicht nur Security?
Weil die zugrundeliegende Technik — Code parsen, Struktur gegen Regeln prüfen — genauso gut auf ein fehlendes ARIA-Label oder einen Inline-Style anwendbar ist wie auf ein SQL-Injection-Muster. Barrierefreiheit hat speziell auch wachsendes regulatorisches Gewicht (etwa der European Accessibility Act 2025), weshalb WCAG-2.1-Mapping neben CWE-Mapping steht, statt ein separates Produkt zu sein.
Wie vermeidet statische Analyse False Positives?
Sie vermeidet sie nicht vollständig — kein statischer Analyzer tut das, da er über die Codestruktur ohne vollen Laufzeitkontext urteilt. Was zwischen Tools enorm variiert, ist die False-Positive-Rate, die vom Regeldesign abhängt (rein musterbasierte Regeln sind rauschender als solche mit Taint-Tracking) und davon, wie konservativ eine Regel geschnitten ist. Fordern Sie einen veröffentlichten, reproduzierbaren Benchmark statt einer selbst berichteten Zahl des Anbieters an — siehe echte Precision/Recall-Benchmarks.
Muss der Code für statische Analyse kompilierbar sein?
Das hängt vom Tool ab. Manche Engines erfordern einen vollständigen Build, um eine abfragbare Datenbank zu konstruieren (üblich für tiefe semantische Analyse kompilierter Sprachen). StaticCodeAudit nicht — es parst Quelldateien direkt ohne Build-Schritt, für jede seiner 8 unterstützten Sprachen, einschließlich kompilierter wie Java und C#.
Sehen Sie, wie Full-Spectrum-Analyse aussieht
Öffnen Sie den Live-Demo-Bericht — Security-, Architektur-, UI-, Barrierefreiheits-, Wartungs-, Abhängigkeits- und CI/CD-Findings, alle in einer HTML-Datei.
Live-Bericht öffnen Standard-Mapping ansehen