Erfolg eines DevSecOps-Programms

Die Verbesserung sicherer Entwicklungsprozesse ist ein Weg, der Zeit braucht. Er beginnt damit, Transparenz über die bestehenden Sicherheitsprozesse und -praktiken der einzelnen Teams zu schaffen. Geschieht dies nicht einfühlsam, kann es als Reaktion auf vermeintliche Schwächen in der Entwicklung wahrgenommen werden. Wenn andere Schuldzuweisungen oder Bewertungen vermuten, reagieren sie leicht defensiv. Eine gute Möglichkeit, das zu vermeiden, ist, die Security-Champions zu bitten, eine Selbsteinschätzung zu den Prozessen und Praktiken ihres Teams auszufüllen. So bleibt genug Zeit zur Reflexion, ohne eine Dynamik von „wir gegen sie“ zu erzeugen. Die Selbsteinschätzung umfasst Fragen zu verschiedenen Sicherheitsverhaltensweisen, Testarten, Prozessen usw. Das Entwicklungsteam gibt dabei an, wie viel in den einzelnen Bereichen bereits umgesetzt wird. Teams konzentrieren sich häufig stärker auf bestimmte Bereiche als auf andere – das ist ganz normal.

Im nächsten Schritt geht es um Verbesserungen. Dabei kann das Sicherheitsteam die Entwicklungsteams unterstützen und begleiten. Ein gutes Beispiel für eine von Entwickler:innen vorangetriebene Verbesserung: Das Entwicklungsteam wurde gefragt, welche Punkte auf der Selbsteinschätzung es verbessern möchte. Es musste nur ein paar Punkte auswählen und angeben, bis wann ein Verbesserungsprozess umgesetzt werden sollte. Vielleicht möchte das Team einige Sicherheitsfragen in Code-Reviews einführen oder alle Schwachstellen mit hohem Schweregrad und einem CVSS-Score von mindestens 9,5 aus dem Backlog entfernen. Unabhängig vom Ziel ist wichtig, dass die Initiative von den Entwickler:innen ausgeht und ihnen gehört. Der Security Coach unterstützt die Security Champions bei der Umsetzung – ob sie Schulungen, Beratung, Änderungen an der Pipeline oder etwas anderes benötigen. So kann der Coach den Security Champions helfen, die gewünschten Änderungen im Team einzuführen.

Eine zentrale Voraussetzung dafür ist jedoch, dass der Erfolg – möglicherweise auch als formeller KPI – des Security Coachs vom Erfolg der Security Champions abhängt. Nur wenn die Security Champions ihr Ziel oder ihren Entwicklungsplan erreichen, ist auch der Security Coach erfolgreich. Dieses gemeinsame Erfolgsmaß unterstreicht das gemeinsame Ziel: sichere Softwareentwicklung, die beide Teams zusammen erreichen wollen.

Ein weiterer häufiger Schwerpunkt von Security-Champions-Programmen ist das Schwachstellenmanagement. Transparenz darüber, wo Schwachstellen vorhanden sind, ist wertvoll, denn sie zeigt die kritischen Bereiche Ihrer Anwendungen und Deployments deutlich auf. Bei größeren Projekten und Deployments kann die schiere Zahl der Schwachstellen, mit denen Entwickler:innen in ihren Projekt-Backlogs konfrontiert sind, jedoch schnell überwältigend werden. Sowohl die Entwicklungs- als auch die Sicherheitsorganisation können Schwachstellen priorisieren, aussortieren oder ignorieren – sowohl im Backlog als auch bei neu entdeckten Schwachstellen. Entwicklungsteams kennen Anwendungsabläufe, Architektur und Design deutlich besser als das Sicherheitsteam. Umgekehrt kennt das Sicherheitsteam Bedrohungen und Risiken besser als das Entwicklungsteam. Eine Zusammenarbeit mit offenen Kommunikationswegen – etwa über die Beziehung zwischen Security Champion und Coach – erleichtert solche Gespräche und Bewertungen und macht sie effizienter.

So starten und etablieren Sie ein Security-Champions-Programm

Denken Sie zunächst daran: Klarheit und Einfachheit sind sehr wichtig. Stellen Sie beim Start sicher, dass genügend Informationen darüber verfügbar sind, was das Security-Champions-Programm ist, welche Ziele es verfolgt und wie es von der Unternehmensführung unterstützt wird und warum es für das Unternehmen wichtig ist. Schreiben Sie die Informationen mit Blick auf Entwickler:innen und holen Sie beim Verfassen deren Feedback ein.

Die wichtigste Regel für die anfängliche Größe des Programms lautet: Führen Sie es nicht zu groß und zu schnell ein. Ermitteln Sie Best Practices, die speziell zu Ihrem Unternehmen und Ihren Teams passen und sich für die spätere Ausweitung eignen. Berücksichtigen Sie bei der Auswahl der Teams für die erste Einführungsphase, welche Teams in Ihrem Unternehmen folgende Kriterien erfüllen:

• Die wichtigsten Services, Anwendungen und Teams Ihres Unternehmens mit dem höchsten Risiko

• Teams, die bei Sicherheits- und Entwicklungspraktiken besonders weit fortgeschritten sind und sich an Veränderungen anpassen können

• Teams, deren Mitglieder bereits Beziehungen zum Sicherheitsteam haben

• Teams mit Mitgliedern, die sich für Sicherheit interessieren und offen dafür sind, Sicherheitsniveau und -hygiene ihres Teams zu verbessern.

Wenn Sie zunächst nur mit wenigen Teams starten, sinkt das Risiko, dass die Einführung scheitert. So können Sie sich bei Bedarf ausreichend Zeit für jedes Team nehmen. Bei der Ermittlung des Unterstützungsbedarfs der Teams können Sie auch nach gemeinsamen Problemen suchen, sofern diese bereits erkennbar sind. Wenn Sie das Programm beispielsweise in drei Teams einführen und alle drei mit Threat Modeling beginnen möchten, können Sie Erkenntnisse zwischen den Teams austauschen und sich auf weniger Aspekte konzentrieren.

Die Wahl des richtigen Security Coachs kann ebenso wichtig sein, denn diese Person ist die zentrale Anlaufstelle für die Entwicklungsteams. Eine gute kommunizierende Person, die idealerweise Erfahrung in der Softwareentwicklung hat und Verständnis für Entwickler:innen mitbringt, kann einen großen Unterschied machen.

Seien Sie zu Beginn großzügig mit Belohnungen und Anerkennung. Das motiviert die Beteiligten und weckt ihr Interesse daran, sich weiterzuentwickeln. Erstellen Sie außerdem frühzeitig einen Best-Practices-Leitfaden, den Sie später mit anderen Teams nutzen können. Aktualisieren Sie bei Bedarf auch die vorhandene Dokumentation und die Leitfäden, damit die nächsten Teams aktuelle und hilfreiche Informationen erhalten.

Wenn Sie das Programm auf weitere Unternehmensbereiche ausweiten, können Sie auch andere Gruppen aus verschiedenen Bereichen einbeziehen, um alle Bereiche Ihres Unternehmens besser abzubilden. Vielleicht empfiehlt sich eine Roadshow, um mehr darüber zu erfahren, welche weitere Unterstützung benötigt wird, und um die Erfolge der bereits beteiligten Teams vorzustellen. Wenn Sie diese Erfolge innerhalb des Programms teilen, können die Teams ihre Fortschritte vergleichen. Das kann einen freundschaftlichen Wettbewerb anstoßen, bei dem sich die Teams gegenseitig zu besseren Ergebnissen motivieren.

Wenn Sie das Programm auf ein Entwicklungsteam ausweiten, sollten Sie dessen Einsatz, neue Erkenntnisse und Verantwortungsbewusstsein belohnen – indem Sie ihm mehr Verantwortung übertragen! Das mag ungewöhnlich klingen, aber letztlich sollen Entwicklungsteams eigenständiger arbeiten können. Wenn sie zeigen, dass sie in der Lage und bereit sind, Verantwortung für Sicherheit zu übernehmen, geben Sie ihnen mehr Befugnisse und Entscheidungsfreiheit.

Akzeptanz bei Entwickler:innen gewinnen

Um die Akzeptanz Ihres Programms bei Entwickler:innen zu gewinnen, müssen Sie die Herausforderungen und Bedürfnisse der Entwicklungsorganisation verstehen. Unabhängig davon, ob Sie das Programm ausschließlich mit Freiwilligen, durch die Auswahl des Managements oder mit einer Kombination aus beidem aufbauen möchten: Sorgen Sie dafür, dass die Teilnehmenden aktiv mitwirken und das Programm mitgestalten.

Es ist wichtig, klar zu vermitteln, warum es das Programm gibt. Klar definierte Programmziele sowie eindeutige Rollen und Verantwortlichkeiten für die Entwicklungs- und Sicherheitsmitarbeitenden sorgen dafür, dass sich alle im Programm wohlfühlen und engagieren. Ein wichtiges Merkmal des Programms: Entwicklung und Sicherheit bilden ein Team, das gemeinsam sichere Anwendungen und sicheren Code entwickelt und bereitstellt. Gerade um Entwickler:innen für sichere Entwicklung zu gewinnen und zu begeistern, sollte diese weitgehend als Teil der Entwicklungsarbeit betrachtet werden.

Berücksichtigen Sie bei der Auswahl von Schulungsthemen, beim Zuweisen von Aufgaben an Entwickler:innen und sogar bei der Nachverfolgung von Tickets stets die Zielgruppe in der Entwicklung. Entwickler:innen interessieren sich oft eher für Best Practices als für grundlegende Informationen, die ihnen meist bereits bekannt sind. Inhalte müssen konkret, technisch und auf die Problemlösung ausgerichtet sein, damit sie wirksam sind.

Oft sind auch Details wichtig, etwa wo Kommunikation und Zusammenarbeit stattfinden. Wenn Sie beispielsweise ein Ticket für das Entwicklungsteam erstellen möchten, verwenden Sie dessen bevorzugtes Ticketsystem. Arbeitet das Team bereits mit Jira, erstellen Sie dort Jira-Tickets. Jedes zusätzliche Tool und jeder zusätzliche Service, den das Entwicklungsteam nutzen soll, kann eine weitere Hürde für die Teilnahme darstellen.

Wie bereits erwähnt, ist es ebenso wichtig, die individuellen Verantwortlichkeiten und Aufgaben der Security Champions klar zu definieren. Das ist einfacher, wenn es eine offizielle Rolle gibt, die festlegt, wie viel Zeit sie gezielt für Sicherheitsaktivitäten im Team aufwenden sollen. In jedem Fall genügt es, zwei oder drei Ziele und Aktivitäten zu nennen, an denen die Security Champions in den nächsten 3 bis 6 Monaten arbeiten sollen. So überfordern Sie sie nicht und lenken ihren Fokus auf die wichtigsten Aufgaben.

Wir haben bereits die Bedeutung von Belohnungen und Anerkennung angesprochen und einige Ideen dazu geteilt, wie sich der geschäftliche Wert dieser Aktivitäten vermitteln lässt. Erfolge zu feiern bedeutet nicht unbedingt, jemanden zu einer Konferenz zu schicken. Meist geht es darum, die Bemühungen einer Person hervorzuheben und sie so zu ermutigen, sich weiter einzubringen – indem Sie sich für sie einsetzen und sie unterstützen. Gleichzeitig motiviert dieses Verhalten andere, sich ebenfalls besonders zu engagieren, um die gleiche Anerkennung zu erhalten.

Woran erkennen Sie den Erfolg?

Erwarten Sie vor allem keine herausragenden Ergebnisse innerhalb weniger Wochen oder Monate. Der Grund für ein solches Programm ist, Entwicklungsprozesse und -praktiken zu verbessern, damit Sie Software sicher bereitstellen können. Dafür gibt es keine Lösung über Nacht. Und wenn Menschen ihre Arbeitsweise ändern sollen, dauert es noch länger. Realistische Zeitrahmen für Veränderungen und Erfolge sind wichtig, damit Entscheidungen richtig getroffen werden und nicht nur ein willkürliches Ziel erreicht wird.

Teilnahme

Eine wichtige Kennzahl für jedes Security-Champions-Programm ist die Akzeptanz. Wie bereits erwähnt, sollte die Teilnahme für alle Security Champions freiwillig sein. Zu den Erfolgsindikatoren zählen daher die Gesamtzahl der Security Champions, das Wachstum der Gruppe im Zeitverlauf und die Zahl derjenigen, die dem Programm treu bleiben.

Eine weitere aussagekräftige Kennzahl ist die Anzahl der Entwicklungsteams, die Ihre Sicherheitsorganisation über das Security-Champions-Programm erreicht, sowie der Anteil der Entwicklungsorganisation, den diese Teams ausmachen. Denken Sie daran: Zu schnelles Wachstum kann zum Scheitern führen. Setzen Sie sich daher erreichbare, organisch wachsende statt übermäßig ambitionierte Ziele.

Engagement

Als Nächstes sollten Sie das Engagement der Mitglieder messen. Es zeigt, ob das Programm und die Zusammenarbeit funktionieren. Nachzuverfolgen, ob Security Champions tatsächlich 10 bis 20 % ihrer Zeit für Sicherheitsaktivitäten aufwenden, ist schwierig und wahrscheinlich auch nicht sinnvoll. Vielmehr geht es darum, die Arbeit von Entwickler:innen im Sicherheitsbereich offiziell zu unterstützen und sie als Teil ihrer Tätigkeit statt als zusätzliche Aufgabe zu verankern, die sie vielleicht in ihrer Freizeit erledigen. Der Zeitaufwand ist außerdem nur ein Richtwert und schwankt je nach Bedarf von Woche zu Woche.

Eine bessere Kennzahl ist, woran die Security Champions mitwirken – von regelmäßigen Meetings bis hin zu Initiativen, die sie in ihren Teams leiten. Die Teilnahme an Meetings lässt sich einfach erfassen, indem Sie festhalten, wie viele Security Champions regelmäßig an monatlichen Gesprächen teilnehmen oder sich wöchentlich mit ihren Security Coachs austauschen. Diese Daten sollten nicht gegen die Security Champions verwendet werden. Nutzen Sie sie stattdessen, um die Inhalte und Aktivitäten des Programms zu verbessern und für die Security Champions relevanter und ansprechender zu gestalten.

Auswirkung

Wie bereits erwähnt, ist es wichtig, die Entwicklungsorganisation dazu zu befähigen, Verantwortung für Änderungen und Verbesserungen im eigenen Team zu übernehmen. Wie weit Sie dabei gehen möchten, entscheiden Sie selbst. Zu verstehen, welche Aufgaben das Team übernimmt, was es verbessert und was es abgeschlossen hat, ist jedoch ein aussagekräftiger Maßstab für die Wirkung des Programms.

Eine gute Möglichkeit, dies mithilfe der Scorecard-Methode zu erreichen, besteht darin, das Entwicklungsteam seine Praktiken und Prozesse selbst bewerten zu lassen. Zunächst: Wie viele Personen erstellen Scorecards für ihre Teams? Nachdem Sie mit ihnen daran gearbeitet haben, die größten Risiken, die schnellsten Abhilfemaßnahmen usw. zu erkennen: Haben sie einen Verbesserungsplan erstellt, für den sie selbst die Verantwortung übernehmen und den sie mit Unterstützung des Sicherheitsteams umsetzen? Und natürlich sollten Sie messen, wo die Teams im Vergleich zu ihren Plänen stehen. Die Fortschritte bei den Verbesserungen sollten als KPI erfasst werden, für den sowohl der Champion als auch der Coach Verantwortung übernehmen.

Fortschritt

Wie bereits erwähnt, unterscheiden sich die Lernangebote, die sich ein Champion und ein Entwickler wünschen, der sich weniger für Sicherheit interessiert. Das ist in Ordnung – trotzdem ist es sinnvoll, ihre Lernfortschritte zu messen und nachzuverfolgen. Sobald Sie entschieden haben, wie Sie die Weiterbildung gestalten möchten – intern, durch externe Zertifizierungen oder sogar anhand der aufgewendeten Stunden oder praktischer Sicherheitsarbeit –, nutzen Sie ein Modell mit Gürteln, Medaillen oder Zertifizierungen. So lässt sich zeigen, wie kompetent Ihre Teams insgesamt sind, und über mehrere Quartale hinweg können Verbesserungsziele festgelegt werden.

Dashboards

Der letzte Messbereich, der eher als indirekt beeinflusste Kennzahl betrachtet werden kann, sind die Dashboards zur Produktsicherheit. Sie zeigen Statistiken zu Schwachstellen, zur Anzahl der Tests, zur Akzeptanz in den Teams usw. Ohne Kontext geben diese Zahlen möglicherweise nicht die Qualität oder das Risiko eines Projekts wieder. Wenn ein Team beispielsweise mehr Tests durchführt als ein anderes, findet es wahrscheinlich auch mehr Schwachstellen, weil es einen besseren Überblick darüber hat, wo Probleme liegen. Das bedeutet nicht, dass das Risiko dieses Teams höher ist – auch wenn die Zahlen dies nahelegen.

Es ist sehr wertvoll, die Auswirkungen für jedes Team samt Kontext und Begründung aufzeigen zu können. Achten Sie beim Messen dieser Kennzahlen auch darauf, Prozesse und Praktiken zu erfassen, die sie beeinflussen. Wenn Ihr Team beispielsweise für jedes entwickelte Feature Bedrohungsmodelle erstellt, verringert das das Risiko des Projekts erheblich. Dies wirkt sich auf die Anzahl der während der Entwicklung gefundenen Schwachstellen aus. Dieser Kontext macht die Ergebnisse deutlich aussagekräftiger.