Sicherheitslücken-Scanning

Das echte Ausmaß des Problems

Die National Vulnerability Database des NIST verzeichnet jährlich über 25.000 neue Sicherheitslücken, 2024 waren es mehr als 38.000. Diese Schwachstellen betreffen zu einem erheblichen Teil Open-Source-Bibliotheken, die in fast jedem Software-Projekt stecken: npm-Pakete, Python-Dependencies, Maven-Artefakte, Docker-Base-Images.

Der “Cost of a Data Breach Report 2026” von IBM beziffert den durchschnittlichen Schaden einer Datenpanne weltweit auf 4,99 Millionen US-Dollar, für den deutschen Mittelstand kleiner, aber die Logik ist dieselbe: Forensik-Kosten, Benachrichtigung betroffener Personen, DSGVO-Bußgelder, Reputationsschäden.

Das eigentliche Problem ist die Zeit bis zur Entdeckung. Eine Bibliothek mit bekannter Lücke bleibt so lange im Build, bis jemand nachsieht, und ohne automatische Prüfung sieht niemand regelmäßig nach. Der CVE ist dann längst veröffentlicht, nur nicht bei euch angekommen.

Früher ist billiger, aber um welchen Faktor? Die oft zitierte Reihe 1, 6, 15 und 100 für Design, Coding, nach dem Deployment und nach einem Vorfall wird gern dem NIST zugeschrieben, eine prüfbare Studie dahinter haben wir nicht gefunden. Belegt ist die Richtung: Ein Fix im Pull Request ist ein Versions-Bump oder eine Codezeile und betrifft einen Entwickler. Ein Fix nach einem Vorfall betrifft Forensik, Kunden und oft Behörden.

“Shift Left Security”, Sicherheitsscanning früh in den Entwicklungsprozess zu integrieren, ist keine optionale Best Practice. Es setzt dort an, wo ein Fix am wenigsten kostet.

Mit vs. ohne KI, ein ehrlicher Vergleich

Qualitativer Vergleich. Belastbare Vorher-nachher-Zahlen gibt es für diesen Use Case nicht, bei euch messbar sind die offenen Findings und die Tage vom Fund bis zum Fix.

Einschätzung auf einen Blick

Zeitersparnis, sehr niedrig (1/5) Sicherheitslücken-Scanning spart keine tägliche Entwicklerzeit, es fügt sogar einen Review-Schritt hinzu. Der Wert liegt in der Vermeidung von Incidents, nicht in der täglichen Effizienz. Deshalb einer der niedrigsten Werte im Branch für Zeitersparnis, der Use Case hat eine andere Wirkungslogik: Prävention statt Effizienz.

Kosteneinsparung, mittel (3/5) Die Tools sind billig, 0 bis rund 300 US-Dollar im Monat für zehn Entwickler. Teuer ist die Arbeit dahinter: Findings sichten, Fehlalarme aussortieren, Updates einspielen und testen. Ob sich das rechnet, hängt an einer Zahl, die niemand kennt, der Wahrscheinlichkeit eines Vorfalls, und daran, dass jemand die gemeldete Lücke auch schließt. Ein Scanner meldet bekannte Schwachstellen und typische Muster, er verhindert keinen Vorfall mit Sicherheit, und Lücken, die noch in keiner Datenbank stehen, sieht er nicht.

Schnelle Umsetzung, mittel (3/5) Dependabot ist in 1 Stunde aktiv. Vollständige SAST-Integration in CI/CD dauert 2–4 Tage. Secret-Scanning der gesamten Git-History ist ein eigenes Projekt. Kein trivialer Einstieg, aber klar machbar ohne spezialisiertes Security-Team.

ROI-Sicherheit, mittel (3/5) Messbar sind offene Findings, Tage vom Fund bis zum Fix und gefundene Secrets. Den verhinderten Schaden misst niemand, man beweist schwer etwas, das nicht eingetreten ist. Für viele stellt sich die ROI-Frage aber gar nicht: Softwarehersteller brauchen nach dem Cyber Resilience Act ein Schwachstellenmanagement, wichtige und besonders wichtige Einrichtungen nach § 30 BSIG ebenso, und ISO 27001 oder BSI IT-Grundschutz verlangen es im Audit.

Skalierbarkeit, hoch (4/5) Mehr Code bedeutet mehr Findings, das Scanning skaliert mit. Herausforderung: Finding-Volumen steigt, und ohne gute Priorisierung führt das zu Finding-Fatigue. Gute Tools (Snyk, SonarQube) haben Triage-Funktionen, die den Rückstand strukturierbar machen.

Richtwerte, stark abhängig von Codebase-Komplexität, Regulierungsumfeld und Incident-Geschichte.

Was das System konkret macht

Schritt 1, Dependency-Scanning (bekannte CVEs): Alle Third-Party-Dependencies werden automatisch gegen die CVE-Datenbank geprüft. Tools wie Snyk , Dependabot (GitHub) oder OWASP Dependency-Check laufen als CI/CD-Job bei jedem Pull Request und melden bekannte Schwachstellen, inklusive Severity-Level und verfügbaren Fix-Versionen. Dependabot ist mit einem Click aktivierbar für bestehende GitHub-Projekte.

Schritt 2, Static Application Security Testing (SAST): SAST analysiert den selbstgeschriebenen Code auf Schwachstellenmuster: SQL-Injection-Risiken, XSS-Vektoren, unsichere Konfigurationen, hardcoded Secrets, ungesicherte Deserialisierung. Moderne SAST-Tools mit KI-Unterstützung reduzieren die False-Positive-Rate erheblich, ein klassisches Problem älterer Tools war, dass so viele potenzielle Findings generiert wurden, dass Entwickler sie als Rauschen ignorierten.

Schritt 3, Secret Detection: Hardcoded API-Keys, Passwörter, SSH-Schlüssel und Datenbank-Credentials sind ein häufiger Einfallsvektor. Tools wie GitLeaks oder TruffleHog scannen sowohl neuen Code als auch die gesamte Git-History auf aus Versehen committete Secrets. Wichtig: Ein Secret, das vor zwei Jahren committed und dann gelöscht wurde, ist in der Git-History noch vorhanden, und potenziell auffindbar.

Schritt 4, KI-gestützte Fix-Vorschläge: Der eigentliche KI-Mehrwert: Moderne Tools liefern nicht nur die Schwachstelle, sondern eine verständliche Erklärung der Ursache und einen konkreten Fix-Vorschlag, manchmal als direkt anwendbaren Patch. Ein Entwickler, der “SQL-Injection-Risiko in Zeile 47” liest, braucht noch Expertise. Ein Entwickler, der “Verwende parameterized queries statt String-Konkatenation, hier ist der Code” liest, kann direkt handeln.

Rechtliche Besonderheiten

Cyber Resilience Act: Wer Software als Produkt mit digitalen Elementen in der EU in Verkehr bringt, fällt unter die Verordnung (EU) 2024/2847, die Cyberresilienz-Verordnung. Seit dem 11. September 2026 gilt ihre Meldepflicht aus Art. 14: Eine aktiv ausgenutzte Schwachstelle im eigenen Produkt geht binnen 24 Stunden als Frühwarnung und binnen 72 Stunden als Meldung an das koordinierende CSIRT und die ENISA, der Abschlussbericht folgt spätestens 14 Tage, nachdem ein Fix verfügbar ist. Die übrigen Pflichten, darunter das Schwachstellenmanagement über den ganzen Lebenszyklus mit einer Software-Stückliste (SBOM), gelten ab dem 11. Dezember 2027. Ohne automatischen Überblick über die eigenen Abhängigkeiten ist keine dieser Fristen zu halten.

NIS2 und BSI-Gesetz: Deutschland hat die NIS2-Richtlinie (EU) 2022/2555 mit dem neuen BSI-Gesetz umgesetzt. § 30 Abs. 2 Nr. 5 BSIG verlangt von besonders wichtigen und wichtigen Einrichtungen “Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von informationstechnischen Systemen, Komponenten und Prozessen, einschließlich Management und Offenlegung von Schwachstellen”, in der Richtlinie ist das Art. 21 Abs. 2 Buchst. e. Erfasst sind unter anderem Cloud- und Managed-Service-Anbieter ab einer bestimmten Größe, ein Softwarehaus, das nur Lizenzen verkauft, fällt nicht automatisch darunter. Ob ihr betroffen seid, hängt an Sektor und Größe, das prüfst du vor jeder Maßnahme.

BSI IT-Grundschutz (CON.8, Software-Entwicklung): Anforderung CON.8.A7 sagt wörtlich: “Darüber hinaus SOLLTE eine automatische statische Code-Analyse durchgeführt werden.” CON.8.A20 verlangt, unbekannte externe Komponenten auf Schwachstellen zu prüfen. Für Unternehmen, die ISO 27001 oder BSI-Grundschutz-Zertifizierungen anstreben, ist automatisiertes Sicherheitsscanning deshalb oft Teil des Audit-Nachweises.

DSGVO und Sicherheitsmaßnahmen: Art. 32 DSGVO verpflichtet zur “Sicherheit der Verarbeitung”, das umfasst angemessene technische Maßnahmen zum Schutz personenbezogener Daten. Ein System ohne systematisches Sicherheitsscanning ist in einem Datenschutz-Audit schwer zu rechtfertigen.

Haftung bei Sicherheitsvorfällen: Wenn bekannte, behebbare Schwachstellen (dokumentierte CVEs) nicht behoben werden, obwohl automatische Tools sie gemeldet haben, entsteht ein dokumentiertes Wissen, das in einem Schadensfall rechtlich relevant sein kann.

Konkrete Werkzeuge

Snyk , Marktführer für entwicklerorientiertes Security-Scanning. Integriert sich in GitHub, GitLab und direkt in die IDE. Besonders stark: Snyk Container scannt Docker-Images, Snyk Infrastructure as Code prüft Terraform/Kubernetes-Konfigurationen. Verständliche, entwicklerfreundliche Berichte mit direkten Fix-Empfehlungen. Kostenloser Plan mit begrenzten Tests, der Team-Plan kostet 25 US-Dollar je aktivem Entwickler und Monat, für 5 bis 10 Entwickler.

SonarQube , Etabliertes SAST-Tool mit umfangreichem Regelwerk. Kann vollständig on-premise betrieben werden, relevant für Teams, die keinen Code an externe Dienste senden dürfen. Der selbst gehostete Community Build ist kostenlos und open-source. Die Cloud-Variante kostet im Team-Plan ab 32 US-Dollar im Monat (bis 100.000 Codezeilen), die selbst gehosteten Server-Editionen mit erweiterten Sicherheitsregeln werden je Instanz nach Codezeilen auf Anfrage bepreist.

GitHub Advanced Security / Dependabot, Für Teams, die GitHub nutzen: Dependabot ist kostenlos und überwacht Dependencies automatisch. GitHub Advanced Security mit CodeQL für tiefe Code-Flow-Analyse ist in GitHub Enterprise enthalten oder separat buchbar.

Semgrep, Open-Source SAST mit anpassbaren Regelsets. Schnell, leichtgewichtig, gut als CI-Job integrierbar. Für Teams, die eigene Security-Regeln für interne Bibliotheken oder Coding-Konventionen schreiben wollen.

GitGuardian , Spezialisiert auf Secret Detection: Scannt in Echtzeit auf API-Keys, Credentials und Tokens, sowohl in neuen Commits als auch rückwirkend in der gesamten Repository-History. Kostenlos für Teams bis 25 Entwickler, den Business-Plan bepreist GitGuardian individuell.

Datenschutz und Datenhaltung

Code-Datenschutz beim Scanning: Ähnlich wie bei KI-Code-Reviews stellt sich die Frage, ob proprietärer Code externe Dienste erreicht. Snyk und GitHub Advanced Security verarbeiten Code in der Cloud, bei Snyk gibt es eine EU-Region in Frankfurt nur im Enterprise-Plan. SonarQube Self-Hosted bleibt vollständig on-premise, die richtige Wahl für regulierte Branchen.

DSGVO bei Security-Logs: Security-Scan-Ergebnisse und Vulnerability-Reports können Informationen enthalten, die sich auf Code mit personenbezogenen Daten beziehen. Auch diese Daten brauchen angemessene Zugriffskontrolle.

Secrets nach Rotation: Wenn ein hardcoded Secret in der Git-History gefunden wird, reicht Löschen nicht, die Rotation des Secrets (API-Key neu generieren, Passwort ändern) ist zwingend. Das ist koordinationsaufwändig aber nicht verhandelbar.

Was es kostet

Sofortstart (Dependabot + kostenlose Snyk-Basis):

• Kosten: 0 € für Open-Source und kleine Teams
• Einrichtungsaufwand: 1–2 Stunden
• Sofortige Wirkung: Alle bekannten CVEs in Dependencies werden gemeldet

Vollständiges Setup (Snyk + SonarQube, 10-köpfiges Dev-Team):

• Snyk Team: 10 Entwickler mal 25 US-Dollar im Monat
• SonarQube Cloud Team: ab 32 US-Dollar im Monat, selbst gehostet nach Codezeilen auf Anfrage
• Einrichtungsaufwand: 2–4 Tage für vollständige CI/CD-Integration
• Der größere Posten ist Arbeitszeit: erste Sichtung, Fehlalarme aussortieren, Updates einspielen und testen (siehe Fehler 1)

ROI-Szenario: Rechne mit euren eigenen Zahlen statt mit fremden. Wie lange hat der letzte Patch nach einem Deployment gedauert, vom Bekanntwerden bis zum Release, und wie viele Personen waren beteiligt? Daniel aus dem Beispiel oben hat sechs Stunden Analyse plus Notfall-Patchrunde gebraucht. Das ist dein Vergleichswert für einen Versions-Bump im Pull Request. Den großen Posten, einen Sicherheitsvorfall, verhindert ein Scanner nicht mit Sicherheit: Er meldet, schließen muss die Lücke ein Mensch, und was in keiner Datenbank steht, sieht er nicht. Die Lizenzen aus der Liste oben fallen daneben kaum ins Gewicht, die Arbeitszeit für Sichtung und Fixes schon. Wer Software in der EU als Produkt verkauft, braucht diese Arbeitszeit ab dem 11. Dezember 2027 ohnehin, dann verlangt der Cyber Resilience Act ein Schwachstellenmanagement über den ganzen Lebenszyklus.

Drei typische Einstiegsfehler

1. Den ersten SAST-Scan ohne Priorisierungsregel starten. Wer auf einer gewachsenen Codebase zum ersten Mal Snyk oder SonarQube aktiviert, erhält oft mehrere Hundert Findings, ein großer Teil davon Low- oder Medium-Schwere-Probleme in transitiven Dependencies ohne direktes Angriffspotenzial. Teams, die ohne Filter alle Findings aufnehmen, stellen das Tool nach zwei Wochen ab. Konkrete Gegenmaßnahme: Erste vier Wochen ausschließlich Critical- und High-Findings im direkt eigenen Code bearbeiten (CVSS-Score ≥ 7.0, nicht-transitive Dependency), alle anderen in einen priorisierten Rückstand überführen.

2. Den Security-Gate zu früh als harten Block einrichten. Wenn SAST-Findings den Merge blockieren, bevor das Team die False-Positive-Rate verstanden hat, entsteht Frust und Umgehungsverhalten. Empfehlung: Ersten Monat im Warn-Modus, Findings anzeigen, aber nicht blockieren. Nach Kalibrierung: nur Critical-Findings blockieren.

3. Secret-Rotation nach Fund vergessen. Wenn GitGuardian oder TruffleHog ein aus Versehen committetes Secret findet und es aus dem Code entfernt wird, aber nicht rotiert, ist das Problem nur halb gelöst. Der Secret-Wert ist in der Git-History und bei allen, die das Repository gecloned haben. Immer rotieren, nicht nur löschen.

Was mit der Einführung wirklich passiert

Erster Scan, erste Schockwelle: Fast jede Codebase, die noch kein systematisches Scanning hatte, produziert beim ersten Durchlauf mehr Findings als erwartet. Das ist keine Katastrophe, es ist Transparenz. Die Findings existierten bereits, jetzt sind sie sichtbar.

Priorisierungsphase: In den ersten 2–4 Wochen wird die Fähigkeit zur Priorisierung wichtiger als das Scannen selbst. Welche Findings sind wirklich kritisch? Welche sind False Positives? Welche können geplant werden? Teams, die diese Phase strukturiert angehen (nach CVSS-Score priorisieren, nicht nach Anzahl), kommen schneller zu einem produktiven Betrieb.

Langfristige Kulturveränderung: Das eigentliche Ziel von Shift-Left-Security ist nicht das Tool, es ist das Bewusstsein. Entwickler, die täglich mit Security-Findings im PR-Prozess arbeiten, entwickeln über 6–12 Monate ein deutlich stärkeres Sicherheitsbewusstsein. Sie schreiben von Anfang an sichereren Code, weil sie die Muster kennen.

Realistischer Zeitplan

Häufige Einwände

„Wir haben Security-Reviews in unserem Release-Prozess, das reicht.” Manuelle Security-Reviews vor Release skalieren nicht mit der Deployment-Frequenz. Teams, die mehrmals täglich deployen, können nicht jeden Release manuell prüfen. Automatisches Scanning ist kein Ersatz für gutes Security-Verständnis, aber es ist die Grundlage auf der menschliche Reviews aufbauen können, nachdem die offensichtlichen Probleme bereits gefiltert wurden.

„Die vielen Findings überfordern unser Team.” Das ist der häufigste Grund, warum Scanning-Tools nach dem ersten Anlauf ignoriert werden. Lösung: Priorisierung. Nur Critical- und High-Findings im genutzten Code sind wirklich dringlich. Snyk und SonarQube haben Triage-Funktionen für strukturierten Abbau des Rückstands.

„Unser Code läuft intern und ist nicht aus dem Internet erreichbar.” Interne Systeme sind ein beliebtes Angriffsziel, gerade weil die Annahme, sie seien sicher, dazu führt, dass Security vernachlässigt wird. Supply-Chain-Angriffe, Insider-Bedrohungen und Phishing auf Entwickler-Accounts können Schwachstellen in internen Systemen trotzdem ausnutzen.

Woran du merkst, dass das zu dir passt

• Ihr nutzt mehr als 10 externe npm/pip/Maven-Pakete und überprüft keine davon systematisch auf bekannte Schwachstellen
• Security-Reviews finden nur kurz vor dem Release statt, nicht kontinuierlich im Entwicklungsprozess
• Ihr habt schon einmal versehentlich einen API-Key oder ein Passwort in ein Git-Repository committed

Das passt noch nicht, wenn:

• Euer System ist ein komplett isoliertes Air-Gap-System ohne externe Dependencies und ohne Netzwerkzugriff, dann gibt es keinen Angriffspfad, den Dependency-Scanning adressiert.
• Euer Team hat noch keine CI/CD-Pipeline, Security-Gates setzen eine funktionierende Build-Pipeline voraus. Erst die CI/CD-Basis aufbauen, dann Security integrieren.
• Ihr entwickelt kein eigenes Software-System, sondern nutzt ausschließlich fertige SaaS-Produkte, dann liegt die Verantwortung für Patch-Management beim jeweiligen Anbieter, nicht bei euch.
• Euer Team ist kleiner als 2 Entwickler und der gesamte Stack besteht aus weniger als 5 Dependencies, der Setup-Aufwand für vollständiges SAST übersteigt den Nutzen. Dependabot reicht.

Das kannst du heute noch tun

Aktiviere Dependabot in deinem GitHub-Repository, Settings → Security → Dependabot alerts. Das dauert 2 Minuten und zeigt dir innerhalb einer Stunde, welche bekannten CVEs in euren Dependencies stecken. Kein Code-Änderung, keine Integration, keine Kosten.

Quellen & Methodik

• NIST National Vulnerability Database (NVD), CVE-Statistiken 2024.
• IBM “Cost of a Data Breach Report 2026”, ibm.com/reports/data-breach: weltweiter Durchschnittsschaden einer Datenpanne 4,99 Millionen US-Dollar.
• BSI IT-Grundschutz-Kompendium, Baustein CON.8 Software-Entwicklung (Edition 2023): CON.8.A7 automatische statische Code-Analyse, CON.8.A20 Überprüfung externer Komponenten.
• Verordnung (EU) 2024/2847 (Cyberresilienz-Verordnung): Art. 14 Meldepflichten für aktiv ausgenutzte Schwachstellen ab 11. September 2026, allgemeiner Geltungsbeginn nach Art. 71 am 11. Dezember 2027.
• NIS2-Richtlinie (EU) 2022/2555, Art. 21 Abs. 2 Buchst. e; in Deutschland umgesetzt in § 30 Abs. 2 Nr. 5 BSIG (gesetze-im-internet.de/bsig_2025).
• Preise: unsere Toolseiten zu Snyk, SonarQube und GitGuardian.