Der aktuelle Veracode State of Software Security basiert auf der Analyse von mehr als 1,6 Millionen Anwendungen und zeichnet ein klares Bild: Schwachstellen werden schneller angehäuft, als sie behoben werden. In einer Zeit beschleunigter Softwareentwicklung und zunehmender Nutzung künstlicher Intelligenz (KI) geraten klassische Sicherheitsprozesse sichtbar an ihre Grenzen.
Security Debt: Wenn bekannte Schwachstellen jahrelang bestehen bleiben
Im Zentrum des Berichts steht der Begriff Security Debt. Gemeint sind bekannte Schwachstellen, die länger als 12 Monate ungepatcht bleiben. Er ähnelt dem technischen Schuldprinzip, beschreibt aber explizit das aufgestaute Sicherheitsrisiko, das Organisationen bewusst oder aus Ressourcengründen in Kauf nehmen.
Laut Veracode weisen inzwischen 82 % der Organisationen einen solchen Sicherheitsrückstand auf (Vorjahr: 74 %). Gleichzeitig nimmt die Schwere der verbliebenen Schwachstellen zu: Der Anteil der Defekte mit hoher Ausnutzungswahrscheinlichkeit stieg von 8,3 % auf 11,3 %. Praktisch bedeutet dies, dass produktive Systeme vermehrt genau jene Lücken enthalten, die Angreifer mit vergleichsweise geringem Aufwand ausnutzen können.
Die Kennzahlen basieren auf einer Kombination aus Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Software Composition Analysis (SCA) sowie manuellen Penetrationstests. Dadurch werden nicht nur Fehler im eigenen Code sichtbar, sondern auch Risiken durch externe Bibliotheken, Frameworks und Komponenten in der gesamten Software-Supply-Chain.
Positive Signale: Weniger verwundbare Open-Source-Komponenten
Trotz des wachsenden Security Debt zeigt der Bericht auch Fortschritte. Die Quote der Anwendungen mit Schwachstellen in Open-Source-Komponenten sank von 70 % auf 62 %. Parallel verringert sich die generelle „Defektdurchdringung“ (Anteil der Anwendungen mit mindestens einer gefundenen Schwachstelle) von 80 % auf 78 %.
Diese Entwicklung deutet auf ein reiferes Schwachstellenmanagement in der Software-Lieferkette hin. Unternehmen aktualisieren Bibliotheken häufiger, setzen konsequenter auf Software Composition Analysis und verfolgen bekannte CVEs in Drittanbieter-Abhängigkeiten systematischer. Zudem trägt die zunehmende Verbreitung von DevSecOps-Praktiken dazu bei, dass Sicherheitsprüfungen direkt in CI/CD-Pipelines integriert werden und nicht erst nachgelagert stattfinden.
Mehr Funde durch bessere Tests – aber auch mehr Rauschen
Ein Teil des Anstiegs gemeldeter Schwachstellen lässt sich durch die breite Einführung automatisierter Sicherheitstools erklären. Anwendungen, Infrastruktur und Abhängigkeiten werden heute häufiger, tiefer und früher im Lebenszyklus gescannt. Dies deckt Schwachstellen auf, die in klassischen, rein manuellen Prüfprozessen oft unentdeckt geblieben wären.
Allerdings bleibt der tatsächliche Anteil an False Positives – also fälschlich gemeldeten Schwachstellen – unklar. In der Praxis führt dies zu einer Überlastung von Entwicklung und Security-Teams: Wertvolle Zeit fließt in die Bewertung und Triagierung von Funden, die sich nicht als sicherheitsrelevant herausstellen. Studien von Branchenorganisationen wie OWASP und Analysten wie Gartner betonen seit Jahren, dass ein ineffizienter Umgang mit False Positives die Akzeptanz von Sicherheitsscans im Entwicklungsalltag deutlich senkt.
KI, Release-Druck und steigende Komplexitaet
Release-Frequenz versus Remediation-Geschwindigkeit
Veracode identifiziert einen zentralen strukturellen Konflikt: Die Geschwindigkeit der Softwareentwicklung überholt die Geschwindigkeit der Schwachstellenbehebung. Häufige Releases, kontinuierliche Feature-Entwicklung und umfangreiche Codeänderungen führen dazu, dass sich ein stetig wachsender Backlog an offenen Findings bildet – insbesondere bei zunächst als „unkritisch“ eingestuften Schwachstellen.
Entsteht erst einmal ein signifikanter Security Debt, verschiebt sich der Fokus in vielen Organisationen von konsequenter Bereinigung hin zu rein reaktiver Brandbekämpfung. Damit erhöht sich das Risiko von Sicherheitsvorfällen, bei denen ältere, lange bekannte Schwachstellen als Einfallstor dienen – ein Muster, das auch in zahlreichen öffentlich gewordenen Sicherheitsvorfällen der vergangenen Jahre zu beobachten war.
Kuenstliche Intelligenz als Beschleuniger und Risikofaktor
Besonders hervorgehoben wird der rapide Anstieg von KI-generiertem Code. KI-gestützte Entwicklungswerkzeuge ermöglichen es, deutlich mehr Code in kürzerer Zeit zu schreiben. Gleichzeitig steigt die architektonische Komplexität von Anwendungen und Systemlandschaften, was die Analyse und sichere Gestaltung erschwert.
Fachkreise sind sich weitgehend einig, dass KI-Tools einer strikten Governance und „Human in the Loop“-Kontrolle bedürfen. Dennoch wird Sicherheitsbewertung in der Praxis häufig der Geschwindigkeit geopfert. KI-Systeme erzeugen zudem selbst Rauschen in Form uneindeutiger Empfehlungen und zusätzlicher Warnungen, was die ohnehin belasteten Review-Prozesse weiter beansprucht.
Strategische Konsequenzen: Von reaktiver zu risk-basierten Software-Sicherheit
Der Veracode-Bericht kommt zu einer klaren Einschätzung: Mit den heute verbreiteten Ansätzen ist umfassende Applikationssicherheit bei der aktuellen Entwicklungsgeschwindigkeit kaum erreichbar. Das entstandene Defizit in der Schwachstellenbehebung erreicht ein Niveau, das als strukturelle Krise beschrieben werden kann.
Statt punktueller Verbesserungen fordern die Daten einen strategischen Kurswechsel im Schwachstellenmanagement:
Erstens benötigen Unternehmen eine risk-basierte Priorisierung. Schwachstellen sollten nicht allein nach technischer Severity-Klassifikation (z. B. CVSS-Score) bewertet werden, sondern nach Kombination von Geschäftsimpact, Ausnutzbarkeit, Exposition und Kritikalität der betroffenen Systeme. Threat-Intelligence-Daten und Exploit-Trends können hier gezielt in die Priorisierung einfließen.
Zweitens muss Security by Design konsequent in den Secure Software Development Lifecycle integriert werden. Dazu gehören verpflichtende Security-Reviews für kritische Funktionen, der kombinierte Einsatz von SAST, DAST und SCA, klare SLAs für die Behebung von Schwachstellen sowie gezielte Schulungen im sicheren Programmieren für Entwicklungsteams.
Drittens sollten KI-Werkzeuge unter klaren Richtlinien betrieben werden: KI dient als Beschleuniger und Assistenz, nicht als autonome Entscheidungsinstanz. Sicherheitsrelevante Empfehlungen der KI bedürfen der Expert*innenvalidierung, Erkennungs-Schwellenwerte und Policies müssen regelmäßig anhand realer Incident-Daten nachjustiert werden.
Organisationen, die stark von komplexen Softwaresystemen abhängig sind, sollten den State of Software Security als Anlass nehmen, ihre Applikationssicherheitsstrategie grundlegend zu überprüfen. Mehr Tools und mehr Scans allein lösen das Problem des Security Debt nicht. Entscheidend ist ein Wandel in Prozessen, Kultur und Priorisierung. Wer frühzeitig systematisch gegen den eigenen Security Debt arbeitet, reduziert nicht nur die Wahrscheinlichkeit schwerer Sicherheitsvorfälle, sondern stärkt messbar die Resilienz und Vertrauenswürdigkeit der eigenen digitalen Angebote.
