# Vom Auffinden einer Schwachstelle bis hin zu einer Produktionsänderung · Stilla > Der Scanner findet Tausende von Problemen, aber die Behebung in der Produktion ist immer noch manuelle Arbeit. URL: https://stilla.eywo.digital/de/blog/from-vulnerability-to-change/ Language: de Last updated: 2026-10-25 [← Zurück zum Blog](https://stilla.eywo.digital/de/blog/) Sicherheit23\. Juli 2026Aktualisiert 25\. Oktober 20263 Min. LesezeitEywo-Team # Vom Auffinden einer Schwachstelle bis hin zu einer Produktionsänderung Der Scanner findet Tausende von Problemen, aber die Behebung in der Produktion ist immer noch manuelle Arbeit. Wie können Schwachstellen mit Servern, Diensten und Änderungen verknüpft werden, damit die wichtigen zuerst behoben werden? Das Sicherheitsteam erhält einen langen Export vom letzten Scan. Tausende von Zeilen, jede mit einer Schwachstellen-ID, einer IP-Adresse und einem Schweregrad. Jemand teilt es nach Teams auf und sendet es weiter. Der Betrieb versucht dann herauszufinden, welche Server diese tatsächlich sind, welchem Service sie zugehören und wann sie angefasst werden dürfen. Einen Monat später trifft der nächste Export ein, und niemand kann mit Sicherheit sagen, was von dem vorherigen behoben wurde. Hinter diesem Bild stehen müde Menschen auf beiden Seiten. Die Sicherheit fühlt sich vom Betrieb nicht gehört. Der Betrieb fühlt sich, als erhielte er Listen ohne Kontext und ohne Prioritäten. Und das Management stellt eine einfache Frage, die niemand schnell beantworten kann: Sind wir in einer besseren Position als letzten Monat? ## Warum ein Scanner-Export nicht genug ist Ein Scanner tut, wofür er gebaut wurde: Er findet anfällige Softwareversionen. Was er nicht weiß, ist, welche Rolle ein Server spielt, welcher Service darauf läuft und wer für diesen Service verantwortlich ist. Ohne diese Informationen kann ein Fund nicht sinnvoll in Arbeit umgesetzt werden. Wir sehen oft dieselben Schwächen: - Fundstellen werden allein nach ihrem Score bewertet, obwohl es in der realen Betriebsumgebung wichtiger ist, ob eine Schwachstelle aktiv ausgenutzt wird, - Fix-Fristen werden nicht aus der Schwere abgeleitet, sodass ein kritischer Fund genauso lange warten kann wie ein kleiner, - der Weg von der Fundstelle zur Änderung führt über E-Mail und manuell erstellte Tickets, - der Remediationsstatus wird aus mehreren Tabellen zusammengestrickt und ist immer einen Schritt hinterher. ## Wie man es angeht Eine Schwachstellen-Fundstelle wird erst dann sinnvoll, wenn sie mit der CMDB verbunden ist. Sobald wir wissen, auf welchem Server sie sitzt, wissen wir auch, welcher Service dadurch gefährdet ist, wer diesen Service besitzt und was das Wartungsfenster ist. Nur dann können wir über Reihenfolge und Zeitplanung entscheiden. Die Priorität sollte sich an zwei Fragen orientieren: Wie schwer ist die Schwachstelle, und wird sie aktiv ausgenutzt? Die Frist ergibt sich aus der Antwort. Der Weg zur Behebung sollte durch den normalen Änderungsprozess führen, sodass auch eine dringende Behebung die Auswirkungen auf Services berücksichtigt, jedoch mit kürzeren Vorlaufzeiten. ## Wie Stilla es handhabt Stilla **importiert Fundstellen von Ihrem Scanner** und ordnet sie CMDB-Elementen zu. Schwachstellen sind dann pro Server und pro Service sichtbar, sodass jeder Service Owner sieht, was ihn betrifft. Die Priorisierung baut darauf auf: - **aktiv ausgenutzte Schwachstellen (KEV)** werden deutlich gekennzeichnet, damit sie nicht unter den übrigen verloren gehen, - **schweregradbasierte Fristen** legen fest, wann eine Fundstelle behoben werden muss, - **ein beschleunigter Modus für kritische Probleme**, der im Voraus im Patch-Vereinbarung mit dem Service Owner vereinbart wird, bietet einen kürzeren Weg, ohne die Verantwortlichkeit zu umgehen. Der Weg von der Fundstelle zur Behebung ist ein **wellenbasierter Patch-Plan**. Server werden nach Service und Fenster gruppiert, und der Plan generiert die Änderungen in einem Schritt. Jede Änderung durchläuft die Wirkungsberechnung, die Überprüfung von Wartungsfenstern, Freeze und Kollisionserkennung. Redundante Knoten können nacheinander gepatcht werden, damit der Service verfügbar bleibt. Das **Schwachstellen- und Remediations-Dashboard** zeigt, wie viele Fundstellen offen sind, welche sich ihrem Termin nähern und wie die Remediation pro Service voranschreitet. Sicherheit und Betrieb sehen dieselben Daten, was die Diskussion darüber beendet, welche Tabelle aktuell ist. ## Ein gemeinsames Bild statt des Austauschs von Listen Schwachstellen-Management ist nicht nur eine Sicherheitsdisziplin. Es ist operative Arbeit, die Kontext benötigt: Server, Services, Besitzer und Änderungen. Wenn diese Informationen verbunden sind, muss die Sicherheit nicht mehr hinterherjagen, und der Betrieb muss nicht mehr raten. Beide Seiten können sehen, was als Erstes behoben werden muss, wer es genehmigt und wann es passiert. Und die Frage des Managements, ob die Dinge besser sind als letzten Monat, hat auf einem einzigen Bildschirm eine Antwort. Der Import von Fundstellen, die Priorisierung von Schwachstellen, die Patch-Planung und das Remediations-Dashboard sind in der Business-Edition enthalten. **Stilla Business** Für Betriebsabläufe, die Monitoring, Sicherheit und Anbieter verbinden möchten. [Editionen vergleichen →](https://stilla.eywo.digital/de/editions/) ## Weitere Artikel [Sicherheit·16\. Juli 2026 ### Patching ohne monatliche Verhandlungen Jeden Monat das gleiche Prozedere: E-Mails über den Zeitpunkt, an dem Server neu gestartet werden dürfen. Eine Patch-Vereinbarung mit dem Service Owner verwandelt eine wiederkehrende Verhandlung in eine Dauerrichtlinie. Business3 Min. Lesezeit](https://stilla.eywo.digital/de/blog/patching-without-monthly-negotiation/)[CMDB·25\. Oktober 2026 ### Das virtuelle Netzwerk in der CMDB: von der Portgruppe bis zum Leaf-Switch Zwischen einer virtuellen Maschine und dem physischen Netzwerk liegt eine Schicht, die die meisten CMDBs nicht sehen – virtuelle Switches, Port Groups und Host-Uplinks. Doch genau hier wird entschieden, welche Business-Services eine Netzwerk-Änderung berührt. Standard3 Min. Lesezeit](https://stilla.eywo.digital/de/blog/virtual-network-in-the-cmdb/)[Governance·25\. Oktober 2026 ### NIS2 und DORA: Was der IT-Betrieb nachweisen können muss Beide Vorschriften stellen dieselbe Frage: Wissen Sie, welche Services ein Ausfall trifft, wer dafür verantwortlich ist und was sich wann geändert hat? Ohne eine zuverlässige Abhängigkeitskarte müssen die Antworten oft unter Zeitdruck manuell zusammengestellt werden. Standard2 Min. Lesezeit](https://stilla.eywo.digital/de/blog/nis2-dora-evidence/)