Der Autor schildert ein eigenes Beispiel: Die Einführung authentifizierter Scans über einen Serverbestand verdreifachte die Zahl der Funde innerhalb eines Quartals. Sicherer oder unsicherer sei dadurch nichts geworden – man habe lediglich aufgehört, so tun zu können, als wisse man nichts. Daraus ergebe sich ein perverser Anreiz: Wer an der Zahl offener Funde gemessen wird, sieht durch mehr Abdeckung schlechter aus. Teams, die so bewertet werden, lernen, nicht hinzusehen.
Ein Rückstau sei daher kein Maß für technische Schulden, sondern für ungelöste Zuständigkeit. Damit ein einzelner Fund geschlossen werden kann, müssen fünf Bedingungen erfüllt sein: Jemand weiß, dass das Asset existiert; jemand ist dafür verantwortlich; diese Person kann es ändern; sie hat Zeit dafür; und sie hat einen Grund, es vor ihrer übrigen Arbeit zu tun. Scanning liefert nur die erste Bedingung – die vier übrigen sind Governance. Deshalb könnten zwei Unternehmen mit identischen Werkzeugen, identischen Beständen und identischen Fundzahlen um den Faktor zehn auseinanderliegen, wenn es ums Tempo geht.
Vier Ausprägungen beschreibt der Kommentar. Kein Eigentümer: Das Asset ist niemandem zugeordnet – der häufigste und schlimmste Fall, weil sich ein Fund ohne Eigentümer nicht eskalieren lässt; der nicht zugeordnete Teil des Bestands ist meist auch der älteste und exponierteste. Eigentümer ohne Befugnis: Ein Team ist verantwortlich, kann aber nicht handeln, weil der Hersteller den Patch kontrolliert, ein anderes Team die Plattform besitzt oder die Anwendung vertraglich eingefroren ist. Eigentümer ohne Kapazität: Die Behebung konkurriert im selben Backlog mit Feature-Entwicklung, moderiert von einem Product Owner, in dessen Bonus Sicherheit nicht vorkommt – in Werkzeugen unsichtbar, weil die Tickets zugewiesen und in Bearbeitung aussehen. Eigentümer ohne Konsequenz: Alles ist vorhanden, aber eine verpasste Frist kostet niemanden etwas. Geht das Sicherheitsreporting an das Security-Team statt an den Vorgesetzten des Eigentümers, sei das der Normalzustand.
Der wirksamste Hebel sei deshalb keine Scanner-Aufrüstung, sondern eine akkurate, gepflegte Zuordnung von Assets zu Eigentümern: Abgleich der CMDB mit dem, was Scanner tatsächlich finden, Schließen der Lücken, ein namentlicher Eigentümer für jedes Asset. Dafür gelten drei Regeln: Verantwortung liegt bei einer Person oder einem festen Team, nie bei einer Abteilung – „Infrastruktur" lässt sich nicht alarmieren und an kein Service-Level-Agreement binden. Die Zuordnung wird laufend gepflegt, nicht einmalig erstellt, da Umorganisationen sie ständig entwerten. Und ein Asset, das niemand übernehmen will, wird als eigenständiger Governance-Befund eskaliert.
Die Zahl offener Funde sei die meistberichtete und zugleich eine der nutzlosesten Kennzahlen, weil sie Erkennungsabdeckung mit Behebungsleistung vermischt und niemandem zugerechnet werden kann. Stattdessen empfiehlt der Autor: mittlere Behebungsdauer, segmentiert nach verantwortlichem Team; SLA-Einhaltung statt Abschlussquote, da Letztere das Abarbeiten der einfachen Fälle belohnt; sowie den Anteil des Bestands mit verifiziertem Eigentümer – unterhalb von 90 Prozent seien die übrigen Zahlen kaum aussagekräftig.
In einem Programm sank die Behebungsdauer binnen sechs Monaten von 45 auf 10 Tage, die SLA-Einhaltung stieg von 30 auf 95 Prozent. Bessere Werkzeuge hätten geholfen, seien aber nicht der Eingriff gewesen: Funde wurden automatisch an benannte Teams geroutet, SLA-Verstöße an die Engineering-Leitung statt an Security gemeldet, Ausnahmen erhielten einen echten Genehmigungsweg, Assets ohne Eigentümer wurden zu Governance-Befunden. Im selben Zeitraum stieg die Entwicklerproduktivität – weil Behebung, sobald sie klar zugeordnet und priorisiert ist, planbar wird statt ungeplante Arbeit zu unterbrechen.