Code-Scanning erkennt Schwachstellen bereits während der Entwicklung. Dieser Leitfaden zeigt die wichtigsten Verfahren und Best Practices für eine sichere Softwareentwicklung.
Sicheres Code-Scanning im Überblick
Beim Secure Code-Scanning wird Quellcode automatisch analysiert, um Sicherheitslücken frühzeitig zu identifizieren. Dazu gehört das Aufspüren von Schwachstellen wie SQL-Injection, fest im Code hinterlegten Secrets, unsicheren Abhängigkeiten und Fehlkonfigurationen im eigenen Code, in Bibliotheken von Drittanbietern, in Container-Images und in Infrastruktur-Templates. So lassen sich ausnutzbare Schwachstellen früh erkennen – bevor Angreifer sie ausnutzen und solange sich Fehler noch kostengünstig beheben lassen.
In CI/CD-Pipelines integriert, wirkt Code-Scanning als automatischer Kontrollpunkt: Es markiert riskanten Code, bevor er zusammengeführt wird, senkt die Zahl der Schwachstellen, die in die Produktion gelangen, und reduziert die Kosten späterer Korrekturen.
Von Code-Scanning erkannte Schwachstellen
Code-Scanning-Werkzeuge erkennen Schwachstellen in mehreren Kategorien, von Injection-Fehlern über Schwächen bei der Authentifizierung bis hin zu offengelegten Secrets und unsicheren Abhängigkeiten. Es gibt mehrere verbreitete Schwachstelle Typen mit jeweils eigenen Erkennungsmechanismen:
| Schwachstelle | Erkennungsmechanismus |
|---|---|
| SQL-Injection | Sucht nach fehlender Eingabebereinigung und weiteren Designfehlern, durch die Nutzer SQL-Abfragen ohne ausreichende Bereinigung direkt in Eingabefelder eingeben können. |
| cross-site request forgery | Erkennt unzureichende Eingabevalidierung oder unsichere Systemtoken, mit denen Angreifer das Vertrauen eines Zielsystems in einen wiederkehrenden Nutzer ausnutzen. |
| remote code execution (RCE) | Sucht nach Fehlkonfigurationen oder mangelhaften Validierungsmechanismen, die es Angreifern erlauben, aus der Ferne beliebigen Code auszuführen. |
| Buffer Overflows | Erkennt Fehlkonfigurationen, durch die sich einem Puffer mehr Daten übergeben lassen, als er normalerweise aufnehmen kann. |
| fest hinterlegte Secrets | Sucht nach hochentropischen oder bekannten Mustern, die auf Secrets wie API-Token oder Admin-Passwörter im Code hinweisen. |
Bei der Ollama-RCE-Schwachstelle vom Juni 2024 entdeckte das Wiz Research Team eine ausnutzbare remote code execution (CVE-2024-37032) in Ollama, einem verbreiteten Open-Source-Projekt zum Ausführen von KI-Modellen. Diese Schwachstelle erlaubte es Angreifern, gezielt präparierte HTTP-Anfragen an den offen erreichbaren API-Server von Ollama zu senden.
Das Sicherheitsproblem ist inzwischen behoben. Dennoch lässt sich aus diesem Angriff eine wesentliche Lehre ziehen, die für Entwickler von KI-Projekten und jeder mit dem Internet verbundenen Software gilt: Code-Scanning ist entscheidend, um Fehlkonfigurationen und Sicherheitsrisiken wie RCE-Schwachstellen zu korrigieren.
Bedeutung von Code-Scanning
Jede Codebasis enthält Schwachstellen. Entscheidend ist, ob man sie vor den Angreifern findet. KI-gestützte Entwicklungswerkzeuge haben den Umfang des ausgelieferten Codes drastisch erhöht, während moderne KI-Modelle wie Anthropics Claude Mythos gezeigt haben, dass sie eigenständig Zero-Day-Schwachstellen aufspüren und innerhalb von Stunden funktionierende Exploits erzeugen können. Auf der einen Seite wächst die Menge des Codes, auf der anderen Seite steigt das Tempo der Ausnutzung. Code-Scanning schließt diese Lücke, indem es die Erkennung früher in den Entwicklungszyklus verlagert, wo Korrekturen schneller, günstiger und weniger störend sind als nach einem Sicherheitsvorfall.
Schnelle Release-Zyklen hinterlassen Fehler und Sicherheitslücken
Schnellere Release-Zyklen lassen weniger Zeit für die manuelle Sicherheitsprüfung, wodurch mehr Schwachstellen in die Produktion gelangen. Code-Scanning löst das, indem es automatisch bei jedem Commit oder Pull Request läuft und Probleme in Echtzeit erkennt, ohne Entwickler auszubremsen.
Je früher der Code gescannt wird, desto günstiger wird die Korrektur. Eine im IDE erkannte Schwachstelle kostet Minuten. Derselbe Fehler kann im Produktivbetrieb Wochen an Aufwand für die Reaktion auf Sicherheitsvorfälle und die Behebung verursachen.
Sicherheitsverletzungen nehmen zu
Laut einer Studie von Forrester wurden 2025 mehr als 10,6 Milliarden Datensätze offengelegt, das sind fast 30.000 pro Tag. Code-Scanning erkennt Schwachstellen auf Code-Ebene, wie Injection-Fehler oder offengelegte Zugangsdaten, schon vor der Bereitstellung und reduziert so die Angriffsfläche, die überhaupt erst zu Sicherheitsverletzungen führt.
Datenschutzverletzungen sind teuer
Die Folgen von Datenschutzverletzungen reichen weit: Strafen wegen Verstößen gegen Vorschriften, Klagen, Reputationsschäden und der Verlust von Kundenvertrauen. Eine Sicherheitsverletzung kostet Unternehmen inzwischen weltweit im Schnitt 4,4 Millionen USD. Bei größeren Unternehmen liegt der reale Aufwand oft um ein Vielfaches höher, sobald Anwaltskosten, Vergleiche und vorgeschriebene Sicherheitsausgaben hinzukommen.
Ansätze für Code-Scanning
Verschiedene Scan-Techniken erkennen unterschiedliche Schwachstellentypen. Kein einzelner Ansatz deckt alle Sicherheitsrisiken ab. Erst die Kombination verschiedener Scan-Verfahren schafft eine mehrschichtige Strategie, die Schwachstellen zuverlässig aufdeckt.
| Technik/Werkzeug | Beschreibung |
|---|---|
| static application security testing (SAST) | Statische Analysewerkzeuge scannen ruhenden Quellcode, um verbreitete Sicherheitsrisiken zu erkennen, etwa veraltete Software-Pakete, Probleme bei der Zugriffssteuerung, nicht bereinigte externe Eingaben und Buffer Overflows. |
| dynamic application security testing (DAST) | Die dynamische Analyse simuliert Angriffe, um Laufzeit-Schwachstellen wie remote code execution (RCE), Race Conditions und cross-site request forgery (CSRF) zu erkennen. |
| software composition analysis (SCA) | SCA-Werkzeuge prüfen Quellcode, Binärdateien, Container-Images, Paketmanager und mehr auf Abhängigkeiten und zugehörige bekannte Schwachstellen, indem sie die Abhängigkeiten mit Schwachstellendatenbanken wie der National Vulnerability Database (NVD) abgleichen. |
| interactive application security testing (IAST) | IAST kombiniert Elemente von SAST und DAST. |
| Secrets-Scanning | Secrets-Scanning-Werkzeuge analysieren öffentliche Repositories, Container-Images, DevOps-Pipelines und mehr auf fest hinterlegte Zugangsdaten, um unbefugten Zugriff auf sensible Cloud-Infrastruktur zu verhindern. |
Grenzen des Code-Scannings
Jede Scan-Technik hat blinde Flecken. Zum Beispiel:
SAST erfasst kein Laufzeitverhalten;
DAST sieht den Quellcode nicht;
SCA kennt nur die deklarierten Abhängigkeiten.
Die Folge sind False Positives, die Zeit kosten, und übersehene echte Schwachstellen, die durchrutschen.
Mehrere Techniken zu kombinieren hilft, doch die eigentliche Lösung liegt darin, Kontext hinzuzufügen. Eine Schwachstelle in Code, der nie in Betrieb geht oder hinter einer Firewall ohne Zugriff auf sensible Daten läuft, ist weit weniger dringend als derselbe Fehler in einem im Internet exponierten Dienst, der personenbezogene Kundendaten verarbeitet. Werkzeuge, die Funde damit verknüpfen, wie stark Code zur Laufzeit tatsächlich exponiert ist, helfen Teams, sich auf das Wesentliche zu konzentrieren.
Der Einfluss von KI auf das Code-Scanning
KI-gestützte Werkzeuge wie die native SAST-Lösung von Wiz zeigen sich beim Code-Scanning an zwei Stellen: beim Verstehen, was ein Fund bedeutet, und beim Beheben. KI spielt außerdem eine wachsende Rolle bei der sicheren Code-Erzeugung und beim Identifizieren von Schwachstellen, mit dem Ziel, den Aufwand fürs Lesen und Umschreiben zu senken.
So setzen Teams KI heute praktisch ein:
Schnellere Triage: KI erklärt, warum ein Fund relevant ist, fasst den Datenfluss zusammen und hilft dabei, wahrscheinliche False Positives zu erkennen, damit keine Zeit mit Rauschen vergeht;
Besser nutzbare Korrekturen: KI schlägt sicherere Muster vor und entwirft Änderungen für Pull Requests, besonders bei Eingabevalidierung, Escaping, Authentifizierungsprüfungen und sichererer Nutzung von Bibliotheken;
Klarere Übergaben der Zuständigkeit: KI formt die Ausgabe eines Scanners in ein kurzes Ticket um, das ein Entwickler bearbeiten kann, ohne erst zum Sicherheitsexperten werden zu müssen.
Ein kurzer Realitätscheck: KI kann nicht erraten, wie stark etwas zur Laufzeit exponiert ist, welche IAM-Berechtigungen gelten oder welche Netzwerkpfade bestehen. Werden die Scan-Ergebnisse nicht mit dem tatsächlichen Laufzeitkontext verknüpft, priorisieren Teams weiterhin die falschen Schwachstellen.
7 zentrale Best Practices für Code-Scanning
1. Richtlinie zum Schutz des Quellcodes erstellen
Eine Richtlinie legt fest, wer auf Repositories und Pipelines zugreifen darf, wie Code im Ruhezustand und bei der Übertragung verschlüsselt wird und wann Scans laufen. Eine dokumentierte Richtlinie verhindert spontane Entscheidungen, die Lücken in der Abdeckung erzeugen.
2. Werkzeuge passend zu Stack und Arbeitsablauf wählen
Bei der Bewertung von Scannern haben folgende Punkte Vorrang:
Abdeckung von Sprachen und Frameworks: das Werkzeug sollte jede Sprache im Stack unterstützen, ohne separate Konfigurationen zu verlangen;
CI/CD-Integration: Scans sollten automatisch bei Commits und Pull Requests laufen, ohne manuelle Auslöser;
Priorisierung und Kontext: sinnvoll sind Werkzeuge, die Funde nach Ausnutzbarkeit einordnen, nicht nur nach Schweregrad;
umsetzbare Hinweise zur Behebung: Berichte sollten Entwicklern genau sagen, was zu beheben ist, nicht nur, was falsch ist;
aktuelle Schwachstellendaten: die Datenbank des Scanners sollte neu veröffentlichte CVEs innerhalb von Tagen statt Monaten abbilden.
3. Sicherheitslücken im Code früh prüfen
Ein Shift-Left-Ansatz berücksichtigt Sicherheit bereits früh im Entwicklungsprozess – ganz im Sinne von Secure by Design. So arbeiten DevSecOps-Teams enger zusammen und erkennen Schwachstellen früher. Das spart langfristig Zeit, Kosten und den Aufwand für aufwendige Sicherheitsprüfungen in späteren Entwicklungsphasen.
4. Automatisierte und geplante Scans durchführen
Beide Scan-Arten sind in unterschiedlichen Situationen nützlich. Automatisierte Scans liefern über den gesamten SDLC hinweg sofortiges Feedback zu Code-Problemen, während geplante Scans eine gründliche Momentaufnahme liefern, die sich gut eignet, um die Entwicklung des eigenen Code-Sicherheitsprogramms über die Zeit zu verfolgen.
5. Risiken zeitnah beheben
Eine Studie von Forbes zeigt, dass Sicherheitsteams mindestens 23 % der Cloud-Warnungen nicht untersuchen und ungelöst lassen. Ungelöste Risiken öffnen Systeme jedoch für Angriffe. Um kein leichtes Ziel zu sein, sollten Korrekturen und Software-Updates zeitnah erfolgen. Zudem verringern Werkzeuge, die Risiken priorisieren und alert fatigue reduzieren, den Bedarf, Ergebnisse manuell zu prüfen.
6. Werkzeugkonfiguration feinjustieren
Die Konfiguration lässt sich so optimieren, dass sie den eigenen Anforderungen dient. Dazu gehört:
den geschäftlichen Kontext einzubeziehen;
die Empfindlichkeitseinstellungen anzupassen;
bei Bedarf Ausnahmen, Zulassungslisten und Sperrlisten zu ergänzen;
Regeln und Signaturen zu definieren.
In Kombination mit mehreren Code-Scanning-Werkzeugen und -Techniken liefern diese Strategien umfassende und präzise Ergebnisse mit wenigen bis gar keinen False Positives.
7. Bewusstsein für sicheres Programmieren stärken
Bewusstsein entsteht durch Schulungen, klare Verantwortlichkeiten und die kontinuierliche Auseinandersetzung mit neuen Schwachstellen und Angriffsmethoden. Entwickler sollten verstehen, dass sicherer Code von Anfang an auch ihre eigene Arbeit erleichtert: Wer Sicherheitsprüfungen früh in den Entwicklungsprozess integriert, muss nach dem Release deutlich weniger Schwachstellen beheben.
Wiz für Code-Sicherheit
Die meisten Code-Scanner finden Schwachstellen, können aber nicht sagen, welche davon wichtig sind, eine Transparenzlücke, die miterklärt, warum nur 10 % der Unternehmen als führend bei der Cyber-Resilienz gelten. Wiz Code verknüpft die Scan-Ergebnisse mit dem Laufzeitkontext der Cloud und zeigt, ob ein verwundbarer Codepfad tatsächlich genutzt wird, aus dem Internet erreichbar ist und Zugriff auf sensible Daten hat.
Diese durchgängige Transparenz vom Quellcode bis zur Cloud verändert die Priorisierung von Sicherheitsrisiken in Entwicklungsteams. Statt Tausende Funde allein nach CVSS-Wert zu bewerten, wird sichtbar, welche Schwachstellen in der Produktion echte Angriffspfade eröffnen. Das Ergebnis: weniger Warnungen, schnellere Behebung und Sicherheit, die mit dem Entwicklungstempo Schritt hält.
Wiz Code scannt Anwendungscode, IaC-Templates, Container-Images und Secrets direkt in CI/CD-Pipelines. Die Funde fließen in denselben Security Graph ein, der die Cloud-Infrastruktur abbildet, und geben AppSec- und Cloud-Sicherheitsteams einen einheitlichen Blick auf das Risiko von der Quelle bis zur Produktion.
Eine Demo zeigt Wiz Code in Aktion und veranschaulicht, wie der durchgängige Kontext vom Quellcode bis zur Cloud eine präzisere Priorisierung von Risiken ermöglicht.