Schwachstellenmanagement für NIS2, CRA & C5: 3 häufige Fehler

Angetrieben durch Regulierungen wie NIS2 und den Cyber Resilience Act (CRA) beginnen immer mehr Unternehmen, ihre Systeme systematisch auf Sicherheitslücken zu durchleuchten. Der Einstieg scheint leicht: Für nahezu jeden Bereich des Tech-Stacks gibt es passende Scanner – von Open-Source-Tools wie Trivy, Syft oder Dependency-Track bis hin zu kommerziellen Lösungen wie Snyk oder SonarQube –, die sich schnell in bestehende CI/CD-Pipelines integrieren lassen.

Doch wie so oft steckt der Teufel im Detail. Denn das bloße Scannen von Code und Containern erfüllt noch lange nicht die aktuellen NIS2-Anforderungen oder die Pflichten des Cyber Resilience Act.

Alle großen Sicherheitsstandards – egal ob NIS2 (insbesondere Art. 21 zur Sicherheit in der Softwareentwicklung), der BSI IT-Grundschutz (Baustein CON.8), die ISO 27001 oder ein BSI C5 Testat – fordern weit mehr als das einmalige Aufdecken von Bugs. Sie verlangen ein durchgängiges Schwachstellenmanagement. Und genau das stellt Organisationen vor enorme Herausforderungen: Plötzlich reicht es nicht mehr, einen Scanner zu installieren. Stattdessen müssen Engineering, Compliance, Produktmanagement und Geschäftsführung eng verzahnt zusammenarbeiten, um Risiken im Ernstfall schnell zu bewerten und fristgerecht zu beheben.

Bei vielen Unternehmen, die diesen Prozess gerade erst aufbauen, passiert in der Praxis jedoch das Gegenteil: Statt klarer Abläufe entsteht ein unübersichtlicher Datenstau. Damit Ihnen das nicht passiert, zeigen wir die drei häufigsten Fehler im Schwachstellenmanagement – und wie Sie diese vermeiden.

1. Vulnerability Scanning mit echtem Schwachstellenmanagement verwechseln

Ein CVE-Scanner oder ein Tool für die statische Codeanalyse (SAST) beantwortet zunächst genau eine Frage: Welche bekannten Lücken lassen sich jetzt gerade in diesem System nachweisen? Für ein funktionierendes Schwachstellenmanagement – und erst recht für ein Audit – reicht diese Momentaufnahme nicht aus.

Ein einfaches Gedankenexperiment: Ein Unternehmen scannt seine Applikationen jeden Montag und erhält jedes Mal einen Report mit 100 Findings. Wie steht es um die Anwendungssicherheit? Unmöglich zu sagen. Es könnten seit Monaten dieselben 100 Altlasten sein. Vielleicht wurden aber auch 80 Probleme behoben, während durch neue Releases 80 neue hinzugekommen sind. Ohne saubere Historie tappt man komplett im Dunkeln.

In modernen Softwarelandschaften wird das schnell komplex. Meist laufen unterschiedliche Tools für Container Security, Software Composition Analysis (SCA) und eigenen Anwendungscode parallel. Die Ergebnisse überschneiden sich, nutzen verschiedene Bezeichnungen und liefern Rohdaten, die erst einmal den richtigen Services und Teams zugeordnet werden müssen.

Dazu kommt: Daten zu Sicherheitslücken verändern sich. Ein Bug taucht erst als GitHub Security Advisory (GHSA) auf, bekommt Tage später eine offizielle CVE-ID, und eine Woche darauf ändern sich der Schweregrad oder die betroffenen Versionen. Wer diese Informationen nicht automatisch zusammenführt, ertrinkt schnell in Dubletten und veralteten Tickets.

SBOM und Software Supply Chain: Ohne Historie wertlos

Auch der Unterschied zwischen einer Schwachstelle an sich und ihrem konkreten Auftreten geht oft unter. Steckt dieselbe verwundbare Bibliothek in fünf verschiedenen Microservices, ist das technisch gesehen eine einzige Lücke – in der Praxis sind es aber fünf unterschiedliche Risiken mit eigenen Release-Zyklen und unterschiedlicher Exposition.

Besonders deutlich wird das in der Software Supply Chain. Anwendungen bestehen heute überwiegend aus externen Frameworks, die wiederum dutzende transitive Abhängigkeiten mitbringen. Eine maschinenlesbare SBOM (Software Bill of Materials), wie sie der Cyber Resilience Act fordert – z. B. im CycloneDX- oder SPDX-Format –, schafft zwar wichtige Transparenz über die verbauten Komponenten. Doch eine statische SBOM veraltet in dem Moment, in dem der nächste Commit durch die Pipeline läuft.

Das Problem sind also selten die Scanner selbst. Werkzeuge wie Trivy, Grype oder Dependency-Track leisten hervorragende Vorarbeit. Es knirscht erst, wenn deren Ergebnisse isoliert betrachtet und manuell in Tabellen zusammenkopiert werden. Was Unternehmen brauchen, sind keine losen Einzelbefunde, sondern eine durchgängige Historie über den gesamten Lebenszyklus einer Anwendung hinweg.

2. Ohne Anwendungskontext und Reachability Analysis priorisieren

Sobald mehrere Scanner regelmäßig Ergebnisse liefern, folgt unweigerlich die Frage: Womit fangen wir an? Der Klassiker ist die Sortierung nach dem technischen Schweregrad (CVSS-Score): erst „Critical“, dann „High“, der Rest später.

Das wirkt auf dem Papier logisch, geht aber an der Realität vorbei. Der theoretische CVSS-Wert einer Lücke sagt wenig über das tatsächliche Risiko für eine konkrete Anwendung aus.

Ein bekanntes Beispiel ist npm audit. Das Tool prüft standardmäßig auch Development-Dependencies – also Pakete, die nur lokal für Tests oder den Build-Prozess gebraucht werden. Meldet der Dependency Scanner dort eine kritische Lücke, ist das für das Produktivsystem meist irrelevant, weil der Code dort überhaupt nicht ausgeliefert wird. Umgekehrt kann eine Lücke mit mittlerem Score in einem öffentlich erreichbaren API-Endpunkt ein massives Einfallstor sein.

Selbst wenn ein verwundbares Paket live in Produktion läuft, heißt das noch nicht, dass es auch ausnutzbar ist. Hier kommt die Reachability Analysis (Erreichbarkeitsanalyse) ins Spiel: Wird die verwundbare Funktion im eigenen Code überhaupt aufgerufen? Kommen externe Nutzereingaben ungefiltert bis zu dieser Stelle durch? Ein reiner Dependency Scanner sieht das nicht. Dafür braucht es Kontext über den Anwendungscode, die Ausführungspfade und die Laufzeitumgebung.

Security konkurriert immer mit der Produkt-Roadmap

Ein Punkt fällt bei der NIS2-Umsetzung oder der Einführung von DevSecOps-Prozessen gerne unter den Tisch: Das Beheben von Schwachstellen kostet Entwicklungszeit. Und genau die ist knapp.

Entwicklungsteams und Produktmanager wägen täglich ab: Bauen wir das neue Feature, lösen wir das Performance-Problem oder ziehen wir das Security-Update vor? Nicht jedes Finding rechtfertigt es, den aktuellen Sprint abzubrechen.

In eine sinnvolle Priorisierung gehören deshalb neben dem technischen Risiko und der Ausnutzbarkeit auch der reale Behebungsaufwand sowie regulatorische Fristen. Ein überfälliges Problem, das sich in fünf Minuten per Versions-Update lösen lässt, sollte im Zweifel Vorrang vor einer theoretisch kritischen Lücke haben, die in der eigenen Architektur gar nicht erreichbar ist, für deren Fix man aber das halbe System umbauen müsste.

Fehlt diese Differenzierung, läuft das Backlog voll mit hunderten „kritischen“ Tickets. Die Folge ist Alert Fatigue: Wenn alles höchste Priorität hat, hat am Ende nichts mehr Priorität. Teams schieben Security-Aufgaben vor sich her – nicht aus Gleichgültigkeit, sondern weil ihnen eine belastbare Grundlage fehlt, wo sich der Zeiteinsatz wirklich lohnt.

3. Keine belastbaren Kennzahlen für Management und Auditoren messen

Woran erkennt die Geschäftsführung eigentlich, dass die Maßnahmen im Schwachstellenmanagement greifen? Während in fast jedem Unternehmensbereich mit klaren KPIs gearbeitet wird, beschränkt sich das Security-Reporting oft auf eine simple Zahl: die Summe der offenen Findings nach Schweregrad.

Diese Zahl allein ist für die Steuerung und für Compliance-Nachweise nahezu wertlos.

Stellen Sie sich ein Unternehmen vor, bei dem jede Woche 100 neue Findings hinzukommen. Schaffen die Teams im selben Zeitraum 120 Fixes, bauen sie technische Risiken kontinuierlich ab. Schließen sie dagegen nur zehn, wächst der Rückstand unaufhaltsam – obwohl der wöchentliche Scan-Bericht auf den ersten Blick fast identisch aussieht.

Entscheidend ist nicht der nackte Bestand, sondern die Dynamik: Wie schnell werden Probleme gelöst und welche Risiken bleiben offen?

Welche Metriken für NIS2, CRA und C5:2026 wirklich zählen

Eine zentrale Messgröße ist die Mean Time to Remediation (MTTR), also die durchschnittliche Zeit von der Erkennung bis zur Behebung. Aber auch hier lohnt sich ein genauer Blick: Ein guter Durchschnittswert kann leicht verdecken, dass zwar viele einfache Lücken schnell geschlossen werden, hochkritische Probleme aber über Monate offen bleiben. Die MTTR sollte daher immer nach Risikoklassen getrennt und um das Alter offener Findings ergänzt werden.

Darüber hinaus verlangen moderne Regulatorien handfeste Prozessnachweise:

• CRA-Meldepflichten einhalten: Seit September 2026 greifen die Meldepflichten des Cyber Resilience Act für aktiv ausgenutzte Schwachstellen – inklusive einer 24-Stunden-Frist für die Frühwarnung und 72 Stunden für die detaillierte Meldung. Ohne klaren Überblick, welche Komponente in welchem Produkt steckt und ob sie tatsächlich ausnutzbar ist, sind diese Fristen kaum zu halten.
• VEX (Vulnerability Exploitability eXchange) & Entscheidungen dokumentieren: Nicht jede Lücke in einer SBOM erfordert ein sofortiges Software-Update. Manchmal ist der verwundbare Code nicht erreichbar, das Risiko wird durch andere Kontrollen abgefangen oder bewusst akzeptiert. Über standardisierte Formate wie VEX und ein sauberes Status-Tracking lassen sich solche Entscheidungen für Kunden und Prüfer nachvollziehbar dokumentieren.
• Echter Deployment-Status für BSI C5 & Audits: Gerade der aktualisierte Kriterienkatalog BSI C5:2026 legt deutlich mehr Gewicht auf ein stringentes Patch-, Schwachstellen- und Container-Management. Ein geschlossenes Entwickler-Ticket in Jira reicht hier als Nachweis nicht aus – entscheidend ist, dass der Fix nachweislich in allen produktiven Umgebungen ausgerollt wurde.

Erst dieses lückenlose Tracking schafft die Datengrundlage für Auditoren und das eigene Management. Ohne diese Transparenz lässt sich weder im Audit ein gelebter Prozess belegen noch intern beurteilen, ob sich zusätzliche Security-Investitionen tatsächlich auszahlen.

Fazit: Compliance und Sicherheit brauchen Prozesse, nicht nur Scanner

Vulnerability Scanner sind das unverzichtbare Fundament für die Anwendungssicherheit, liefern aber zunächst nur Rohdaten. Echte Sicherheit – und belastbare Compliance für NIS2, CRA, ISO 27001 oder BSI C5 – entsteht erst, wenn Engineering, Security und Compliance-Verantwortliche auf derselben Datengrundlage arbeiten.

Die größte Gefahr besteht heute nicht mehr darin, eine Schwachstelle technisch zu übersehen. Das Risiko liegt darin, dass die wirklich kritischen Probleme im Grundrauschen hunderter unpriorisierter Meldungen untergehen. Erfolgreiches Schwachstellenmanagement misst sich deshalb nicht an der Anzahl der gefundenen Bugs, sondern daran, wie verlässlich und ressourcenschonend ein Unternehmen seine tatsächlichen Risiken reduziert.

Schwachstellenmanagement und ASPM automatisieren – mit Farion

Genau um diese Brücke zwischen technischen Scannern, Entwicklungsteams und regulatorischen Anforderungen zu schlagen, haben wir Farion entwickelt. Als Plattform für Application Security Posture Management (ASPM) führt Farion Ergebnisse aus unterschiedlichsten Sicherheitsanalysen und Open-Source-Scannern zentral zusammen und reichert sie mit dem nötigen Kontext an: Durch die Analyse von Abhängigkeiten (SBOM), tatsächlicher Erreichbarkeit im Code (Reachability Analysis) und Ausnutzbarkeit erkennen Teams sofort, welche Risiken für ihre Anwendungen wirklich relevant sind.

Eine intelligente Priorisierung verbindet das technische Risiko mit Dringlichkeit, SLA-Vorgaben und Behebungsaufwand. Gleichzeitig sorgt die lückenlose Historie dafür, dass Fortschritte messbar werden und Sie gegenüber Geschäftsführung und Auditoren jederzeit nachweisen können, dass Sie Ihre Sicherheitsrisiken im Griff haben.