Der Lebenszyklus des Schwachstellenmanagements für Softwarehersteller

Was ist der Lebenszyklus des Schwachstellenmanagements?

Der Lebenszyklus des Schwachstellenmanagements ist der wiederholbare Prozess, mit dem ein Produkthersteller eine Schwachstelle in seiner ausgelieferten Software behandelt: sie empfangen oder finden, verifizieren, ermitteln, was betroffen ist, beheben, den Fix veröffentlichen und die Kunden informieren. Beim Hersteller betreibt ihn meist ein Product Security Incident Response Team (PSIRT), während Entwicklungsteams die Fixes umsetzen.

Diese Seite behandelt die Herstellerseite. IT-Schwachstellenmanagement, also das Scannen und Patchen der Server und Laptops, die eine Organisation betreibt, teilt das Vokabular, aber nicht die schwierigen Teile. Ein Hersteller muss für jedes unterstützte Release in den Händen seiner Kunden einstehen und veröffentlichen, was er gefunden hat.

Die Stufen des Lebenszyklus

1. Empfangen oder entdecken. Schwachstellen kommen von externen Forschenden über Ihr Offenlegungsprogramm, von Kunden, von Koordinatoren wie nationalen CSIRTs und aus Ihrer eigenen Überwachung: eine neue CVE in einer Open-Source-Abhängigkeit, ein Scanner-Befund oder ein interner Test. Erfassen Sie jede mit einer Tracking-ID und bestätigen Sie externen Meldenden den Eingang.
2. Verifizieren und triagieren. Reproduzieren Sie das Problem oder bestätigen Sie den Abhängigkeitstreffer, entscheiden Sie, ob es eine Schwachstelle in Ihrem Produkt ist, und bewerten Sie, wie schwerwiegend und wie dringend sie ist. Schließen Sie, was nicht zutrifft, mit einer Begründung, die Sie später vorlegen können. Priorisierungssignale wie EPSS und der CISA-KEV-Katalog helfen, den Rest zu ordnen.
3. Betroffene Produkte und Versionen ermitteln. Finden Sie jedes Produkt, Release und jeden unterstützten Branch, der den verwundbaren Code oder die Komponente enthält, und jede Kundeninstallation, die eines davon betreibt. Dieser Schritt bestimmt den Umfang des Fixes und des Advisorys.
4. Beheben. Das zuständige Team entwickelt und testet einen Fix: eine aktualisierte Abhängigkeit, eine Codeänderung oder eine Abhilfemaßnahme wie eine Konfigurationsänderung, wenn ein Fix noch nicht möglich ist.
5. Den Fix veröffentlichen. Liefern Sie aktualisierte Versionen für jeden betroffenen unterstützten Branch aus, über einen Kanal, dem Kunden vertrauen können.
6. Informieren und offenlegen. Veröffentlichen Sie ein Advisory, das sagt, was betroffen ist, wie schwerwiegend es ist und was zu tun ist, vergeben oder referenzieren Sie eine CVE-ID und nennen Sie den Meldenden. Maschinenlesbare Formate wie CSAF und VEX lassen Kunden Advisories automatisch verarbeiten.
7. Überwachen und lernen. Achten Sie auf Ausnutzung und neue Informationen, aktualisieren Sie das Advisory und geben Sie die Grundursache an die Entwicklung zurück, damit dieselbe Fehlerklasse nicht erneut ausgeliefert wird.

ISO/IEC 30111 und ISO/IEC 29147

Zwei internationale Standards beschreiben diesen Lebenszyklus für Hersteller. Sie teilen ihn an der Grenze der Organisation:

	ISO/IEC 30111:2019	ISO/IEC 29147:2018
Titel	Vulnerability handling processes	Vulnerability disclosure
Deckt ab	Was intern geschieht: Verifizieren, Untersuchen, Priorisieren und Beheben	Die Schnittstellen: Meldungen empfangen und Advisories veröffentlichen
Wichtige Inhalte	Policy und Organisation, Aufgaben des PSIRT, Behandlungsphasen, Aspekte der Lieferkette	Rollen der Beteiligten, Umgang mit Meldungen, Inhalte von Advisories, Koordination, Offenlegungsrichtlinie
Zielgruppe	Hersteller, die gemeldete Schwachstellen behandeln	Hersteller, die Meldungen empfangen und Schwachstellen offenlegen

Die Standards sind für die gemeinsame Nutzung gedacht. ISO/IEC 30111 nennt sechs Behandlungsphasen: Vorbereitung, Eingang, Verifizierung, Entwicklung der Behebung, Release und Nach-Release. Der Standard verlangt außerdem Prozessüberwachung, Vertraulichkeit von Schwachstelleninformationen und Aufmerksamkeit für die Lieferkette, da viele Schwachstellen in Komponenten stecken, die Sie nicht geschrieben haben. Beide Standards sind aktuelle Ausgaben, bei ihrer letzten ISO-Überprüfung bestätigt, und zur Überarbeitung vorgemerkt.

Andere Frameworks folgen demselben Muster. Das FIRST PSIRT Services Framework gliedert die Arbeit in Schwachstellenentdeckung, Triage und Analyse, Behebung und Offenlegung, und IEC 62443-4-1 nimmt Sicherheitsupdates und Fehlermanagement in seinen sicheren Entwicklungslebenszyklus für Industrieprodukte auf.

Rollen

• PSIRT oder Produktsicherheitsteam: verantwortet den Prozess, empfängt Meldungen, triagiert, koordiniert Fixes und veröffentlicht Advisories. Siehe CRACI für PSIRT-Teams und wie sich ein PSIRT von einem CSIRT unterscheidet.
• Produkt- und Entwicklungsteams: verantworten den Code, entwickeln und testen die Fixes und liefern die Releases aus.
• Release-Management: entscheidet, welche unterstützten Branches wann einen Fix erhalten.
• Kundensupport und Kommunikation: kümmern sich um Kundenfragen und die Zielgruppe des Advisorys.
• Recht: berät zu Offenlegung, Verträgen und behördlichen Meldungen.
• Externe Beteiligte: Meldende, Koordinatoren wie CERT/CC oder ein nationales CSIRT, Upstream-Maintainer betroffener Komponenten und Kunden, die den Fix einspielen müssen.

Fristen und SLAs

Es gibt keine einheitlich vorgeschriebene Frist. Die meisten Hersteller setzen interne Ziele nach Schweregrad und veröffentlichen die externen in ihrer Offenlegungsrichtlinie. Eine typische Struktur:

• Bestätigen Sie eine externe Meldung innerhalb weniger Werktage.
• Triagieren Sie innerhalb von Tagen, damit Meldende und das zuständige Team den Stand kennen.
• Beheben Sie innerhalb einer Frist, die sich nach Schweregrad und Ausnutzung richtet, am kürzesten bei kritischen Befunden und allem, was bekanntermaßen ausgenutzt wird.
• Legen Sie offen, wenn der Fix verfügbar ist, oder zu einem vereinbarten Termin, wenn sich der Fix verzögert.

Äußerer Druck setzt die Obergrenze. Forschende setzen oft eine Offenlegungsfrist (Google Project Zero gibt Herstellern 90 Tage), und die Regulierung kommt hinzu: Der EU Cyber Resilience Act verlangt von Herstellern, Schwachstellen unverzüglich zu beheben, und setzt Meldefristen für aktiv ausgenutzte Schwachstellen (siehe was der CRA verlangt). Wird eine Schwachstelle bereits ausgenutzt, wie bei einer Zero-Day-Schwachstelle, läuft jede Stufe mit der kürzesten Frist.

Wo der Lebenszyklus scheitert

Die meisten Verzögerungen entstehen nicht beim Schreiben des Fixes. Sie entstehen, weil Sie nicht wissen, was Sie ausgeliefert haben.

• Nicht wissen, welche Releases eine Komponente enthalten. Eine neue CVE trifft eine Bibliothek. Welche Releases des letzten Jahres enthalten sie, und welche Kunden betreiben diese? Ohne Aufzeichnung pro Release bauen Teams alte Tags neu oder durchsuchen Repositories von Hand, und die Liste betroffener Versionen im Advisory ist geraten.
• Transitive Abhängigkeiten. Viele verwundbare Pakete haben Sie nicht selbst gewählt. Sie kommen als transitive Abhängigkeiten mehrere Ebenen tiefer herein, sodass eine Suche in Ihren Manifesten sie übersieht.
• Rauschen durch Entwicklungsabhängigkeiten. Scanner, die Lockfiles lesen, melden Test-Frameworks und Build-Tools, die nie ausgeliefert werden. Jedes davon kostet Triage-Zeit und verschüttet die Befunde, die zählen.
• Komponenten außerhalb des Paketmanagers. Von Build-Skripten heruntergeladene Binärdateien, Basis-Images und Komponenten von Zulieferern erscheinen gar nicht in einem Lockfile.
• Unklare Zuständigkeit. Ein Befund, für den kein Team zuständig ist, bleibt liegen. Die Triage ist erst abgeschlossen, wenn der Fix einen Zuständigen hat.
• Fixes, die nicht halten. Eine verwundbare Version kommt über eine andere Abhängigkeit oder einen alten Branch zurück, weil nichts sie daran hindert, in den nächsten Build zu gelangen.

Kennzahlen

Kennzahl	Was sie zeigt
Zeit bis zur Bestätigung	Ob Meldende dann eine Antwort erhalten, wenn Ihre Richtlinie es zusagt
Zeit bis zur Triage	Wie lange ein Befund wartet, bevor jemand weiß, ob er relevant ist
Zeit bis zur Behebung, nach Schweregrad	Wie schnell Fixes ausgeliefert werden, gemessen vom Eingang bis zu einem verfügbaren Release
Zeit bis zum Advisory	Wie lange Kunden nach dem Fix auf Informationen warten
Anteil innerhalb des Ziels	Ob interne SLAs halten, besonders bei kritischen und ausgenutzten Befunden
Backlog nach Alter	Befunde, die feststecken, und wo
Nicht-betroffen-Quote	Wie viel Triage-Aufwand in Befunde fließt, die nicht zutreffen

Messen Sie jede Stufe einzeln. Eine lange Zeit bis zur Behebung erweist sich oft als lange Zeit, um die betroffenen Releases zu finden.

Betreiben Sie den Lebenszyklus auf Basis einer Aufzeichnung des Ausgelieferten

Jede Stufe nach der Triage setzt voraus, dass Sie wissen, was in jedem Release steckt. CRACI führt Ihre GitHub-Actions-Builds auf seinen eigenen Runnern aus und zeichnet die Pakete auf, die jeder Job tatsächlich geladen hat, einschließlich transitiver Abhängigkeiten, aus CI-Caches wiederhergestellter Pakete und Abhängigkeiten, die kein Lockfile auflistet. Jede SBOM trägt einen Vollständigkeitsstatus und lässt sich als CycloneDX oder SPDX exportieren.

CRACI bewertet überwachte SBOMs laufend neu und führt sie über Builds und Repositories hinweg zusammen, und SBOMs von Zulieferern lassen sich hinzufügen, sodass zugekaufte Komponenten zusammen mit Ihren eigenen überwacht werden. Wenn eine neue CVE auftaucht, zeigt die Build-Historie, welche früheren Builds die verwundbare Abhängigkeit enthielten, direkt oder transitiv, sodass Sie den Zeitraum kennen, in dem Sie betroffen waren, und die Inventaransicht zeigt, welche Softwareversionen in welchen Produkten im Einsatz sind. Sicherheitsteams sichten Befunde in CRACI und leiten sie an die Teams weiter, die für die Behebung zuständig sind, CRACI unterstützt VEX, und Policy-Gates können Builds blockieren, die eine bestimmte CVE enthalten, damit eine behobene Schwachstelle draußen bleibt. Siehe Schwachstellenverfolgung.

Lebenszyklus des Schwachstellenmanagements: häufig gestellte Fragen

Was sind die Stufen des Lebenszyklus des Schwachstellenmanagements?

Für einen Produkthersteller: die Schwachstelle empfangen oder entdecken, verifizieren und triagieren, die betroffenen Produkte und Versionen finden, die Behebung entwickeln, den Fix veröffentlichen, das Advisory veröffentlichen, dann überwachen und lernen. ISO/IEC 30111 nennt die Phasen Vorbereitung, Eingang, Verifizierung, Entwicklung der Behebung, Release und Nach-Release.

Was ist ISO/IEC 30111?

ISO/IEC 30111:2019 ist der internationale Standard für Prozesse zur Behandlung von Schwachstellen. Er gibt Herstellern Anforderungen und Empfehlungen für die Bearbeitung und Behebung gemeldeter Schwachstellen in ihren Produkten und Diensten, von der Policy und der Rolle des PSIRT bis zu den Behandlungsphasen und Aspekten der Lieferkette.

Was ist der Unterschied zwischen ISO/IEC 30111 und ISO/IEC 29147?

ISO/IEC 29147 behandelt den nach außen gerichteten Teil: Meldungen empfangen und Advisories veröffentlichen. ISO/IEC 30111 behandelt die interne Bearbeitung dazwischen: Verifizieren, Untersuchen, Priorisieren und Beheben. Beide sind für die gemeinsame Nutzung gedacht. Den 29147-Teil finden Sie unter koordinierte Offenlegung von Schwachstellen.

Was ist Schwachstellen-Triage?

Triage ist der Schritt, in dem ein Sicherheitsteam bestätigt, dass eine gemeldete oder entdeckte Schwachstelle real ist, beurteilt, wie schwerwiegend und dringend sie für Ihr Produkt ist, und sie an das für die Behebung zuständige Team weiterleitet. Gute Triage schließt außerdem Befunde, die nicht zutreffen, mit einer dokumentierten Begründung.

Worin unterscheidet sich Produkt-Schwachstellenmanagement vom IT-Schwachstellenmanagement?

IT-Schwachstellenmanagement patcht die Systeme, die eine Organisation betreibt. Produkt-Schwachstellenmanagement behandelt Fehler in Software, die die Organisation baut und an andere ausliefert. Es umfasst daher Schritte, die IT-Teams nicht haben: ermitteln, welche veröffentlichten Versionen betroffen sind, einen Fix an Kunden ausliefern und sie in einem Advisory darüber informieren.

Welche Kennzahlen sollte ein Prozess zur Schwachstellenbehandlung verfolgen?

Die Zeit bis zur Bestätigung einer Meldung, bis zur Triage, bis zur Behebung und bis zum Advisory, jeweils nach Schweregrad, dazu den Anteil der Befunde, die Ihre internen Ziele einhalten, das offene Backlog nach Alter und wie viele Befunde als nicht betroffen geschlossen wurden.