Am Montag wird eine Schwachstelle als für das eigene Produkt nicht relevant bewertet. Am Donnerstag aktiviert ein Entwicklungsteam eine bisher ungenutzte Funktion. Der alte Vermerk bleibt bestehen, die technische Voraussetzung seiner Begründung jedoch möglicherweise nicht. Genau an dieser Stelle entscheidet sich, ob VEX die Bearbeitung verbessert oder eine neue Form veralteter Ausnahmen erzeugt.
Für deutsche Softwarebetreiber und Hersteller liegt der praktische Nutzen maschinenlesbarer Sicherheitsinformationen in einer nachvollziehbaren Entscheidungskette. Sie verbindet Meldung, Produkt, tatsächlichen Einsatz und erneute Prüfung. Eine niedrigere Zahl offener Tickets allein belegt noch keine bessere Sicherheit.
Von der Meldung zur überprüfbaren Aussage
Das BSI beschreibt CSAF als maschinenverarbeitbares Format, mit dem Sicherheitsmeldungen abgerufen und mit einem eigenen Inventar abgeglichen werden können. Damit wird ein bisher häufig manueller Informationsfluss besser automatisierbar. Der Abgleich braucht allerdings belastbare Angaben darüber, welche Produkte tatsächlich eingesetzt werden.
Die DGUV erläutert CSAF und VEX im industriellen Umfeld. VEX ermöglicht eine Aussage dazu, ob ein Produkt von einer Schwachstelle betroffen ist. Daraus folgt eine wichtige Trennung: Eine Komponentenliste beschreibt den Inhalt der Software; eine Bewertung ordnet eine konkrete Schwachstelle einem Produktkontext zu.
Diese Quellen liefern einen technischen Ausgangspunkt. Sie bedeuten weder, dass jede deutsche Firma dasselbe Austauschformat einsetzen muss, noch dass eine maschinenlesbare Aussage ohne fachliche Prüfung übernommen werden sollte. Für einen konkreten Auftrag müssen Format, Verantwortlichkeiten und Empfänger vereinbart werden.
Ein Beispiel aus einer Integrationsplattform
Stellen Sie sich einen fiktiven Anbieter vor, der eine Plattform für Lieferantendokumente betreibt. Eine Bibliothek enthält eine anfällige Importfunktion. Das Team bewertet die veröffentlichte Anwendung zunächst als nicht betroffen, weil diese Funktion dort nicht erreichbar ist. Die Entscheidung enthält die geprüfte Version und die technische Begründung.
Später ergänzt ein Projektteam einen neuen Dokumentimport. Die Bibliothek bleibt unverändert, der aufrufende Anwendungscode jedoch nicht. Wer nur Versionsänderungen der Bibliothek überwacht, übersieht möglicherweise die relevante Veränderung.
Ein sinnvoller Ablauf verknüpft die ursprüngliche Bewertung deshalb mit ihrer Voraussetzung. Die Einführung eines neuen Importpfads öffnet die Prüfung erneut. Das Ergebnis kann weiterhin unkritisch sein; entscheidend ist, dass die alte Begründung nicht ungeprüft auf eine andere Anwendung übertragen wird.
Produktidentität ist keine reine Schreibweise
Ein Herstellername und eine Versionsnummer reichen nicht in jeder Umgebung aus. Unterschiedliche Pakete, Images, Erweiterungen oder Bereitstellungsvarianten können unter ähnlichen Bezeichnungen laufen. Die Zuordnung muss so genau sein, dass ein Bearbeiter erklären kann, welches ausgelieferte Artefakt betrachtet wurde.
Beginnen Sie mit einem kleinen, wichtigen Produktbestand. Verbinden Sie dessen Kennungen mit dem Build oder Release, der tatsächlich produktiv ist. Halten Sie auch fest, welche Varianten bewusst nicht durch eine Aussage abgedeckt sind. Unklarheit sollte als offene Zuordnung erscheinen und nicht automatisch als Entwarnung.
Ein externer Dienstleister sollte dieses Zuordnungsproblem anhand Ihrer Daten zeigen. Eine Vorführung mit perfekt vorbereiteten Beispielen beweist nicht, dass die vorhandenen Namen in Einkauf, Betrieb und Entwicklung zusammenpassen.
Eine begründete Entscheidung hat einen Lebenszyklus
Die Bearbeitung beginnt mit dem Eingang einer Meldung. Danach folgen Zuordnung, fachliche Prüfung, Entscheidung und gegebenenfalls eine Maßnahme. Jede dieser Stufen braucht einen sichtbaren Zustand. Wenn Informationen fehlen, ist ein dokumentiertes „noch nicht geklärt“ hilfreicher als eine künstlich vollständige Bewertung.
Zur Entscheidung gehören mindestens das betrachtete Produkt, die Schwachstelle, die Aussage, die Begründung und der verantwortliche Prüfer. Ergänzen Sie die technischen Voraussetzungen und den Zeitpunkt der nächsten vorgesehenen Überprüfung. Diese Angaben müssen nicht alle im selben Dokumentformat stehen, solange die Verbindung zuverlässig bleibt.
Ändert sich eine Voraussetzung, wird die Entscheidung erneut geprüft. Dazu können eine neue Produktvariante, eine aktivierte Schnittstelle, eine geänderte Berechtigung oder zusätzliche Herstellerinformationen gehören. Ein Ablauf, der nur neue CVE-Nummern verarbeitet, erfasst diese Veränderungen nicht zuverlässig.
Automatisierung braucht einen Weg für Ungewissheit
Automatisieren Sie wiederkehrende Schritte wie Abruf, Formatprüfung, Zuordnungsvorschläge und Benachrichtigungen. Legen Sie vorher fest, was bei widersprüchlichen Aussagen geschieht. Eine neuere Meldung muss beispielsweise nicht dieselbe Produktmenge behandeln wie eine ältere.
Auch Herkunft und Integrität der Informationen verdienen Aufmerksamkeit. Wer darf eine Bewertung liefern, über welchen Kanal kommt sie an und wie wird eine Änderung erkannt? Ein technisch gültiges Dokument ist nicht automatisch eine für Ihr Produkt autorisierte Aussage.
Für operative Teams sollte der nächste Schritt klar sein. Eine nicht zuordenbare Meldung geht an den Produktverantwortlichen. Eine begründete Betroffenheit führt in den vereinbarten Maßnahmenprozess. Eine Entwarnung mit geänderter Voraussetzung wird zur erneuten Prüfung vorgelegt. So entsteht ein Arbeitsablauf statt eines weiteren Ablageorts.
Den Nutzen an Entscheidungen messen
Ein Pilot kann eine kleine Auswahl realer, bereinigter Meldungen durchlaufen. Nehmen Sie eine eindeutige Betroffenheit, eine begründete Nichtbetroffenheit, eine unbekannte Produktvariante und einen später geänderten Einsatzfall auf. Beobachten Sie, ob das System den richtigen Bearbeiter erreicht und ob dieser die Entscheidung erklären kann.
Sinnvolle Kennzahlen betreffen die Zuordnungsqualität, unbearbeitete Unsicherheiten und veraltete Entscheidungen. Eine hohe automatische Schließungsquote kann dagegen ein Warnsignal sein, wenn Voraussetzungen nicht überprüft werden.
Unser Beitrag zur Abnahme individueller Software hilft, solche Ergebnisse als überprüfbare Liefergegenstände zu formulieren. Vereinbaren Sie außerdem, wer den Ablauf nach Projektende pflegt, neue Produktvarianten ergänzt und geänderte Quellen bewertet.
Wenn Sie Sicherheitsmeldungen mit Ihrem Produktinventar und Ticketsystem verbinden möchten, finden Sie hier unsere Cybersecurity-Leistungen. Beschreiben Sie Ihren heutigen Bewertungsprozess, damit TuniCyberLabs gemeinsam mit Ihrem Team einen passenden Integrationsumfang für die Zusammenarbeit aus der Ferne prüfen kann.