Code-Scanning-Tools: Der vollständige Leitfaden für statisches, dynamisches und Sicherheits-Scanning

Software-Schwachstellen, die in der Produktion entdeckt werden, verursachen Unternehmen durchschnittlich viermal höhere Kosten für deren Behebung als Schwachstellen, die während der Entwicklung gefunden werden. Laut dem IBM-Bericht „Cost of a Data Breach 2025“ belaufen sich die durchschnittlichen Kosten eines Datenlecks auf 4.88 Millionen US-Dollar. Datenlecks, die auf unentdeckte Quellcode-Schwachstellen zurückzuführen sind, gehören zu den teuersten in der Behebung, da ihre Ursache neben der Reaktion auf den Vorfall auch die Behebung der Schwachstellen im Quellcode erfordert. Code-Scanning-Tools dienen dazu, die Erkennung von Schwachstellen so früh wie möglich – in der Entwicklungsumgebung und nicht erst nach einem Datenleck – zu ermöglichen.

Code-Scanning ist die automatisierte Analyse von Quellcode, kompilierten Binärdateien oder laufenden Anwendungen, um Sicherheitslücken, Qualitätsmängel, Compliance-Verstöße und technische Schulden zu identifizieren, bevor die Software produktiv eingesetzt wird. Es bildet die Grundlage der Anwendungssicherheit und ist kein Ersatz für Penetrationstests oder Bedrohungsmodellierung, sondern die systematische Basis, die vorhersehbare und wiederholbare Fehlertypen aufdeckt, die kein menschlicher Prüfer in großem Umfang zuverlässig erkennt.

Was ist Code-Scanning?

Code-Scanning ist die automatisierte Untersuchung von Softwareartefakten, Quellcode, Bytecode, Binärdateien oder laufenden Anwendungen, um Fehler zu identifizieren, ohne dass jede Zeile manuell von einem Menschen überprüft werden muss. Scanning-Tools wenden Regelsätze, Mustererkennung, Datenflussanalyse und – in komplexeren Tools – die Verfolgung von Fehlern zwischen verschiedenen Prozessen an, um Probleme aufzuspüren, die andernfalls unentdeckt in die Produktion gelangen würden.

Was Code-Scanning nicht ist: Es ist kein Ersatz für Code-Reviews, Architekturanalysen, Penetrationstests oder Laufzeitüberwachung. Es ist ein schneller, systematischer und skalierbarer erster Filter, der bekannte Muster zuverlässig und konsistent im gesamten Quellcode erkennt, einschließlich der Teile, die Code-Reviewer oft vernachlässigen, weil sie als Routine erscheinen.

Was bedeutet Codeverifizierung in diesem Kontext? Sie bestätigt, dass sich der Code gemäß seiner Spezifikation verhält. Scanning ist eine Komponente der Verifizierung; es ist die automatisierte Komponente, die Mustererkennung und Datenflussanalyse durchführt. Manuelle Überprüfung, Tests und formale Verifizierung sind die anderen Komponenten. Zusammen bilden sie ein Verifizierungsprogramm; Scanning allein reicht nicht aus.

Statisches vs. dynamisches Code-Scanning: Der Kernunterschied

Die wichtigste Entscheidung beim Erstellen eines Scanprogramms besteht darin, zu verstehen, wann welcher Ansatz ausgeführt wird und was er erfassen kann:

Abmessungen	Statisch (SAST)	Dynamisch (DAST)
Wenn es läuft	Im Quellcode ist keine Ausführung erforderlich	gegen eine laufende Anwendung
Was es sieht	Codestruktur, Datenfluss, Musterverletzungen	Laufzeitverhalten, Serverkonfiguration, API-Antworten
Funde	SQL-Injection-Muster, fest codierte Geheimnisse, unsichere Kryptografie, Code-Smells	Authentifizierungsumgehungen, Laufzeit-Injection, Fehler im Sitzungsmanagement, Serverfehlkonfiguration
Misses	Laufzeit-Schwachstellen, Konfigurationsprobleme	Code-Level-Muster, die während des Testens nicht ausgelöst wurden
Schnelligkeit	Schnell, läuft in Sekunden bis Minuten	Langsam, erfordert eine laufende Umgebung
Entwicklerfeedback	Sofort, IDE oder Pre-Commit	Verzögert, erfordert bereitgestellte Anwendung
Falsch-Positiv-Rate	Höher, es fehlt der Laufzeitkontext.	Niedrigere Werte bestätigen die Ausnutzbarkeit
Am besten integriert bei	IDE, Pre-Commit, CI/CD bei jedem Pull Request	Staging-Umgebung, Vorab-Release-Gate

Die praktische Lösung für die meisten Teams: beides ausführen . Statisches Scannen in der IDE und der CI-Pipeline liefert schnelles, frühzeitiges Feedback zu Codemustern. Dynamisches Scannen in der Staging-Umgebung bestätigt die Ausnutzbarkeit und deckt Konfigurationsprobleme auf, die bei der statischen Analyse nicht erkennbar sind.

Die vier Arten des Code-Scannens

SAST, Statische Anwendungssicherheitstests

SAST analysiert Quellcode, Bytecode oder Binärdateien ohne Ausführung. Es ist die gängigste Form der Codeanalyse und in IDEs und CI/CD-Pipelines integriert. SAST findet Injection-Schwachstellen durch Taint-Analyse (Rückverfolgung nicht vertrauenswürdiger Eingaben zu gefährlichen Zielen), kryptografischen Missbrauch durch Mustererkennung, fest codierte Anmeldeinformationen durch String-Analyse und strukturelle Qualitätsprobleme mithilfe von Metriken und Musterregeln.

Beste Werkzeuge: Semgrep, SonarQube, Checkmarx, CodeQL, Veracode, Snyk Code, SMART TS XL.

DAST, Dynamisches Anwendungssicherheitstesting

DAST wird gegen eine laufende Anwendung ausgeführt, indem es speziell präparierte Eingaben sendet und die Antworten beobachtet. Es kann den Quellcode nicht einsehen und interagiert von außen mit der Anwendung, so wie es ein Angreifer tun würde. DAST findet Authentifizierungsumgehungen, Schwachstellen in der Geschäftslogik, Server-Side Request Forgery und Konfigurationslücken, die SAST nicht erkennen kann, da sie den Laufzeitkontext benötigen.

Beste Tools: OWASP ZAP, Burp Suite, Invicti, Acunetix, HCL AppScan.

SCA, Software Composition Analysis

SCA scannt Abhängigkeitsmanifeste (package.json, pom.xml, requirements.txt, go.mod) werden Schwachstellendatenbanken abgeglichen, um bekannte CVEs in Drittanbieterbibliotheken zu identifizieren. Jede moderne Anwendung verwendet Open-Source-Abhängigkeiten. SCA ist die Scan-Ebene, die sicherstellt, dass diese Abhängigkeiten keine bekannten Schwachstellen enthalten.

Beste Tools: Snyk, OWASP Dependency-Check, Mend (ehemals WhiteSource), GitHub Dependabot, npm audit.

IAST, interaktives Anwendungssicherheitstesting

IAST instrumentiert die Anwendung zur Laufzeit mithilfe von Agenten oder Sensoren, die in den Anwendungsserver eingebettet sind. Es beobachtet die tatsächliche Anfrageverarbeitung innerhalb der Anwendung und kombiniert die Laufzeitgenauigkeit von DAST mit der Code-Ebenen-Analyse von SAST. IAST weist die niedrigste Rate falsch positiver Ergebnisse der vier Typen auf, erfordert jedoch instrumentierte Bereitstellungsumgebungen.

Beste Tools: Contrast Security, Seeker (Synopsys), HCL IAST.

So kombinieren Sie diese: Führen Sie SAST bei jedem Commit aus, um schnelles Feedback von Entwicklern zu erhalten. Führen Sie SCA bei jeder Änderung einer Abhängigkeit aus. Führen Sie DAST vor jedem Release gegen die Staging-Umgebung aus. Ergänzen Sie IAST für kritische Anwendungen, bei denen die Rate falsch positiver Ergebnisse minimiert werden muss.

Was die Code-Analyse tatsächlich findet

Verschiedene Scan-Typen erkennen unterschiedliche Schwachstellenklassen. Diese Zuordnung hilft Teams zu verstehen, in welchen Scanner sie für ihr spezifisches Risikoprofil investieren sollten:

Schwachstellenkategorie	SAST	DAST	SCA	IAST
SQL-Injection	Stark (Taint-Analyse)	Stark (aktives Testen)	Nein	Strong
XSS	Moderat	Strong	Nein	Strong
Fest codierte Geheimnisse/Anmeldeinformationen	Stark (Mustererkennung)	Nein	Teilweise	Nein
Unterbrochene Authentifizierung	Teilweise (nur Muster)	Strong	Nein	Strong
Anfällige Abhängigkeiten (CVE)	Nein	Nein	Strong	Nein
Kryptografischer Missbrauch	Starke (bekanntermaßen schlechte APIs)	Nein	Teilweise	Teilweise
Fehlkonfiguration der Sicherheit	Teilweise (Konfiguration im Code)	Strong	Nein	Teilweise
SSRF	Stark (Taint-Analyse)	Strong	Nein	Strong
Pfaddurchquerung	Strong	Moderat	Nein	Strong
Befehlsinjektion	Stark (Taint-Analyse)	Strong	Nein	Strong
Codequalität / technische Schulden	Strong	Nein	Nein	Nein
Toter Code	Strong	Nein	Nein	Nein

Code-Scanning im SDLC: Wann was ausführen?

Das Shift-Left-Prinzip in der IT-Sicherheit, das die Schwachstellenerkennung so früh wie möglich im Entwicklungszyklus vorsieht, ist der Grund dafür, dass Code-Scanning zum Standard geworden ist. Die Behebung einer SQL-Injection in der Entwicklungsumgebung (IDE) dauert nur wenige Minuten. Die Entdeckung in der Produktionsumgebung nach einem Sicherheitsvorfall erfordert hingegen wochenlange Reaktion, Behebung und Meldung an die Behörden.

In der IDE: SonarLint, Snyk-IDE-Erweiterungen und Semgrep-IDE-Plugins zeigen Schwachstellen direkt im Code an, während Entwickler schreiben. Ein SQL-Injection-Flag, das beim Schreiben der anfälligen Zeile erscheint, lässt sich in Sekundenschnelle beheben.

Pre-Commit-Hooks: Schnelle SAST-Regeln und Geheimniserkennung werden ausgeführt, bevor der Code ins Repository gelangt. Pre-Commit-Hooks sollten schnell sein (unter zehn Sekunden), da Entwickler sie sonst deaktivieren.

Bei jedem Pull Request: Vollständiger SAST-Scan und SCA-Check. Hier setzen die meisten Teams Qualitätskontrollen durch und blockieren Zusammenführungen, sobald neue kritische Ergebnisse auftreten.

Nächtlich oder wöchentlich: Tiefgreifende interprozedurale Analysen, vollständige DAST-Scans, umfassende SCA-Audits. Diese sind für die Ausführung pro Commit zu langsam, werden aber regelmäßig im Hauptzweig ausgeführt.

Eine vollständige CI/CD-Scankonfiguration:

YAML

# GitHub Actions: layered scanning at the right pipeline stage
name: Code Scanning Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:

jobs:
  sast:
    name: Static Analysis
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Semgrep SAST scan
        uses: semgrep/semgrep-action@v1
        with:
          config: >-
            p/owasp-top-ten
            p/security-audit
            p/secrets

      - name: SonarCloud quality gate
        uses: SonarSource/sonarcloud-github-action@master
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

  sca:
    name: Dependency Scan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Snyk dependency check
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

  secrets:
    name: Secret Detection
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: TruffleHog secret scan
        uses: trufflesecurity/trufflehog@main
        with:
          extra_args: --only-verified

Code-Scanning-Tools: Ein praktischer Überblick

Werkzeug	Typ	Am besten geeignet für	Open Source
Semgrep	SAST	Benutzerdefinierte Regeln, schnelle Scans, Mehrsprachigkeit	Ja (Community-Regeln)
SonarQube / SonarCloud	SAST	Qualität und Sicherheit, CI/CD-Integration, Trendverfolgung	Gemeinschaftsausgabe
CodeQL	SAST	Tiefensemantische Analyse, GitHub-nativ	Ja
Scheckmarx	SAST	Enterprise AppSec-Programme, Compliance	Nein
Snyk-Code	SAST	Entwicklerfreundliche, IDE-zentrierte Sicherheit	Freemium
OWASP ZAP	DAST	Kostenloses DAST, CI/CD-kompatibel	Ja
Burp Suite	DAST	Manuelle und automatisierte Sicherheitstests für Webanwendungen	Gemeinschaftsausgabe
Snyk / Mend	SCA	Abhängigkeitsschwachstellenmanagement	Freemium
OWASP-Abhängigkeits-Check	SCA	CVE-Scanning von Open-Source-Abhängigkeiten	Ja
Contrast Security	IAST	Laufzeitgenauigkeit, geringe Anzahl falsch positiver Ergebnisse	Nein
SMART TS XL	SAST + Struktur	Mehrsprachigkeit, COBOL, Unternehmen, Legacy	Nein

Best Practices für effektives Code-Scanning

Beginnen Sie mit zuverlässigen, fehlerarmen Regeln. Die Ausführung aller verfügbaren Regelsätze am ersten Tag führt zu Tausenden von Ergebnissen, überfordert die Entwickler und hemmt die Akzeptanz. Starten Sie mit einem sorgfältig ausgewählten Satz von Regeln mit hoher Priorität und Zuverlässigkeit, den OWASP Top 10-Mustern, der Erkennung geheimer Funktionen und bekannten gefährlichen Funktionsaufrufen. Fügen Sie weitere Regeln schrittweise hinzu, sobald das Team Vertrauen in die Tools gewonnen hat.

Nur auf neuen Code anwenden. Bei älteren Codebasen mit bereits vorhandenen Sicherheitslücken ermöglicht die Konfiguration von Qualitätsprüfungen, die nur auf im aktuellen Pull Request (PR) eingeführte Sicherheitslücken (und nicht auf die gesamte Codebasis) angewendet werden, die Integration von Sicherheitsprüfungen in den Workflow, ohne einen Rückstand an bereits vorhandenen Sicherheitslücken zu erzeugen, der die gesamte Entwicklung blockiert.

YAML

# SonarQube: new-code quality gate configuration
# Block merges on new critical security hotspots only
sonar.qualitygate.wait=true
sonar.newCode.referenceBranch=main
# Existing findings in main don't block PRs
# Only new findings in the PR diff are gated

Optimieren Sie die Fehlererkennung systematisch. Ein Fehler, den ein Entwickler einmal untersucht und verwirft, ist lästig. Ein Fehler, der sechs Monate lang bei jedem Pull Request auftritt, führt dazu, dass Entwickler die Ergebnisse komplett ignorieren. Etablieren Sie einen Überprüfungsprozess für Unterdrückungen: Jede Unterdrückung erfordert eine dokumentierte Begründung und wird vierteljährlich überprüft.

Ordnen Sie die Ergebnisse den Schweregradstufen zu. Nicht jedes Ergebnis erfordert sofortiges Handeln. Ein abgestuftes Vorgehen:

• Kritische (CVSS 9+, bestätigt ausnutzbar): Bereitstellung blockieren, innerhalb von 24 Stunden beheben
• Hoch (CVSS 7-8): PR-Merge blockieren, innerhalb des Sprints beheben.
• Medium: Zur Aufgabenliste hinzufügen, innerhalb des Quartals bearbeiten
• Niedrig / Informativ: Nachverfolgen, Adressieren während des Refactorings

Messen Sie, was wirklich zählt. Verfolgen Sie die durchschnittliche Zeit bis zur Behebung (MTTR) nach Schweregrad, das Verhältnis von behobenen zu neu gefundenen Fehlern pro Sprint sowie die Falsch-Positiv-Rate im Zeitverlauf. Diese Kennzahlen zeigen Ihnen, ob das Scanprogramm funktioniert und nicht nur, ob der Scanner läuft.

Wie Code-Scanning technische Schulden verhindert

Technische Schulden entstehen, wenn Qualitätsprobleme aufgeschoben werden, beispielsweise wenn ein SQL-Injection-Muster, das durch eine SAST-Regel während der Entwicklung erkannt werden könnte, stattdessen in die Produktionsumgebung gelangt und zur Behebung einen Sicherheitspatch, Regressionstests und eine koordinierte Bereitstellung erfordert. Code-Scanning-Tools fangen diese Schulden direkt an der Quelle ab.

Drei Mechanismen verbinden Code-Scanning direkt mit der Reduzierung technischer Schulden:

Komplexitätserkennung. Zyklomatische Komplexität oberhalb eines bestimmten Schwellenwerts, tief verschachtelte Bedingungen und lange Funktionen sind Code-Smells, die von Scanning-Tools erkannt werden. Werden diese Muster nicht behoben, häufen sie sich in Codebasen an, deren Änderung zunehmend schwieriger und kostspieliger wird. Scanning liefert die metrikbasierte Frühwarnung, die zu Refactoring anregt, bevor die Komplexität strukturell wird.

Erkennung von Duplikaten. Doppelt geschriebener Code zählt zu den teuersten Formen technischer Schulden. Jede Fehlerbehebung und Funktionsänderung muss an mehreren Stellen vorgenommen werden, und Kopien weichen zwangsläufig voneinander ab. Die Duplikaterkennung von SonarQube und ähnliche Regeln decken dieses Muster im gesamten Code auf und ermöglichen so die Konsolidierung, bevor Abweichungen zu Inkonsistenzen führen.

Identifizierung von totem Code. Toter Code, also Funktionen und Module, die in der Produktion nie aufgerufen werden, vergrößert die Codebasis unnötig, verwirrt Entwickler und erschwert die Migrationsanalyse. Scanning-Tools, die eine Erreichbarkeitsanalyse durchführen, identifizieren toten Code systematisch und ermöglichen so dessen Entfernung, bevor er sich weiter anhäuft.

Der kumulative Effekt: Eine Codebasis, die kontinuierlich gescannt wird, weist eine geringere Fehlerdichte, eine geringere zyklomatische Komplexität, eine geringere Duplikationsrate und einen geringeren Anteil an ungenutztem Code auf als eine vergleichbare Codebasis ohne Scanning. Diese Kennzahlen führen direkt zu einer schnelleren Feature-Entwicklung, geringeren Wartungskosten und einem reduzierten Risiko von Produktionsvorfällen.

Wie SMART TS XL Bietet Code-Scanning im Unternehmensmaßstab

Standardmäßige Code-Scanning-Tools arbeiten innerhalb einer einzigen Sprache. In Unternehmensumgebungen, in denen Java-Dienste, Python-Pipelines, COBOL-Batchprogramme, JCL-Jobstreams und RPG-Module nebeneinander existieren und jeweils einen eigenen Scanner mit eigener Konfiguration und eigenem Ergebnis-Dashboard benötigen, ist das Bild des Code-Scannings fragmentiert.

SMART TS XL statische Code-Analyse Es scannt gleichzeitig alle Sprachen der Umgebung – COBOL, JCL, Java, Python, RPG, PL/I, SQL und moderne Technologien – und liefert in einem einzigen Analysedurchlauf einheitliche Qualitätsmetriken, Sicherheitsergebnisse und Strukturdaten für das gesamte Portfolio. Für Unternehmen mit älteren Mainframe-Anwendungen und modernen Cloud-Diensten ist diese sprachübergreifende Abdeckung der entscheidende Unterschied zwischen einem Scanprogramm, das nur die modernen Technologien abdeckt, und einem, das das gesamte System erfasst.

Die Funktion zur Abbildung von Anwendungsabhängigkeiten erweitert die Analyse über einzelne Dateien hinaus auf die Architektur: Welche Komponenten weisen die stärkste Kopplung auf, wo existieren zirkuläre Abhängigkeiten und welche Programme teilen Daten über implizite Dateischnittstellen anstatt über explizite APIs? Diese strukturellen Erkenntnisse decken architektonische Sicherheits- und Qualitätsprobleme auf, die mit herkömmlichen Methoden zur Mustererkennung einzelner Dateien nicht erkannt werden können.

Die Auswirkungsanalyse ermöglicht es, Scan-Ergebnisse in großem Umfang umzusetzen: Wird eine Schwachstelle in einer stark frequentierten Komponente gefunden, von der 150 Programme abhängen, definiert die Auswirkungsanalyse den Umfang der Behebungsmaßnahmen, legt fest, welche Programme getestet und welche Aufrufer aktualisiert werden müssen und wie weitreichend die Korrektur insgesamt ist. So werden Schwachstellenfunde von einer Liste von Problemen in ein strukturiertes Behebungsprogramm mit definiertem Umfang umgewandelt.

Die unternehmensweite Suchfunktion ermöglicht die Abfrage der Scan-Ergebnisse über das gesamte Portfolio hinweg: Finden Sie innerhalb von Sekunden jedes Programm, das eine bestimmte unsichere API verwendet, jede Datei, die fest codierte Anmeldeinformationen enthält, jede Komponente, die einen Komplexitätsschwellenwert überschreitet, über Millionen von Codezeilen in beliebiger Kombination von Sprachen.

Für Teams, die verwalten Modernisierung des Altbestands Programme, SMART TS XLDie Scans liefern die Qualitätsgrundlage vor der Migration: den toten Code, der vom Migrationsbereich ausgeschlossen ist, die Komplexitätsverteilung, die die Migrationsreihenfolge bestimmt, und die Sicherheitsbefunde, die behoben werden müssen, bevor der konvertierte Code in der Cloud-Infrastruktur bereitgestellt wird.

Frühzeitig scannen, kontinuierlich scannen, alles scannen

Die Organisationen mit der kürzesten durchschnittlichen Zeit zur Behebung von Sicherheitslücken sind nicht diejenigen mit den aggressivsten Penetrationstests. Sie sind diejenigen, die die meisten Schwachstellen aufdecken, bevor diese die Code-Review-Phase, die Entwicklungsumgebung, den Pre-Commit-Hook oder die CI/CD-Pipeline erreichen. Code-Scanning ist der Schlüssel dazu.

Die Entwicklung eines Scanning-Programms erfordert die Auswahl der richtigen Kombination aus SAST, DAST, SCA und IAST für Ihr Risikoprofil, deren Integration zum richtigen Zeitpunkt im Entwicklungszyklus, die Optimierung zur Minimierung von Störungen ohne Einbußen bei der Abdeckung und die kontinuierliche Messung der Programmeffektivität, anstatt von einem laufenden Scanner auszugehen. Ein laufender Scanner ist der Anfang, ein funktionierendes Programm das Ziel.