Einblicke aus dem Entwicklungsteam eines Finanzinstituts
In der modernen Softwareentwicklung stehen Unternehmen in vielen Branchen, insbesondere im Finanzsektor, vor einer gewaltigen Herausforderung: hohe Sicherheitsanforderungen, strikte Compliance-Vorgaben und gleichzeitig agile Entwicklungszyklen unter hohem Innovationsdruck. In diesem Spannungsfeld hilft eine entscheidende Rolle – der Security Champion, der Sicherheit und Entwicklung im Projektalltag miteinander verbindet.
In diesem Blogpost geht es um die Aufgaben von Martin Müller, seit sieben Jahren Security Champion bei einem Finanzinstitut in Deutschland. Er arbeitet dort übergreifend für agile Teams und hat die Aufgabe, IT-Sicherheit unmittelbar im Entwicklungsprozess zu verankern. Was diese Rolle konkret bedeutet, wie sie das Team und die Software nachhaltig verändert hat und welche Learnings sich daraus ziehen lassen, zeigt dieser Erfahrungsbericht.
Warum Security Champions entscheidend sind
Viele Banken bewegen sich heute zwischen Regulierung und Innovation. Themen wie DORA, KRITIS, Cloud-Migration oder API-First-Strategien stellen enorme Anforderungen an die Sicherheit digitaler Produkte. Zugleich müssen Entwickler:innen weiterhin schnell neue Features liefern, ohne dass Sicherheit zur Bremse wird.
Genau hier kommt der Security Champion ins Spiel. Er oder sie sorgt dafür, dass Security-by-Design konsequent umgesetzt wird – von der Architektur über das Coding bis zur Auslieferung. Ziel ist es, das notwendige Security-Know-how ins Team zu bringen, statt es zentral „außen vor“ zu halten.
In Martins Projekt bedeutete das:
Sicherheit als integralen Bestandteil der Softwarearchitektur zu etablieren,
eine Security-First-Mentalität im gesamten Team zu fördern und
die Entwickler:innen gleichzeitig von übermäßiger Compliance-Dokumentation zu entlasten.
Ein Balanceakt, der funktioniert, wenn die Rolle ein explizites Mandat und volle Unterstützung im Projekt besitzt.
Alltag eines Security Champions im Scrum-Team
Der Security Champion agiert als Brücke zwischen Konzern-IT-Security und Entwicklungsteam.
In der Praxis heißt das: kontinuierliche Abstimmung über Anforderungen, Maßnahmen und Dokumentationsstandards sowie die Integration zentraler Richtlinien in die Projektplanung. Besonders herausfordernd ist die Umsetzung von konzernweiten Vorgaben wie der EU-Verordnung DORA für digitale operationale Resilienz und NIS 2 zum Schutz von Netz- und Informationssystemen.
Parallel ist Martin Ansprechpartner für das SOC-Team. Er analysiert verdächtige Vorfälle, definiert neue Detection-Regeln für das Security Information & Event Management (SIEM) und leitet daraus Verbesserungen für Log- und Monitoring-Mechanismen ab.
Auch im täglichen Austausch mit anderen Rollen ist Sicherheit präsent:
Im Dienstleistermanagement definiert und prüft Martin Sicherheitsanforderungen für die Infrastruktur.
Für Businessanalyst:innen und Product Owner bewertet er fachliche Features auf Sicherheitsrisiken – etwa bei Änderungen an Autorisierungs- oder Rollenkonzepten.
Gemeinsam mit dem Team entwirft er technische Sicherheitsmaßnahmen, um fachliche Funktionen sicher umzusetzen.
Dadurch wird Sicherheit weder rein technisch noch rein organisatorisch betrachtet – sondern als integrierte Dimension jeder Entscheidung im Entwicklungsprozess.
Sicherheitsbewusstsein im Entwicklungsprozess
Ein Schlüssel zur erfolgreichen Integration von Security im Entwicklungsalltag liegt in der Risikobewertung der Arbeitspakete.
Martin etablierte dafür ein Risiko-Rating für User Stories in drei Stufen:
Niedriges Risiko: kosmetische Änderungen oder Anpassungen ohne sicherheitsrelevante Logik
Hohes Risiko: funktionale Änderungen, die indirekt Sicherheitsmechanismen berühren
Sehr hohes Risiko: alles rund um Authentifizierung, Autorisierung und Session Management
Dieses Rating entscheidet darüber, wie tief Security-Tests greifen müssen.
Bei Features mit hohem Risiko führt das Team manuelle Tests mit dem Zed Attack Proxy (ZAP) durch, um neue und veränderte Endpunkte gezielt auf Schwachstellen zu überprüfen.
Bei „sehr hohen“ Risiken werden zudem Secure Code Reviews von Martin durchgeführt – umgesetzt über Pull Requests, die vom Security Champion freigegeben werden.
Auch regelmäßige, externe Pentests sind fester Bestandteil des Entwicklungsprozesses. Als Security-Champion koordiniert Martin die Vorbereitung der externen Pentests, ebenso wie die Nachbereitung der Findings.
Die Kombination aus automatisierten Regressionstestläufen und zielgerichteten, manuellen Analysen schafft eine solide Basis, um die entwickelte Software sicher auszuliefern.
Security by Design in Architektur und Infrastruktur
Ein weiterer Schwerpunkt der Rolle ist die enge Zusammenarbeit mit Softwarearchitekt:innen im Unternehmen.
Hier geht es etwa darum, Richtlinien für die Auswahl neuer Software-Bibliotheken zu definieren, die die Freiheit der Teams beim Technologieeinsatz wahren und gleichzeitig Sicherheitsrisiken minimieren. Diese Richtlinien berücksichtigen Kriterien wie Aktualität, Anzahl der aktiven Maintainer, Stabilität, Reputation in der Community und bekannte Schwachstellen in den Dependencies. Damit vermeiden Teams die Integration wenig gepflegter oder potenziell unsicherer Dependencies.
Auch für die Umsetzung von fachlichen Anforderungen müssen architekturelle Lösungen gefunden werden. Ein Beispiel ist die Anforderung, bei besonders kritischen Aktionen im Portal – etwa die Freigabe sensibler Kundendaten oder Änderungen an Authentifizierungsinformationen – eine zusätzliche Multi-Faktor-Authentifizierung einzufordern. Dies galt es architekturell in die bestehende Microservice-Landschaft zu integrieren. Martin und die Architekt:innen entwickelten ein Konzept zur zusätzlichen Multi-Faktor-Authentifizierung, welche sich per Konfiguration für einzelne Microservice-Aufrufe aktivieren lässt und transparent für den eigentlichen fachlichen Aufruf ist.
Ein weiteres Element des „Security by Design“-Ansatzes ist das regelmäßige Threat Modeling nach STRIDE. So werden frühzeitig mögliche Bedrohungen, sowohl für die Portalsoftware selbst als auch für die Build- und Deployment-Infrastruktur systematisch identifiziert. So wurde bereits früh im Projekt die potentielle Möglichkeit der Manipulation von Buildartefakten als Bedrohung identifiziert. Als konkrete Sicherheitsmaßnahme führte das Team die Signatur der erstellten Artefakte in der Build Pipeline, sowie deren Prüfung vor Deployments ein – ein entscheidender Schritt, um Manipulationen an Buildartefakten zu verhindern.
Schwachstellenmanagement im Dev-Team
Zur laufenden Überwachung nutzt das Team ein einfaches, aber wirkungsvolles Schwachstellenmanagement-System. Basis ist Dependency Track, das Softwarekomponenten und deren Schwachstellen transparent macht. Über den Import von SBOMs (Software Bill of Materials) erhält das Team jederzeit einen Überblick über in Produktion verwendete Abhängigkeiten und kritische Schwachstellen. Zur weiteren Automatisierung kommen Tools wie Renovate und npm audit fix zum Einsatz, die Paketabhängigkeiten möglichst schnell und wo sinnvoll automatisiert aktualisieren. Um Probleme wie Dependency Confusion oder manipulierten Repositories zu adressieren wurde ein internes Repository als Proxy für öffentliche Repositories wie Maven Central oder NpmJS installiert. In diesem werden die Artefakte bereits vor dem erstmaligen Download auf bekannte Sicherheitslücken oder andere Probleme untersucht und der Download ggf. untersagt.
Das Ergebnis: Eine kontinuierliche, automatisierte Sicherheitsüberwachung, die nahtlos in den Entwicklungsalltag integriert ist.
Menschen & Kultur: Security First als Teamkompetenz
Neben Technik und Prozessen lebt IT-Sicherheit vor allem durch Menschen.
Als Trainer trug Martin sein Wissen in das Team, um Verständnis und Kompetenz im Bereich sicherer Softwareentwicklung zu fördern. Dazu gehören regelmäßige Schulungen zu Themen wie OWASP Top 10, sichere Authentifizierung und sichere Schnittstellen.
Der Effekt dieser strategischen Ausbildung zeigt sich deutlich:
Es wurden immer weniger Findings bei internen und externen Pentests gefunden
das Sicherheitsbewusstsein im gesamten Team ist deutlich gestiegen
Sicherheit wird zunehmend proaktiv statt reaktiv behandelt
das Team sieht Security nicht mehr als externe Auflage, sondern als Qualitätsmerkmal eigener Software.
Eine gute Basis, um langfristig eine Security-First-Mentalität in Organisationen zu etablieren.
Fazit und Handlungsempfehlungen
Das Beispiel dieses Finanzinstituts zeigt klar, dass Security Champions ein wichtiger Teil von Dev-Teams sind, um Wissen in das Team zu tragen, für IT-Sicherheit zu sensibilisieren und bei der Konzeption und Umsetzung von Sicherheitsmaßnahmen zu unterstützen. Sie schaffen Sichtbarkeit und sorgen dafür, dass Sicherheitsmaßnahmen früh – und damit kosteneffizient – umgesetzt werden.
Damit das erfolgreich funktioniert, braucht die Rolle:
Ein klares Mandat, um bei Sicherheitsrisiken einzugreifen – bis hin zur Freigabe-Blockade bei gravierenden Findings.
Explizite Ressourcen, damit Sicherheit nicht im Spannungsfeld zwischen Feature-Entwicklung und Zeitdruck untergeht.
Rückhalt durch das Management und gelebte Wertschätzung der sicherheitsrelevanten Arbeit.
In diesem Fall waren genau diese Dinge durch das Finanzinstitut gegeben. Das Thema Informationssicherheit hat dort einen sehr hohen Stellenwert und die Rolle des Security-Champions wurde explizit gefördert.
Die Bilanz nach mehreren Jahren Praxis zeigt eindrucksvoll:
Mit kontinuierlicher Security-Ausbildung, fortlaufenden Tests und einem klaren Verantwortungsrahmen lässt sich das Sicherheitsniveau einer Bankanwendung über die Zeit messbar erhöhen.
Wir unterstützen auch Sie gerne bei allen Bedarfen im Bereich der sicheren Softwareentwicklung – von der Architekturberatung über Security Champions bis hin zu Code Reviews und Penetrationstests.
