Auf den Punkt: Ein wachsender Vulnerability-Backlog zeigt meist kein Versagen des Sicherheitsteams, sondern fehlende organisatorische Klarheit darüber, wer Remediation tatsächlich umsetzen und wer Restrisiken akzeptieren muss.
Wenn Sicherheitsteams nicht nur Risiken erkennen, sondern auch jede Behebung selbst durchführen sollen, entsteht ein strukturelles Problem: Der Backlog wächst nicht wegen mangelnder Security-Arbeit, sondern weil Verantwortlichkeiten für die Umsetzung nie klar zugewiesen wurden.
Ein gängiges, aber ineffektives Betriebsmodell weist Sicherheitsteams die vollständige Verantwortung für das Auffinden, Priorisieren, Zuweisen, Umsetzen, Nachverfolgen und Validieren jeder einzelnen Korrekturmaßnahme zu. Entdeckt ein Scanner ein veraltetes Softwarepaket, soll Security den Server patchen. Findet eine Cloud-Security-Plattform einen offenen Storage-Bucket, soll Security das Deployment neu gestalten. Deckt ein Audit überhöhte Berechtigungen in einer Fachanwendung auf, soll Security die Zugriffsänderungen mit der zuständigen Fachabteilung aushandeln. Dieses Muster entsteht, weil das Erkennen von Schwachstellen sichtbar ist, die Behebung dagegen oft unbequem – mit der Zeit erwarten Infrastruktur-, Engineering- und Fachbereichs-Eigentümer, dass Security Tickets erstellt, Anweisungen liefert, Termine koordiniert, Fristen überwacht, Ausnahmen beantragt und Verzögerungen an die Leitung meldet.
Ein effektiveres Modell trennt die Rollen klar: Security fungiert als Aufsichtsinstanz, während Technik- und Fachbereiche die Umsetzung verantworten. Sicherheitsteams pflegen das maßgebliche Risikoinventar, legen Prioritäten und Remediation-Standards fest, eskalieren verpasste Zusagen und verifizieren den Abschluss von Maßnahmen. Die Eigentümer der betroffenen Infrastruktur, Cloud-Umgebung, Anwendung, Identitätsplattform oder des Geschäftsprozesses sind für die tatsächliche Umsetzung der Fixes zuständig. Führungskräfte lösen Ressourcenkonflikte auf und akzeptieren explizit jene Risiken, die die Organisation bewusst nicht beheben will. Diese Unterscheidung entscheidet darüber, ob ein Vulnerability-Management-Programm Risiko tatsächlich reduziert oder lediglich Tickets erzeugt.
Ein anwachsender Backlog wird häufig dem Sicherheitsteam angelastet, weil dieses das Dashboard pflegt. Das Dashboard legt jedoch primär ein umfassenderes organisatorisches Versagen offen: Eigentümerschaft für Assets wurde nie zugewiesen, Remediation-Aufwand wurde nicht in die operative Kapazitätsplanung aufgenommen, und die Leitung hat keine klare Entscheidungsbefugnis darüber etabliert, wann Verfügbarkeit, Produktlieferung, Kundenzusagen oder technische Schulden zugunsten der Risikoreduktion zurückstehen müssen. Das NIST Cybersecurity Framework 2.0 betont Governance, Priorisierung und Kommunikation von Cybersicherheitsrisiken über die gesamte Organisation hinweg – es empfiehlt jedoch nicht, dass die Sicherheitsfunktion jede Behebung selbst ausführt. Auch die NIST-Leitlinien zum Enterprise Patch Management beschreiben Patching als präventive Wartung und regulären Geschäftskostenpunkt, nicht als exklusive Aufgabe des Sicherheitsteams.
Ein Backlog ist damit keine bloße Sammlung technischer Schwachstellen, sondern ein Protokoll unbeantworteter organisatorischer Entscheidungen: Wer besitzt das System? Wer hat die Befugnis, Änderungen umzusetzen? Welche Geschäftsauswirkungen sind zu berücksichtigen? Welche Kapazität steht zur Verfügung? Wer darf das verbleibende Risiko akzeptieren? Der wirksamste Weg, Accountability zu erhalten, besteht darin, Zuständigkeiten festzulegen, bevor neue Findings auftauchen – Security besitzt dabei das maßgebliche Risikoinventar inklusive Validierung von Findings, Bereinigung von Duplikaten und False Positives sowie der Verknüpfung technischer Schwachstellen mit betroffenen Assets und Geschäftsdiensten.
Quelle: www.csoonline.com · Erschienen 14. August 2026
Lumi AI News — KI-assistierte Kuratierung gemaess Art. 50 EU AI Act. Paraphrase und Klassifikation durch Lumi News Pipeline v1.8.3.