Ein neuer Scanner ist schnell eingeführt. Ein Klick in der Pipeline, ein Report erscheint, und plötzlich stehen dreihundert Befunde auf einer Liste. Das fühlt sich nach Fortschritt an. Sechs Wochen später ist die Liste auf achthundert gewachsen, niemand hat sie gelesen, und die Sicherheit ist keinen Schritt besser. Das Werkzeug funktioniert einwandfrei. Was fehlt, ist ein Mensch, der für die Ergebnisse geradesteht.
Ein Scanner produziert Befunde, keine Entscheidungen
Werkzeuge in der Lieferkette sind gut darin, Zustände zu melden. Eine verwundbare Abhängigkeit, ein Secret im Code, eine schwache Berechtigung. Sie sind schlecht darin zu entscheiden, was das für dieses konkrete Team, dieses Produkt und diesen Zeitplan bedeutet. Ein Befund ist eine Beobachtung, keine Handlung. Die Lücke zwischen beidem schließt kein Tool, sondern eine Zuständigkeit.
Ohne diese Zuständigkeit passiert immer dasselbe. Der Report läuft in ein Postfach oder ein Dashboard, das niemand als seines betrachtet. Jeder sieht ihn, keiner besitzt ihn. Die kritischen Punkte gehen im Rauschen der unkritischen unter. Nach kurzer Zeit klickt das Team die Benachrichtigung weg, weil sie ohnehin nie zu etwas führt.
Alarmmüdigkeit ist kein Zufall, sondern die Folge
Wenn ein Werkzeug hundert Meldungen ausgibt und neunzig davon irrelevant sind, lernt das Team, die ganze Kategorie zu ignorieren. Das ist keine Nachlässigkeit, sondern eine vernünftige Reaktion auf zu viel Lärm. Das Problem ist nur, dass mit den neunzig irrelevanten auch die zehn wichtigen verschwinden. Ein Scanner ohne jemanden, der triagiert, trainiert das Team darauf, Sicherheit zu übersehen.
Zuständigkeit heißt an dieser Stelle nicht, dass eine Person alles selbst behebt. Es heißt, dass eine Person entscheidet, was ein echter Fund ist, was warten kann und was Rauschen ist, das man abschaltet. Genau diese Entscheidung fehlt, wenn ein Tool ohne Prozess eingeführt wird.
Was eine funktionierende Zuständigkeit ausmacht
Eine tragfähige Zuständigkeit hat drei Merkmale. Erstens ist sie benannt. Nicht das Team ist verantwortlich, sondern eine Rolle mit Namen, die weiß, dass die Befunde zu ihr gehören. Zweitens hat sie das Mandat zu handeln. Wer triagiert, muss auch einen Build blockieren, ein Ticket priorisieren oder eine Ausnahme genehmigen dürfen. Verantwortung ohne Befugnis erzeugt nur Frust. Drittens ist sie mit einem Turnus verbunden. Befunde werden nicht bei Gelegenheit angeschaut, sondern in einem festen Rhythmus, damit nichts liegen bleibt, bis es jemand von außen findet.
Wichtig ist dabei die Trennung von zwei Dingen. Die Frage, ob ein Fund technisch stimmt, kann oft automatisch beantwortet werden. Die Frage, ob er in diesem Kontext gefährlich ist, braucht ein Urteil. Werkzeuge nehmen einem den ersten Teil ab. Den zweiten nicht. Wer das verwechselt, kauft Software und erwartet davon eine Entscheidung, die sie nicht treffen kann.
Erst die Zuständigkeit, dann das Werkzeug
Die Reihenfolge, in der die meisten Teams vorgehen, ist umgekehrt zur sinnvollen. Zuerst wird ein Scanner eingeführt, dann stellt man fest, dass die Befunde niemanden erreichen, und irgendwann fragt man, wer sich eigentlich kümmern sollte. Besser ist der andere Weg. Zuerst klären, wer die Ergebnisse besitzt und was mit ihnen passiert, dann das Werkzeug einschalten. Ein Scanner, dessen Output an eine klare Rolle mit klarem Prozess geht, verändert etwas. Derselbe Scanner ohne diese Rolle erzeugt nur eine wachsende Liste, die niemand liest.
Der Test ist einfach. Wenn morgen ein kritischer Fund auftaucht, weiß dann eine bestimmte Person, dass sie ihn sieht, bewertet und darüber entscheidet? Wenn die Antwort unklar ist, hilft kein weiteres Werkzeug. Dann fehlt nicht Technik, sondern die Person, die dahintersteht.
Der GitSecOps QuickCheck schaut nicht nur, welche Werkzeuge in Ihrer Pipeline laufen, sondern ob ihre Befunde jemanden erreichen und zu Entscheidungen führen. Ergebnis in 3 Werktagen, 1.990 Euro netto. Kontakt: mm@crank.zone.
Dein Blog zum Thema digitales Business 