Schwachstellen Management Übersicht##

Schwachstellen Management ist der kontinuierliche, systematische Prozess der Identifizierung, Bewertung, Priorisierung, Behebung und Dokumentation von Sicherheitsschwachstellen in Softwaresystemen. In der modernen Softwareentwicklung ist es keine optionale Sicherheitsmaßnahme mehr — es ist eine Ingenieurdisziplin, eine regulatorische Anforderung und Voraussetzung für den Vertrieb von Software an Unternehmens- und EU-Kunden.

Diese Seite erklärt, warum Schwachstellen Management in der Softwareentwicklung unverzichtbar ist, wie es die Softwarekonformität mit Rahmenwerken wie dem EU Cyber Resilience Act (CRA), NIS2, DORA und ISO 27001 untermauert, und wie DevGuard einen risikobasierten Ansatz umsetzt, der sich in moderne DevSecOps-Pipelines integriert.

Warum Schwachstellen Management in der Softwareentwicklung wichtig ist##

Software ist zur Grundlage jeder Branche geworden — und Angreifer haben das erkannt. Die Bedrohungslandschaft hat sich von seltenen, schlagzeilenträchtigen Vorfällen zu einer konstanten, hochvolumigen Realität gewandelt, mit der jedes Entwicklungsteam umgehen muss.

Das Volumen der Schwachstellen explodiert. Im Jahr 2017 wurden weniger als 1.000 neue CVEs pro Monat veröffentlicht. Bis 2023 hatte sich dieser Monatsdurchschnitt auf rund 2.000 verdoppelt, und 2025 schloss mit über 4.000 neu gemeldeten CVEs pro Monat — etwa 131 täglich. Der Anteil als „kritisch" eingestufter Schwachstellen ist überproportional gestiegen und setzt Teams unter Druck, mehr und schneller zu beheben.

Ausnutzung erfolgt schneller denn je. Nahezu 29 % der im Jahr 2025 in den CISA-Katalog bekannter ausgenutzter Schwachstellen (KEV) aufgenommenen Lücken wurden am oder vor dem Tag ihrer CVE-Veröffentlichung ausgenutzt. Laut Verizon DBIR 2025 entfallen auf die Ausnutzung von Schwachstellen rund 20 % aller Sicherheitsvorfälle — ein Anstieg von 34 % gegenüber dem Vorjahr und eine Rate von 70 % bei spionagemotivierten Angriffen.

Die finanziellen Auswirkungen sind konkret. Allein in Deutschland verursachten Cyberangriffe im Jahr 2023 Schäden von rund 206 Milliarden Euro, ein erheblicher Teil davon auf ausgenutzte Softwareschwachstellen zurückzuführen. Weltweit erreichte der Markt für Sicherheits- und Schwachstellenmanagement 2025 ein Volumen von 17,63 Milliarden US-Dollar — ein direkter Beleg dafür, wie viel Organisationen allein aufwenden, um Schritt zu halten.

Kurz gesagt: Software wird mit Schwachstellen ausgeliefert, Angreifer finden und nutzen sie schneller als je zuvor, und diese Realität zu ignorieren ist für einen Hersteller, der Produkte auf dem Markt platziert, keine tragbare Position mehr.

Die versteckten Kosten des Nichtstuns##

• Datenpannengefährdung: 92 % der im Checkmarx Global Pulse on AppSec 2024 befragten Organisationen erlebten im Vorjahr einen Einbruch, der auf Schwachstellen in intern entwickelter Software zurückzuführen war.
• Bekanntes Risiko: 81 % der Organisationen geben zu, wissentlich Code mit bekannten Schwachstellen ausgeliefert zu haben — meist, weil kein strukturierter Prozess zur rechtzeitigen Triage und Behebung besteht.
• Alert-Fatigue: Traditionelle Scanner erzeugen 50–80 % False Positives, die reale Risiken verschleiern und Entwicklungsteams erschöpfen.
• Wiederholte Sicherheitsvorfälle: Organisationen mit mangelhaftem Schwachstellen Management sind rund doppelt so häufig von einem erneuten Einbruch innerhalb desselben Jahres betroffen.

Schwachstellen Management und Softwarekonformität##

Softwarekonformität ist zur zweiten treibenden Kraft hinter dem Schwachstellen Management geworden. Eine wachsende Zahl von Vorschriften macht den Umgang mit Schwachstellen zur gesetzlichen Pflicht — und die Konsequenzen der Nichteinhaltung sind direkt: verlorener Marktzugang, blockierte Verträge und Bußgelder, die sich am globalen Umsatz orientieren.

Wichtige Compliance-Rahmenwerke mit Anforderungen an das Schwachstellen Management##

Der EU Cyber Resilience Act im Fokus##

Der CRA ist die folgenreichste europäische Cybersicherheitsgesetzgebung für Software, die je verabschiedet wurde. Ab dem 11. Dezember 2027 muss jeder Hersteller, der Produkte mit digitalen Elementen auf dem EU-Markt platziert, die Einhaltung von Anhang I nachweisen — oder verliert das Recht, in der EU zu verkaufen. Die Sanktionen erreichen bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Meldepflichten für aktiv ausgenutzte Schwachstellen beginnen früher, am 11. September 2026.

Der CRA schreibt unter anderem vor:

• Security by Design und by Default: Produkte müssen mit eingebetteter Cybersicherheit entworfen werden, nicht nachträglich.
• Prozess zur Schwachstellenbehandlung: kontinuierliche Identifizierung, Dokumentation und Behebung von Schwachstellen — auch in Drittanbieterkomponenten.
• Software Bill of Materials (SBOM): maschinenlesbare Inventare (CycloneDX, SPDX) für jede Produktversion.
• Sicherheitsupdates: kostenfrei bereitgestellt, mit klarer Kommunikation an Nutzer über sicherheitsrelevante Implikationen.
• Konformitätsbewertung und technische Dokumentation: jeder Scan, jede Triage-Entscheidung, jede durchgesetzte Richtlinie muss für Prüfer abrufbar sein.

Diese Verpflichtungen sind keine Wunschziele. Sie sind die neue Mindestanforderung für den Softwarevertrieb in Europa — und sie entsprechen direkt der täglichen Arbeit eines Schwachstellen-Management-Programms. Eine vollständige Übersicht finden Sie auf der CRA-Compliance-Seite.

Warum Softwarekonformität ohne Schwachstellen Management unmöglich ist##

Jedes moderne Softwarekonformitäts-Rahmenwerk — CRA, NIS2, DORA, ISO 27001, SOC 2, PCI-DSS — läuft auf dieselbe operative Anforderung hinaus: einen dokumentierten, auditierbaren Prozess zur Identifizierung, Priorisierung und Behebung von Schwachstellen über die gesamte Software-Lieferkette hinweg.

Ohne kontinuierliches Schwachstellenscanning, SBOM-Generierung und Triage-Dokumentation können Sie nicht:

• Einem Prüfer nachweisen, was in Ihrer Software steckt.
• Belegen, dass neu gemeldete CVEs gegen Ihre früheren Releases erneut bewertet wurden.
• Zeigen, dass Risikoentscheidungen bewusst, von namentlich genannten Personen und auf dokumentierter Grundlage getroffen wurden.
• Die CRA-Anforderung erfüllen, aktiv ausgenutzte Schwachstellen im Zeitrahmen der Behörde zu melden.

Schwachstellen Management ist die Schicht, die die Beweise produziert, die jedes Softwarekonformitäts-Rahmenwerk verlangt. Wird es übersprungen, wird Compliance zur Papierbeschäftigung, die einer ernsthaften Prüfung nicht standhält.

Von reaktivem Patchen zu risikobasierter Priorisierung##

Ein naiver Ansatz — „alle kritischen CVEs patchen" — skaliert nicht, wenn täglich 131 neue CVEs veröffentlicht werden. Die Entwicklungskapazität ist begrenzt. Die richtige Frage ist nicht ob Schwachstellen zu managen sind, sondern welche zuerst zu beheben sind, angesichts begrenzter Zeit und konkurrierender Produktprioritäten.

Effektives Schwachstellen Management kombiniert mehrere Signale, um das reale Risiko zu ermitteln, anstatt sich auf einen einzelnen Schweregrad-Score zu verlassen:

• CVSS (Common Vulnerability Scoring System): standardisierter technischer Schweregrad, ausgedrückt als Basis-Score.
• EPSS (Exploit Prediction Scoring System): Wahrscheinlichkeit, dass eine Schwachstelle innerhalb der nächsten 30 Tage in der Praxis ausgenutzt wird.
• Exploit-Verfügbarkeit: Vorhandensein in öffentlichen Datenbanken wie ExploitDB, Metasploit-Modulen oder dem CISA KEV-Katalog.
• Erreichbarkeit und Ausnutzbarkeit im Anwendungskontext: Wird der verwundbare Codepfad tatsächlich aufgerufen? Gibt es mildernde Kontrollen?
• Organisatorische Sicherheitsanforderungen: Anforderungen an Vertraulichkeit, Integrität und Verfügbarkeit des betroffenen Assets.

Wenn diese Signale kombiniert werden, ordnet sich ein erheblicher Anteil von Schwachstellen mit hohen CVSS-Scores auf ein niedrigeres reales Risiko ein — und eine kleine Zahl von „mittleren" CVSS-Schwachstellen entpuppt sich als die, die tatsächlich ausgenutzt werden. Ohne diese Neubewertung investieren Teams den Großteil ihrer Kapazität in die falschen Befunde, während Angreifer die ignorierten ausnutzen.

Für eine vertiefte Analyse, wie risikobasierte Priorisierung die Ergebnisse verändert — einschließlich eines Sankey-Diagramms, das zeigt, wie CVSS-Scores sich nach Einbeziehung von EPSS und Exploit-Daten neu ordnen — siehe die L3montree-Analyse Effektive Priorisierung von Schwachstellen.

Der Schwachstellen-Management-Lebenszyklus##

Ein reifes Schwachstellen-Management-Programm ist ein kontinuierlicher Lebenszyklus, kein einmaliges Audit. Jede Phase erzeugt Artefakte, auf die sowohl das Entwicklungsteam als auch externe Prüfer angewiesen sind.

1. Entdeckung: kontinuierliches Scanning über Quellcode (SAST), Abhängigkeiten (SCA), Container, Infrastructure-as-Code, Secrets und Laufzeitumgebung. SBOMs werden für jeden Build generiert.
2. Abgleich: Gefundene Komponenten und Code-Befunde werden mit Schwachstellendatenbanken abgeglichen (NVD, OSV, GitHub Advisory Database, Herstellerhinweise).
3. Risikobewertung: Jeder Befund wird mit CVSS + EPSS + Exploit-Verfügbarkeit + organisatorischem Kontext bewertet.
4. Triage: Befunde werden zugewiesen, akzeptiert, mitigiert oder als False Positive markiert. Jede Entscheidung wird mit Wer, Wann und Warum erfasst — das ist die Spur, nach der Prüfer suchen.
5. Behebung: Patches, Dependency-Upgrades, Konfigurationsänderungen oder kompensierende Maßnahmen werden angewendet. Issue-Tracker (GitHub Issues, GitLab Issues, Jira) halten die Sicherheitsarbeit im normalen Entwicklungsworkflow sichtbar.
6. Verifizierung: Re-Scans bestätigen die Behebung; Attestierungen werden erstellt, wo erforderlich.
7. Reporting und Offenlegung: Der Status wird intern geteilt und, wo anwendbar, extern über VEX-Dokumente (Vulnerability Exploitability eXchange) und koordinierte Schwachstellenoffenlegungskanäle.

Jeder Schritt erzeugt Artefakte — Scan-Protokolle, SBOMs, VEX-Dokumente, Triage-Entscheidungen, signierte Attestierungen —, die zusammen den Prüfpfad bilden, der von CRA, NIS2 und ISO 27001 gefordert wird.

Wie DevGuard Schwachstellen Management umsetzt##

DevGuard implementiert den oben beschriebenen Lebenszyklus als eine einzige Open-Source-Plattform, die in den Entwicklerworkflow integriert ist, anstatt daneben zu laufen.

• Kontinuierliches Scanning über den gesamten Stack: SCA, SAST, Container-Scanning, IaC-Scanning, Secret-Erkennung und DAST, integriert in bestehende CI/CD-Pipelines (GitHub Actions, GitLab CI, Jenkins).
• Risikobasierte Priorisierung: CVSS wird mit EPSS, Exploit-Verfügbarkeit, Komponententiefe und organisatorischen Sicherheitsanforderungen angereichert — sodass die Spitze der Warteschlange das tatsächliche Exploit-Risiko widerspiegelt, nicht nur den nominellen Schweregrad.
• Automatisiertes SBOM und VEX: CycloneDX SBOMs und Live-VEX-Endpunkte werden pro Release generiert und kontinuierlich gegen neu gemeldete CVEs abgeglichen — einschließlich rückwirkender Abgleiche mit früheren Releases.
• Auditierfähige Triage: Jede Triage-Entscheidung wird mit Zeitstempel, Begründung und verantwortlicher Person erfasst. Dies erfüllt die „Nachweispflicht" gemäß CRA Anhang I, NIS2 Artikel 21 und ISO-27001-Maßnahmen.
• Signierte Attestierungen: In-toto-Attestierungen und Sigstore-Signierung erzeugen manipulationssichere Aufzeichnungen des Sicherheitsprozesses — direkt verwendbar als Konformitätsbewertungsnachweise.
• Bring Your Own Scanner: SBOM- und SARIF-Ingestion ermöglicht es Teams, vorhandenes Tooling (Trivy, Grype, Semgrep und andere) beizubehalten und Befunde an einem Ort zu konsolidieren.

Das Ergebnis: Schwachstellen Management — und die Nachweise, die für die Softwarekonformität benötigt werden — wird zum natürlichen Nebenprodukt des Entwicklungsprozesses, nicht zu einem separaten Programm, das um Entwicklungskapazität konkurriert.

Weiterführende Dokumentation##

• Schwachstellen-Lebenszyklus — detaillierter Überblick über jede Lebenszyklusphase
• Risikobewertungsmethodik — wie DevGuard CVSS, EPSS und Kontext kombiniert
• Schwachstellen-Abgleich — wie Befunde CVEs zugeordnet werden
• Mitigationsstrategien — Patching, Dependency-Upgrades, VEX und kompensierende Maßnahmen
• False Positives — Umgang mit Rauschen ohne echte Risiken zu verlieren
• DevGuard & Compliance-Rahmenwerke — Mapping von Schwachstellen Management zu CRA, NIS2, ISO 27001
• CRA-Konformität mit DevGuard — wie DevGuard die Anforderungen des Cyber Resilience Act abbildet
• Was ist DevGuard? — Plattformübersicht

Häufig gestellte Fragen##

Was ist Schwachstellen Management in der Softwareentwicklung?#

Schwachstellen Management in der Softwareentwicklung ist der kontinuierliche Prozess der Identifizierung, Priorisierung, Behebung und Dokumentation von Sicherheitsschwachstellen in Quellcode, Abhängigkeiten, Containern und Infrastruktur. Es ist inzwischen sowohl eine Ingenieurdisziplin als auch eine Compliance-Anforderung gemäß Vorschriften wie dem EU Cyber Resilience Act, NIS2 und DORA.

Warum ist Schwachstellen Management für die Softwarekonformität wichtig?#

Schwachstellen Management ist die operative Schicht, die die von Softwarekonformitäts-Rahmenwerken geforderten Nachweise erzeugt. CRA, NIS2, DORA und ISO 27001 fordern alle eine dokumentierte Identifizierung, Bewertung und Behebung von Schwachstellen — auch in Drittanbieterkomponenten — sowie SBOMs und einen auditierbaren Nachweis. Ohne kontinuierliches Schwachstellen Management ist der Nachweis der Konformität in einer ernsthaften Prüfung praktisch unmöglich.

Wie wirkt sich der EU Cyber Resilience Act auf das Schwachstellen Management aus?#

Der CRA macht die Behandlung von Schwachstellen zur gesetzlichen Pflicht für jeden Hersteller, der Produkte mit digitalen Elementen auf dem EU-Markt platziert. Ab dem 11. Dezember 2027 müssen Hersteller einen Schwachstellenbehandlungsprozess dokumentieren, SBOMs generieren, zeitnahe Sicherheitsupdates bereitstellen und aktiv ausgenutzte Schwachstellen melden. Meldepflichten beginnen früher, am 11. September 2026. Bei Nichteinhaltung drohen Bußgelder von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes.

Wie sollten Softwareschwachstellen priorisiert werden?#

Schwachstellen sollten nach realem Risiko priorisiert werden, nicht allein nach dem CVSS-Schweregrad. Kombinieren Sie den CVSS-Basis-Score mit EPSS (Exploit-Wahrscheinlichkeit), Exploit-Verfügbarkeit (CISA KEV, ExploitDB), Erreichbarkeit in Ihrer Anwendung und den organisatorischen Sicherheitsanforderungen des betroffenen Assets. Dadurch wird ein erheblicher Anteil der „kritischen" CVSS-Befunde auf ein niedrigeres reales Risiko eingestuft — sodass Teams ihre Kapazität auf das konzentrieren können, was Angreifer tatsächlich ausnutzen werden.

Was ist der Unterschied zwischen Schwachstellen Management und Schwachstellen-Scanning?#

Schwachstellen-Scanning ist ein einzelner Schritt — die Erkennung. Schwachstellen Management ist der vollständige Lebenszyklus: Entdeckung, Abgleich, Risikobewertung, Triage, Behebung, Verifizierung, Reporting und Dokumentation. Scanning erzeugt Befunde; Schwachstellen Management wandelt Befunde in Entscheidungen, Korrekturen und den für die Softwarekonformität erforderlichen Prüfpfad um.

Fällt Open-Source-Software unter die CRA-Anforderungen für das Schwachstellen Management?#

Ja — Hersteller, die Open-Source-Komponenten integrieren, sind zur Sorgfaltspflicht verpflichtet und müssen Schwachstellen in diesen Komponenten als Teil ihres Produkts behandeln und melden. Dedizierte „Open-Source-Software-Stewards" haben eigene, leichtere Pflichten zur Politik und Zusammenarbeit gemäß dem CRA. In jedem Fall sind ein SBOM und ein dokumentierter Schwachstellenbehandlungsprozess unvermeidlich.