Schwachstellenmanagement für Softwareprodukte: Erkennen, bewerten und reagieren innerhalb von 24 Stunden

Das Wichtigste in Kürze Eine kritische Schwachstelle war für viele Softwarehersteller lange ein technisches Problem mit dehnbarer Frist. Das ändert sich gerade grundlegend. Seit dem 11. September 2026 müssen Hersteller, die Produkte mit digitalen Elementen in der EU vertreiben, aktiv ausgenutzte Schwachstellen innerhalb von 24 Stunden mit einer Frühwarnung melden. Konzernkunden schreiben vergleichbare Anforderungen zunehmend in ihre Verträge, und Angreifer nutzen veröffentlichte Lücken heute oft schon nach wenigen Tagen aus. Ein 24-Stunden-Fenster einzuhalten, ist keine Frage von Überstunden im Ernstfall. Entscheidend ist, was vorher steht: ein vollständiges Verzeichnis aller Komponenten im Produkt, eine Erkennung, die echte Bedrohungen vom Rauschen trennt, klare Zuständigkeiten, eine Pipeline, die Korrekturen sicher ausliefert, und Ansprechpartner, die im richtigen Moment erreichbar sind. Dieser Beitrag beschreibt die fünf Bausteine eines Schwachstellenmanagements, das auch unter Zeitdruck funktioniert, die Kennzahlen, an denen sich die Reife ablesen lässt, und die Frage, wann sich ein Managed Service lohnt.

Warum 24 Stunden zum Maßstab geworden sind

Drei Entwicklungen haben die Reaktionszeit zu einem geschäftlichen Thema gemacht.

Regulierung. Seit dem 11. September 2026 verpflichtet der Cyber Resilience Act (CRA) der EU Hersteller von Produkten mit digitalen Elementen, aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle zu melden, beginnend mit einer Frühwarnung innerhalb von 24 Stunden. Die Pflicht gilt auch für Produkte, die bereits auf dem EU-Markt sind, und für Hersteller außerhalb der EU, etwa aus der Schweiz, die in die EU liefern. Die rechtliche Einordnung überlassen wir bewusst der Rechtsberatung; hier geht es um die operative Konsequenz. Was ein Unternehmen nicht innerhalb von 24 Stunden erkennen, verstehen und bewerten kann, kann es auch nicht innerhalb von 24 Stunden melden.

Erwartungen der Kunden. Banken, Versicherungen, Industrieunternehmen und die öffentliche Hand unterliegen selbst Regelwerken wie NIS2 oder DORA und reichen Sicherheitsanforderungen an ihre Lieferanten weiter. Fragen nach dem Umgang mit Schwachstellen, nach Reaktionszeiten und nach einer Software-Stückliste gehören inzwischen zum Standard jedes Sicherheitsfragebogens.

Das Tempo der Angreifer. Die Zeit zwischen der Veröffentlichung einer Schwachstelle und ihrer aktiven Ausnutzung wird immer kürzer. Ein Prozess, der auf monatliche Patchzyklen ausgelegt ist, lässt Angreifern ein Zeitfenster, das sie zu nutzen wissen.

Warum die meisten Softwarehersteller noch nicht so weit sind

In unseren Projekten mit Softwareherstellern begegnen uns immer wieder dieselben Lücken. Keine davon ist ungewöhnlich, und die meisten bleiben unsichtbar, bis der erste ernsthafte Vorfall eintritt.

• Kein verlässliches Verzeichnis. Das Team kennt seinen eigenen Code, aber nicht jede Open-Source-Bibliothek, jedes Container-Basis-Image und jedes Drittanbieter-SDK in jeder unterstützten Produktversion.
• Zu viel Rauschen. Scanner melden Hunderte von Befunden. Ohne Priorisierung geht die eine aktiv ausgenutzte Schwachstelle zwischen den rein theoretischen unter.
• Unklare Zuständigkeiten. Taucht am Freitagabend ein kritisches Problem auf, weiß niemand genau, wer es bewertet, wer über die Reaktion entscheidet und wer die Kunden informiert.
• Langsamer Weg in die Produktion. Die Pipeline ist auf geplante Releases ausgelegt. Eine dringende Korrektur auszuliefern heißt, Schritte zu überspringen, und damit neue Risiken einzugehen.
• Viele Versionen im Feld. Kunden betreiben ältere Releases, On-Premise-Installationen oder Embedded-Versionen in Maschinen und Anlagen, die sich nicht einfach mit dem nächsten Deployment aktualisieren lassen.

Jede dieser Lücken kostet im Ernstfall Stunden oder Tage. Sie zu schließen, ist die eigentliche Arbeit im Schwachstellenmanagement.

Die fünf Bausteine einer schnellen Reaktion

1. Wissen, was im Produkt steckt

Jede Reaktion beginnt mit derselben Frage: Sind wir betroffen? Um sie in Minuten statt in Tagen zu beantworten, braucht es für jedes Release und jede noch unterstützte Version eine Software-Stückliste (SBOM). Sie verzeichnet alle direkten und transitiven Abhängigkeiten samt Versionsständen und sollte automatisch in der CI/CD-Pipeline entstehen, nicht in mühsamer Handarbeit.

Die SBOM hilft allerdings nur, wenn sie aktuell ist und sich schnell durchsuchen lässt. Wird eine neue Schwachstelle bekannt, sollte das Team binnen Minuten sehen, welche Produkte, Versionen und Kunden betroffen sind.

2. Erkennen, was wirklich zählt

Die Erkennung speist sich aus mehreren Quellen:

• Software Composition Analysis, um bekannte Schwachstellen in Abhängigkeiten zu finden,
• statische Codeanalyse für den eigenen Code,
• Scans von Containern und Infrastruktur, also Basis-Images, Konfigurationen und Cloud-Ressourcen,
• externe Bedrohungsinformationen, etwa der Katalog aktiv ausgenutzter Schwachstellen der US-Behörde CISA oder der EPSS-Wert, der die Wahrscheinlichkeit einer Ausnutzung schätzt.

Entscheidend ist die Priorisierung. Eine aktiv ausgenutzte Schwachstelle, die im eigenen Produkt erreichbar ist, ist weitaus dringlicher als eine höher bewertete Lücke in Code, der nie ausgeführt wird. Wer nach Ausnutzung und Angriffsfläche priorisiert statt allein nach dem Schweregrad, setzt seine Zeit dort ein, wo sie zählt.

3. Schnell bewerten und entscheiden

Ist eine relevante Schwachstelle erkannt, läuft die Uhr. Eine zügige Bewertung beantwortet vier Fragen: Wird der betroffene Code tatsächlich genutzt? Ist er von außen erreichbar? Wie groß ist der mögliche Schaden? Welche Kunden sind betroffen?

Das Tempo hängt dabei weniger vom technischen Können ab als von klar geregelten Rollen. Wer bestätigt den Befund? Wer entscheidet, ob er kritisch ist? Wer bindet Rechtsabteilung und Compliance ein, wenn eine Meldepflicht bestehen könnte? Wer kommuniziert mit den Kunden? Diese Entscheidungen gehören in ein Playbook und sollten geübt werden, bevor es ernst wird.

4. Sicher beheben und ausliefern

Eine Korrektur, die zwei Wochen bis zur Auslieferung braucht, hilft wenig. Der Weg für Sicherheitsupdates sollte genauso automatisiert und genauso sicher sein wie der reguläre: automatisierte Tests für geschäftskritische Abläufe, die Möglichkeit, einen Patch unabhängig von der Feature-Roadmap auszuliefern, und definierte Abläufe, um Korrekturen in ältere, noch unterstützte Versionen zurückzuportieren.

Möglich wird das durch ausgereifte Praktiken in den Bereichen DevOps, Cloud-Sicherheit und Managed Services: Infrastructure as Code, reproduzierbare Builds, kontrollierte Deployment-Strategien und ein Secrets Management, das nicht an einzelnen Personen hängt.

5. Kommunizieren und daraus lernen

Kunden brauchen klare und rechtzeitige Informationen: Was ist betroffen, was sollen sie tun, wann kommt die Korrektur? Intern sollte jeder bedeutende Vorfall mit einer Nachbetrachtung ohne Schuldzuweisung enden, die zeigt, was die Reaktion verzögert hat und was sich ändern muss. So wird aus jedem einzelnen Vorfall nach und nach ein besserer Prozess.

So sehen die ersten 24 Stunden aus

Die genauen Schritte hängen vom Produkt und von der Organisation ab. Für eine aktiv ausgenutzte Schwachstelle sieht ein praxistauglicher Ablauf etwa so aus:

In den ersten 24 Stunden geht es vor allem ums Wissen und Entscheiden, nicht ums Beheben. Deshalb entscheidet die Vorbereitung darüber, ob sich das Zeitfenster einhalten lässt.

Woran Sie erkennen, ob Ihr Unternehmen vorbereitet ist

Einige Kennzahlen zeigen, ob der Prozess in der Praxis trägt und nicht nur auf dem Papier existiert:

• SBOM-Abdeckung: der Anteil der Produkte und unterstützten Versionen mit aktueller, automatisch erzeugter Stückliste.
• Zeit bis zur Bewertung: wie lange es von der Erkennung bis zu einer bestätigten Einschätzung dauert.
• Behebungsdauer nach Schweregrad: wie lange kritische, hohe und mittlere Schwachstellen offen bleiben.
• Durchlaufzeit für Patches: wie schnell sich eine fertige Sicherheitskorrektur ausliefern lässt.
• Abdeckung der unterstützten Versionen: der Anteil der unterstützten Releases, die Korrekturen innerhalb der Zielzeit erhalten.

Ein simulierter Vorfall, etwa mit einer kürzlich veröffentlichten Schwachstelle in einer verbreiteten Bibliothek, zeigt schnell, an welcher Stelle der Prozess hakt.

Selbst machen, Managed Service oder beides?

Eine schnelle Reaktion setzt voraus, dass auch außerhalb der Bürozeiten jemand erreichbar ist. Eine verlässliche Rufbereitschaft rund um die Uhr braucht in der Regel mindestens fünf Personen, um auf Dauer tragfähig zu sein. In Deutschland und Österreich kommen die Vorgaben zu Arbeits- und Ruhezeiten hinzu, die bei Einsätzen in der Nacht schnell die Dienstplanung bestimmen. Für ein mittelständisches Softwareunternehmen ist das eine erhebliche Investition, zumal ernsthafte Vorfälle selten sind.

Für viele Unternehmen ist ein kombiniertes Modell die beste Lösung. Das Produktteam bleibt verantwortlich für den Code und die Korrekturen, während ein externer Partner kontinuierliches Monitoring, Alarmierung und Eskalation, eine Rufbereitschaft, Incident Management mit Nachbetrachtungen sowie die automatisierte Sammlung von Compliance-Nachweisen übernimmt. Es geht nicht darum, Verantwortung abzugeben, sondern sicherzustellen, dass immer jemand Kompetentes hinschaut.

Auch KI kann einzelne Schritte deutlich verkürzen: Sicherheitshinweise zusammenfassen, prüfen, ob verwundbare Funktionen überhaupt aufgerufen werden, Versionsupdates für Abhängigkeiten vorschlagen und Tests für die Korrektur erzeugen. In einem kontrollierten Ablauf, wie wir ihn auf unserer Seite zur KI-gestützten Softwareentwicklung beschreiben, spart das bei Bewertung und Behebung viele Stunden Handarbeit. Liegt das Hauptproblem in veralteten Abhängigkeiten in Legacy-Code, die sich ohne größeren Umbau nicht aktualisieren lassen, zeigt ein AI Refactoring Assessment einen realistischen Weg zur Modernisierung auf.

Warum Investoren genau hinschauen

Der Umgang mit Schwachstellen fließt zunehmend auch in die Unternehmensbewertung ein. In einer technischen Due Diligence fragen Käufer immer häufiger nach SBOMs, Behebungszeiten und Nachweisen für eine funktionierende Incident Response. Ein Unternehmen, das einen gelebten Prozess vorweisen kann, ist für Käufer ein geringeres Risiko; fehlt dieser Nachweis, drohen Kaufpreisabschläge oder spezifische Freistellungen.

Reaktionsgeschwindigkeit ist Teil der Produktqualität

Kunden bewerten Software längst nicht mehr nur nach ihren Funktionen. Sie achten auch darauf, wie schnell und transparent der Hersteller reagiert, wenn etwas schiefgeht. Die Fähigkeit, innerhalb eines Tages zu erkennen, zu bewerten und zu handeln, ist zu einem Qualitätsmerkmal des Produkts selbst geworden.

Dafür braucht es keine große Sicherheitsabteilung. Es braucht ein genaues Verzeichnis, eine fokussierte Erkennung, klare Entscheidungswege, einen sicheren Auslieferungsweg und Menschen, die im entscheidenden Moment erreichbar sind. Wenn Sie wissen möchten, wie gut Ihr Produkt vorbereitet ist, oder ein Monitoring mit Reaktion rund um die Uhr aufbauen wollen, erfahren Sie auf unserer Seite zu DevOps, Cloud-Sicherheit und Managed Services, wie wir Sie dabei unterstützen.

Dieser Beitrag beschreibt operative Praktiken und stellt keine Rechtsberatung dar. Ob und in welchem Umfang der Cyber Resilience Act auf ein bestimmtes Produkt anwendbar ist, sollte mit einer qualifizierten Rechtsberatung geklärt werden.