Einführung von Entwicklersicherheit in einem Unternehmen mit über 5.000 Ingenieuren

Große Ingenieurbüros glauben gerne, ihre größten Probleme seien technischer Natur. Wenn nur jemand das Budget für das neueste Tool bewilligen würde, wäre alles gelöst. In letzter Zeit setzt man vor allem darauf, dass „Vibe Coding“ – unterstützt durch die bevorzugte Variante eines LLM – die Wunderwaffe sei. Doch die Missstände in großen Organisationen sind selten technischer Natur. 

Meiner Erfahrung nach handelt es sich dabei um prozessbezogene Probleme, die sich an zwei unterschiedlichen Enden des Spektrums zeigen können. Auf der einen Seite stehen Teams, die in einer „Analyseparalyse“ gefangen sind und endlos zwischen Besprechungen, Überprüfungen und konsensorientierter Planung hin- und herpendeln, ohne nennenswerte Ergebnisse vorweisen zu können. Auf der anderen Seite stehen diejenigen, die „erst springen und dann schauen“ – mit einer Tendenz zur überstürzten Umsetzung, die aufgrund mangelnder Selbstreflexion zu vielen selbstverschuldeten Fehlern führt.

Etwa ab dem Zeitpunkt, an dem eine Organisation die Marke von 5.000 aktiven Committern überschreitet, verändert sich die Art der Sicherheitstransformation grundlegend. Die Tools sind nicht mehr der begrenzende Faktor. Das Budget ist nicht mehr der begrenzende Faktor. Selbst die Fachkräfte sind nicht mehr der begrenzende Faktor. Was nun knapp wird, ist die Abstimmung.

Tatsächlich verfügt ein Unternehmen, sobald es diese Größe erreicht hat, bereits über ein funktionierendes Sicherheitskonzept, eine festgelegte Risikotoleranz und eine Sicherheitsorganisation, die in etwa nach bekannten Personalquoten aufgebaut ist. Ein gängiges Muster ist ein Sicherheitsexperte pro 100 Ingenieure, was bedeutet, dass ein Unternehmen mit 5.000 Entwicklern wahrscheinlich über ein 50-köpfiges Sicherheitsteam verfügt , das täglich versucht, Tausende von Softwareentscheidungen zu beeinflussen. Die Frage ist nicht, ob es Sicherheit gibt. Die Frage ist, ob sie skalierbar ist.

Dieser Artikel beschreibt die Erkenntnisse, die bei der Einführung von Sicherheitsprogrammen für Entwickler in Unternehmen dieser Größenordnung gewonnen wurden, und erläutert, warum der Weg zum Erfolg ganz anders aussieht, als es die meisten CISOs erwarten.

Warum die Einführung von Sicherheitsmaßnahmen für Entwickler in großen Unternehmen scheitert

Die meisten Sicherheitsinitiativen scheitern aus einem überraschend einfachen Grund: Sie sind wie Software-Implementierungen konzipiert und nicht als kulturelle Veränderungen. Sicherheitsverantwortliche gehen oft von der Annahme aus, dass die richtige Kombination von Tools (z. B. SAST, SCA, container , secrets ) zu besseren Ergebnissen führt, wenn sie in ausreichendem Umfang eingesetzt wird. Doch die Einführung von Tools ist der einfache Teil.

Das Schwierige ist die Priorisierung innerhalb von Entwicklungsabteilungen. Entwickler haben bereits mehr Arbeit, als sie in einem Sprint bewältigen können. Produkttermine bestimmen die Priorisierung des Backlogs. Die Geschwindigkeit bei der Umsetzung neuer Funktionen ist sichtbar und wird belohnt. Sicherheitskorrekturen wirken oft abstrakt und von außen auferlegt. Wenn ein Sicherheitsprogramm in diesem Umfeld eingeführt wird, ist die Standardreaktion vorhersehbar: Es werden Sicherheitstickets erstellt, sie landen im Backlog und sammeln sich still und leise an.

Die Scanning-Abdeckung ändert nichts an dieser Tatsache. Je mehr Schwachstellen aufgedeckt werden, ohne dass klar ist, wer dafür verantwortlich ist, desto schlimmer wird die Situation sogar. Sicherheitsteams glauben oft, sie würden Risiken durch mehr Transparenz verringern, doch in der Praxis verstärken sie damit manchmal unkontrollierte Risiken. Denn jeder weiß, dass die Probleme existieren, aber niemand übernimmt wirklich die Verantwortung dafür.

​

Die unumgänglichen Herausforderungen, denen sich jedes Unternehmen mit mehr als 5.000 Ingenieuren stellen muss

Große Ingenieursunternehmen arbeiten unter einer Reihe struktureller Zwänge, mit denen kleinere Unternehmen selten konfrontiert sind. Erstens gibt es die Fragmentierung des Softwareentwicklungszyklus (SDLC). Ein Unternehmen mit Tausenden von Ingenieuren betreibt mit ziemlicher Sicherheit mehrere Entwicklungszyklen gleichzeitig. Einige Teams führen täglich Deployments durch. Andere tun dies vierteljährlich. Manche stützen sich auf vor einem Jahrzehnt entwickelte Altsysteme, an die sich niemand herantraut, aus Angst, dass diese komplett ausfallen und zu ihrem persönlichen Problem werden könnten. Zweitens gibt es die technologische Heterogenität. Eine typische Unternehmensumgebung kann Dutzende von Programmiersprachen, mehrere CI/CD-Systeme, verschiedene Infrastrukturplattformen und eine Mischung aus Cloud-nativen und Legacy-Workflows umfassen.

Sicherheitswerkzeuge, die in einer Umgebung reibungslos funktionieren, lassen sich in einer anderen Umgebung unter Umständen kaum einsetzen. Drittens sind die zentralen Durchsetzungsmöglichkeiten begrenzt, und es gibt kein einziges System, das den gesamten Umfang der Anwendungs- und Cloud-Angriffsfläche eines Unternehmens erfasst. 

Auch wenn der CISO formal dem CIO oder CTO unterstellt ist, haben Sicherheitsteams selten Einfluss auf die Prioritäten im Backlog der Produktentwicklungsteams. Sie können diese zwar beeinflussen, haben aber keine Entscheidungsgewalt darüber. Dies führt zu einem grundlegenden Spannungsverhältnis.

Und die gefährlichsten Sicherheitsprobleme sind oft diejenigen, die Änderungen an der Architektur, Aktualisierungen von Abhängigkeiten oder umfangreiche Umstrukturierungen erfordern. Genau diese Aufgaben meiden Entwickler instinktiv, da sie sich nicht nahtlos in die Planung von zweiwöchigen Sprints einfügen lassen.

Aufgaben, deren Aufwand auf über 13 Story-Punkte geschätzt wird, werden oft auf unbestimmte Zeit zurückgestellt. Dabei handelt es sich um Projekte, die sich als Tickets tarnen. Die Folge ist ein wachsender Rückstau an Sicherheitsaufgaben, deren Notwendigkeit zwar jeder rational versteht, für deren Priorisierung sich jedoch niemand befähigt oder motiviert fühlt.

​

Das oberste Ziel ist Eigenverantwortung, nicht Berichterstattung

Einer der häufigsten Fehler, den Sicherheitsverantwortliche begehen, ist die Annahme, dass die Abdeckung durch Tools gleichbedeutend mit Fortschritt ist. Der Einsatz von Scannern in jedem Repository mag zwar beeindruckende Dashboards liefern, doch ohne Eigenverantwortung werden diese Dashboards kaum mehr als Risikokataloge. Echter Fortschritt beginnt mit einer anderen Frage:

Wer ist für welche Reparaturen zuständig?

Skalierbare Sicherheitsprogramme beginnen damit, Einflussnehmer innerhalb der Entwicklungsorganisation zu identifizieren. Nicht die formellen Führungskräfte. Nicht die Architekten im Organigramm. Sondern die Entwickler, deren Meinungen das Verhalten der Entwickler tatsächlich prägen. Jede große Entwicklungsorganisation hat solche Personen. Das sind die Ingenieure und Entwickler, die die Unternehmenskultur prägen und die andere konsultieren, bevor sie architektonische Entscheidungen treffen. Ein überraschend wirksamer Ansatz ist ein „Training-of-Trainers“-Modell:

1. Ermitteln Sie 10 erfahrene Entwickler, die im gesamten Unternehmen hoch angesehen sind
2. Schulen Sie sie gründlich in sicheren Entwicklungspraktiken
3. Lassen Sie sie 100 Vorreiter im Bereich Technik ausbilden
4. Diese Champions beeinflussen ihre jeweiligen Teams, die jeweils aus 50 Entwicklern bestehen

Innerhalb weniger Wochen verbreiten sich Sicherheitspraktiken unter Tausenden von Ingenieuren, ohne dass das Sicherheitsteam jeden einzelnen direkt schulen muss. In großem Maßstab verbreitet sich der Einfluss durch die Glaubwürdigkeit unter Kollegen.

Wie CISOs Pilotteams auswählen (und warum die meisten Pilotprojekte irreführend sind)

Die meisten Sicherheitsprogramme in Unternehmen beginnen mit einem Pilotprojekt. Theoretisch ist das sinnvoll. Doch die Art und Weise, wie die Pilotprojekte ausgewählt werden, führt oft zu irreführenden Ergebnissen.

Sicherheitsverantwortliche entscheiden sich häufig für eine von zwei Arten von Teams:

1. Das erfahrenste Ingenieurteam
2. Das Team, das am meisten darauf brennt, mitzumachen

Beides führt zu künstlich positiven Ergebnissen. Leistungsstarke Teams achten bereits auf eine hohe technische Qualität. Ihre Abhängigkeitsaktualisierungen sind auf dem neuesten Stand. Ihre CI/CD-Pipelines sind modern. Ihre Architektur wird aktiv gepflegt. Der Einsatz von Sicherheitstools liefert dort zwar beeindruckende Kennzahlen, schafft aber auch die gefährliche Illusion, dass Rollouts reibungslos skalierbar sind. Die Realität zeigt sich erst später: wenn der Rollout auf veraltete Dienste, unterbesetzte Teams oder Systeme trifft, die seit Jahren nicht mehr nennenswert aktualisiert wurden.

Ein besserer Ansatz zur Pilotenauswahl berücksichtigt bewusst eine repräsentative Komplexität:

• Ein Altdienst
• Ein modernes, cloud-natives Team
• Eine Produktgruppe mit hohem Umsatz
• Eine sich langsam bewegende interne Plattform

Das Ziel eines Pilotprojekts ist es, Hindernisse frühzeitig zu erkennen.

Das vierstufige Einführungsmodell, das sich in großem Maßstab bewährt

Erfolgreiche Sicherheitsprogramme für Entwickler folgen in der Regel einem einheitlichen Einführungsmuster. Das geschieht selten bewusst, doch erfahrene CISOs kommen letztendlich auf dasselbe Modell zurück.

Phase 1: Sichtbarkeit ohne Durchsetzung

In der ersten Phase steht die Beobachtbarkeit im Vordergrund. Sicherheitswerkzeuge werden über Repositorys und die gesamte Infrastruktur hinweg eingesetzt, blockieren jedoch weder Builds noch Bereitstellungen. Festgestellte Probleme werden aufgedeckt, kategorisiert und analysiert. Diese Phase hilft Sicherheitsteams dabei, wichtige Fragen zu beantworten:

• Welche Schwachstellen treten am häufigsten auf?
• Welche Teams reagieren schnell?
• Welche Arten von Korrekturen verursachen die größten Reibungsverluste?

Betrachte es als eine Lernerfahrung.

​

Phase 2: Entwickelnde Rückkopplungsschleifen

Als Nächstes folgt die Einbindung der Entwickler. Die Ergebnisse werden so präsentiert, dass die Entwickler tatsächlich darauf reagieren können. Fehlalarme werden konsequent beseitigt. Die Dokumentation wird verbessert. Beispiele für Abhilfemaßnahmen werden ausgetauscht. In dieser Phase kommt auch die intrinsische Motivation ins Spiel. Entwickler reagieren selten positiv auf Vorschriften von oben. Auf Herausforderungen zur Problemlösung reagieren sie jedoch sehr wohl. Einige Unternehmen setzen bei der Fehlerbehebung erfolgreich auf Gamification und lassen Teams auf der Grundlage der Anzahl der pro Sprint behobenen Sicherheitsprobleme gegeneinander antreten. Wenn Ingenieure beginnen, Probleme freiwillig zu beheben, weiß man, dass das Programm zu greifen beginnt.

{{Falsch-Positive}}

Phase 3: Leitplanken und Richtlinien

Erst wenn die Entwickler dem System vertrauen, kommen Durchsetzungsmechanismen zum Einsatz. Diese nehmen in der Regel die Form von Sicherheitsvorkehrungen an. Beispiele hierfür sind:

• Behebung kritischer Sicherheitslücken in neuen Abhängigkeiten
• Verhindern, secrets in Repositorys gelangen
• Durchsetzung von Mindest-Patch-Ständen für Basis-Images

Der Schwerpunkt liegt weiterhin auf der Vermeidung neuer Risiken und nicht auf der Ahndung früherer Verfehlungen. Das „Warum“ muss neben dem „Was“ stehen, damit wir nicht einfach nur eine fortgeschrittene oder beschleunigte Version von „Whack-a-Mole“ mit Schwachstellen und Fehlkonfigurationen spielen.

​

Phase 4: Verantwortlichkeit der Führungskräfte

In der letzten Phase wird die Sichtbarkeit der Führung eingeführt. In den Dashboards der technischen Führungskräfte werden Kennzahlen angezeigt:

• Zeit bis zur Behebung
• Häufig auftretende Schwachstellenkategorien
• Entwicklungen beim Sicherheitsrückstand

An diesem Punkt wird Sicherheit zu einem festen Bestandteil der Diskussionen über die technische Leistungsfähigkeit. Und genau dann wird der kulturelle Wandel spürbar und nachhaltig.

Was man zu Beginn nicht durchsetzen sollte (und warum)

Der schnellste Weg, eine Sicherheitsmaßnahme zum Scheitern zu bringen, ist eine verfrühte Durchsetzung. Zu den häufigsten Fehlern in der Anfangsphase gehören:

• Die Blockierung basiert auf Schwellenwerten für die Anfälligkeit
• Festlegung einheitlicher Fristen für die Installation von Patches
• Durchsetzung globaler Richtlinien zur Schweregradbewertung

Diese Maßnahmen wirken zwar entschlossen, führen jedoch oft zu Gegenreaktionen. Wenn Entwickler plötzlich feststellen, dass ihre Bereitstellungen durch Tools blockiert werden, um die sie nicht gebeten haben, finden sie schnell Wege, diese zu umgehen. Sie deaktivieren Scanner und erstellen Abzweigungen der Pipelines. Sie ignorieren Warnmeldungen. Die Folge sind schlechtere Sicherheit und ein gestörtes Verhältnis zwischen den Entwickler- und Sicherheitsteams. Akzeptanz muss vor Durchsetzung kommen. Vertrauen muss vor Kontrolle kommen.

Die Kennzahlen, die auf eine echte Akzeptanz hindeuten

Sicherheits-Dashboards konzentrieren sich Sicherheits-Dashboards auf die falschen Kennzahlen. Die Anzahl der Schwachstellen, der durchgeführten Scans oder der analysierten Repositorys bietet zwar einen Überblick, sagt aber wenig über Verhaltensänderungen aus.

Zu den aussagekräftigeren Indikatoren gehören:

• Behebungsquote: Beheben Entwickler die festgestellten Mängel tatsächlich? Eine steigende Behebungsquote deutet in der Regel auf ein zunehmendes Engagement hin.
• Behebungszeit: Wie schnell werden Probleme mit hohem Schweregrad behoben? In Unternehmen mit einer soliden Sicherheitskultur unter den Entwicklern werden kritische Fehler oft innerhalb von Tagen und nicht erst nach Wochen behoben.
• Wiederkehrende Befunde: Treten dieselben Schwachstellen immer wieder auf? Wenn ja, liegt das Problem nicht in der Behebung. Es geht vielmehr um die Schulung der Entwickler oder um architektonische Muster.
• Anzeichen für nachlassendes Engagement: Die frühesten und wichtigsten Warnsignale für ein Scheitern sind, dass Entwickler das System vernachlässigen, Tickets ohne Korrekturen oder Verweise auf Code-Commits schließen, Beschwerden über Alarmmüdigkeit sowie ein plötzlicher Rückgang der Behebungsmaßnahmen.

​

Wenn die Einführung eines Sicherheitsprogramms scheitert

Selbst gut geplante Einführungen stoßen auf Turbulenzen. Erfahrene Sicherheitsverantwortliche erkennen die Warnsignale frühzeitig:

• Der Rückstand wächst schneller als die Fehlerbehebungen
• Ingenieure umgehen Scan-Tools
• Sicherheitsbeauftragte verlieren an Einfluss

In solchen Fällen neigt man oft dazu, die Kontrollen zu verschärfen, doch das ist fast immer der falsche Weg. Erfolgreiche CISOs halten stattdessen inne und stellen sich drei Fragen:

1. Werden hier zu viele Themen auf einmal angesprochen?
2. Erhalten Entwickler klare Anweisungen zur Fehlerbehebung?
3. Konzentrieren wir uns auf die Schwachstellen, die wirklich von Bedeutung sind?

Die letzte Frage führt zu einem der wichtigsten Grundsätze bei groß angelegten Sicherheitsprogrammen:

Hier gilt das Pareto-Prinzip: In den meisten Umgebungen sind etwa 20 % der Schwachstellen für 80 % des tatsächlichen Unternehmensrisikos verantwortlich. Sicherheitsprogramme, die sich auf diese besonders schwerwiegenden Probleme konzentrieren, senken das Risiko drastisch und minimieren gleichzeitig den Aufwand für die Entwickler. Programme, die versuchen, alles gleichzeitig zu beheben, brechen unter ihrem eigenen Gewicht zusammen.

Sicherheitsaspekte in den Softwareentwicklungszyklus integrieren

Ein langfristiges Sicherheitsprogramm für Entwickler verlagert den Fokus letztendlich auf die frühen Phasen des Entwicklungsprozesses. Anstatt auf Berichte über Sicherheitslücken zu reagieren, beginnen Unternehmen bereits in der Entwurfs- und Entwicklungsphase, diesen vorzubeugen.

Eines der wirksamsten Instrumente für diesen Wandel ist die Bedrohungsmodellierung. Viele Entwickler beschäftigen sich erst dann mit Sicherheit, wenn ein Scanner ein Problem meldet. Sie lernen die Regel, aber nicht die Gründe dafür. Die Bedrohungsmodellierung ändert diese Dynamik.

Es hilft Entwicklern zu verstehen:

• Warum Entscheidungen zum Session-Speicher wichtig sind
• Wie Authentifizierungsmuster Angriffsflächen schaffen
• Warum OWASP Top 10 Probleme immer wieder auf

Wenn Entwickler das „Warum“ verstehen, betrachten sie Sicherheitskorrekturen nicht mehr als externe Anforderungen, sondern beginnen, Systeme zu entwerfen, die diese Probleme von vornherein vermeiden. Die Zusammenarbeit von Nachwuchsentwicklern mit erfahrenen Ingenieuren beschleunigt diesen Lernprozess noch weiter. Erfahrene Entwickler geben ganz selbstverständlich Gewohnheiten wie eine konsequente Dokumentation, automatisierte Tests und eine sichere Infrastrukturkonfiguration weiter. Bei der Sicherheit geht es dann weniger um das Scannen von Code als vielmehr darum, wie Entwickler beim Schreiben denken.

Die eine Regel, die über den Erfolg in großem Maßstab entscheidet

Nachdem ich Dutzende von Sicherheitsprogrammen für Entwickler beobachtet habe, die entweder erfolgreich waren oder scheiterten, lässt sich feststellen, dass ein Grundsatz stets über den Erfolg entscheidet: Sicherheit muss die kognitive Belastung der Entwickler verringern, nicht erhöhen.

Wenn Tools einen erdrückenden Lärm verursachen, schalten sich Ingenieure ab. Wenn die Anweisungen zur Fehlerbehebung unklar sind, schieben Ingenieure die Behebung auf. Wenn Durchsetzungsmaßnahmen vor dem Aufbau von Vertrauen kommen, umgehen Ingenieure die Kontrollen. Aber wenn Sicherheitstools:

• konkrete Ergebnisse
• sinnvolle Risiken priorisieren
• in bestehende Arbeitsabläufe integrieren

Die Entwickler reagieren wie immer und lösen das Problem.

Und wenn genug von ihnen anfangen, das Problem zu lösen, geschieht etwas Bemerkenswertes: Sicherheit wird zur Gewohnheit.

Und in einer Organisation mit 5.000 Committern sind es letztlich die Gewohnheiten, die die Sicherheitslage des gesamten Unternehmens bestimmen.

​

Diese Erkenntnisse haben die Designphilosophie hinter modernen Sicherheitsplattformen für Entwickler maßgeblich beeinflusst, wie zum Beispiel Aikido. Ein System, das entwickelt wurde, um relevante Risiken aufzudecken und gleichzeitig die kognitive Belastung der Entwickler zu minimieren.

{{walkthrough}}