Sicherheitswissen staut sich bei wenigen Personen
Das OWASP-Kapitel zu Security Champions sagt es nüchtern: Sicherheitsleute skalieren nicht über die Teams von Entwicklern hinweg. Ein guter Weg sind Champions, also Teammitglieder, die Sicherheit im Team tragen.
Dieser Beitrag stützt sich auf drei Quellen aus dem OWASP-Umfeld, gelesen am 26.09.2026: das Kapitel Security Champions im Projekt Security Culture, das dort referenzierte Security Champions Playbook (persönliches GitHub-Repository seines Autors, kein OWASP-Repository) und den OWASP Security Champions Guide. Auslegung und Empfehlung sind gekennzeichnet.
Zur Abgrenzung: Warum Sicherheitswerkzeuge scheitern, wenn niemand für die Befunde zuständig ist beschreibt, wer Scanner-Befunde besitzen muss. Code Review als Sicherheitskontrolle, nicht als Formalakt behandelt das Review als Kontrolle in der Pipeline. DevSecOps vs DevOps: was der Unterschied praktisch bedeutet erklärt, an welcher Stelle der Pipeline Sicherheit passiert. Shared Responsibility Model: wo deine Pipeline-Pflicht beginnt trennt die Pflichten von Cloud-Anbieter und Nutzer. Hier geht es um Auswahl, Zeitanteil und Wirkung im Team.
Was ein Champion ist
Das Playbook beschreibt Champions als aktive Teammitglieder, die mitentscheiden können, wann das Sicherheitsteam eingebunden wird. Im Team sind sie die erste Ansprechperson für Sicherheitsfragen. Nach dem OWASP-Kapitel gehören dazu Sicherheitsthemen im Team voranbringen, Threat Modeling, sichere Code-Reviews und der Einsatz von Sicherheits-Testwerkzeugen. Die Rolle kann eine Entwicklerin, ein Ops-Kollege oder eine QA-Person übernehmen.
Ein Champion ersetzt kein Sicherheitsteam. Laut Kapitel holt er sich dort Rat. Auslegung: Gibt es bei dir keine solche Stelle, fehlt diese Anlaufstelle.
Security Champions auswählen: nominieren, nicht zuweisen
Das Playbook schreibt: „it’s not appointing but nominating“. Das OWASP-Kapitel sagt: „nominated, rather than assigned“. Der Guide rät, Freiwillige zu suchen und ein Zuweisen möglichst zu vermeiden.
Das Playbook beschreibt den Ablauf: Kandidaten gemeinsam mit der Teamleitung auswählen, mit jeder Person ein kurzes Gespräch führen und dabei Rolle, Erwartung und persönlichen Nutzen erklären. Als Nutzen nennt es unter anderem Weiterentwicklung und höheren Marktwert. Das OWASP-Kapitel empfiehlt außerdem, Champions nach Technologie zuzuordnen, etwa Frontend, Backend oder Mobile, damit ihr Fachwissen zum Einsatz kommt.
Der Guide warnt vor einer Falle: Hängt das Programm an wenigen Personen, kippt es, wenn eine davon geht. Er rät von dem Modell ab, in dem jedes Team genau einen Champion hat, und empfiehlt Gruppen nach Spezialgebiet. Empfehlung, keine Aussage der Quelle: In einem kleinen Team benennst du mindestens zwei Personen, die sich gegenseitig auffangen können.
Zeitanteil: ohne freigegebene Zeit bleibt es ein Wunsch
Das Playbook verlangt die Zustimmung des Managements auf allen Ebenen, damit das schlechteste Argument nicht mehr greift: „I had no time for security“. Als Größenordnung nennt es: 20 Prozent sollten für den Anfang reichen. Das OWASP-Kapitel führt dieselbe Zahl als Beispiel („such as 20% of their role“). Eine Herleitung steht in beiden Texten nicht. Empfehlung: Nimm die Zahl als Startwert zum Anpassen, nicht als Messwert. Bei Vollzeit sind 20 Prozent rechnerisch ein Tag pro Woche.
Der Guide erklärt, warum die Freigabe formal sein muss: Bei kollidierenden Prioritäten gewinnen formalisierte, und selbst die begeistertste Person setze Sicherheit kaum gegen die erwartete Arbeitslast durch. Empfehlung: Plane die Zeit als sichtbare Kapazität in der Sprintplanung ein.
Zum Betreuungsverhältnis nennen die Quellen zwei Zahlen: laut OWASP-Kapitel kann eine Person aus dem Sicherheitsteam fünf Champions unterstützen, laut Guide ist bei großen Organisationen etwa ein Champion je 25 Entwickler ein Beispiel. Keine der beiden Zahlen wird in den Texten hergeleitet.
Wirkung: woran du erkennst, dass es trägt
Miss vor dem Start, wo du stehst. Schon im ersten Schritt nennt das Kapitel, den aktuellen Sicherheitsstand als Ausgangswert zu erfassen, etwa durchgeführte Code-Reviews oder automatisierte Sicherheitstests.
Als Ziele nennt das Kapitel beispielhaft: einen Anteil kritischer und hoher Schwachstellen schließen, eine bestimmte Zahl von Threat-Modeling-Aktivitäten durchführen, Schulungsmodule abschließen. Der Guide ergänzt Stunden, die ein Champion für Sicherheit aufwendet, Trainingsziele, Treffen und den Rückgang des Sicherheitsrisikos. Er empfiehlt außerdem, die Wirkung des Programms zu messen und sichtbar zu machen.
In den gelesenen Passagen steht kein Wirkungsnachweis mit Zahlen. Sie nennen Messgrößen, keine gemessenen Ergebnisse. Empfehlung: Wähle wenige Größen und mische Aktivität mit Ergebnis. Die Zahl der Schulungen zeigt, dass die Rolle gelebt wird. Der Anteil geschlossener kritischer Befunde zeigt, ob sie etwas verändert.
Klein anfangen
Das OWASP-Kapitel nennt einen Proof of Concept mit ein oder zwei Champions als sinnvollen Start. Hat er sich bewährt, lässt sich das Programm auf alle Teams ausweiten. Das Playbook fasst den Aufbau in sechs Schritten zusammen: Teams erfassen, Rolle definieren, Champions nominieren, Kommunikationskanäle einrichten, Wissensbasis aufbauen, Interesse wach halten.
Empfehlung für den Einstieg: eine Liste der Teams mit ihren Technologien, eine einseitige Rollenbeschreibung und ein Gespräch mit der Leitung über die freigegebene Zeit.
Wo Unterstützung ansetzt
Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.
Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.
Hinterlasse einen Kommentar