Entwicklungsteams verstehen

Die Einführung eines funktionsübergreifenden Programms erfordert Empathie. Die Zusammenarbeit zwischen Sicherheits- und Entwicklungsteams scheitert häufig, weil ihre Perspektiven und Ziele so unterschiedlich sind. Beide Teams verfolgen vielleicht dasselbe Ziel – sichere Anwendungen –, doch ihre bevorzugten Arbeitsabläufe und Erfolgskriterien können sich stark unterscheiden. Zum Glück kann Empathie für gemeinsame Ausrichtung sorgen.

Damit neue Lösungen gut und ganz selbstverständlich angenommen werden, sollten Sie eine Kultur der Zusammenarbeit schaffen, in der Ihr Sicherheitsteam und Ihre Entwicklungsteams dieselbe Sprache sprechen und gemeinsam auf Ziele hinarbeiten. Das Sicherheitsteam ist nicht länger dazu da, die Engineering-Teams zu prüfen und ihnen zusätzliche Arbeit aufzubürden. Es soll Engineers unterstützen und ihnen dabei helfen, Sicherheitsprobleme so früh, schnell und effektiv wie möglich zu finden und zu beheben. Die Engineering-Teams sollten das Sicherheitsteam als Gruppe wahrnehmen, die sie dabei unterstützt. Wenn das nicht der Fall ist, sollten sie sich Hilfe holen.

Bei der Einführung eines modernen AppSec-Programms müssen alle, die mit den Entwicklungsteams zusammenarbeiten und sie unterstützen, die Probleme, Reibungspunkte und Frustrationen kennen, mit denen Entwicklerinnen und Entwickler derzeit konfrontiert sind. Erst wenn sie diese verstehen, können sie erkennen, wie sich Sicherheit in den Entwicklungsprozess integrieren lässt. Sehen wir uns genauer an, welche Bereiche Sie vor Beginn neuer Kooperationen bewerten und berücksichtigen sollten. Im Folgenden finden Sie einige Fragen, die Sie sich vor der Einführung stellen können.

„Sicherheit muss eine Partnerschaft sein. Ein wesentlicher Grund für viele unserer Sicherheitsvorfälle ist, dass wir den Gruppen, denen wir zum Erfolg verhelfen wollen, Vorschriften machen, statt wirklich mit ihnen zusammenzuarbeiten. Meine Aufgabe ist es, unsere Engineering-Teams bei Mandiant dabei zu unterstützen, schnell guten, sicheren und funktionalen Code zu entwickeln. Als Unternehmen müssen wir schnell vorankommen. Durch Partnerschaften können wir Lösungen entwickeln, die sowohl den geschäftlichen als auch den Sicherheitsanforderungen gerecht werden.“

Tim Crothers, SVP und Chief Security Officer bei Mandiant

Wie viel Empathie und Verständnis bringen Sie Ihren Entwicklungsteams entgegen?

Es ist entscheidend, zu verstehen, wie Ihre Entwicklungsteams arbeiten und Entscheidungen treffen. Wenn Sie ihre allgemeine Vorgehensweise und ihren Entwicklungsreifegrad kennen, können Sie realistische Erwartungen formulieren, herausfinden, wo und wie sich tatsächlich etwas ändern lässt, und sie bestmöglich unterstützen und befähigen. Ohne dieses Verständnis können Sie ihre Sichtweise nicht nachvollziehen. Das führt zu Reibung und verringert die Erfolgsaussichten. Denken Sie außerdem daran, dass die Antworten auf die folgenden Fragen zwischen Teams derselben Geschäftseinheit oder sogar Abteilung variieren können. Gehen Sie nicht von Annahmen über Entwicklungsteams aus, sondern berücksichtigen Sie, dass sich ihre Kultur und Vorgehensweise unterscheiden können.

Wie aufgeschlossen sind sie gegenüber Veränderungen?

Manche Entwicklungsteams interessieren sich für die neueste Technologie – manchmal sogar zu sehr – und probieren neue Tools, Technologien, Bibliotheken, Programmiermodelle und mehr aus, nur um auf dem neuesten Stand zu bleiben oder herauszufinden, ob es vielleicht eine bessere Lösung gibt. Andere Teams nehmen solche Änderungen nur vor, wenn es bereits einen konkreten Problempunkt gibt oder sie sicher sind, dass die Änderung ein Problem ihrer Anwendung behebt. Wieder andere vermeiden Veränderungen grundsätzlich und folgen dem Motto: „Wenn es nicht kaputt ist, reparier es nicht.“

Wenn Sie erkennen, wie bereit Ihre Entwicklungsteams sind, ihre Arbeitsweise zu ändern, können Sie besser entscheiden, wie Sie mit ihnen ein gemeinsames Ziel für Ihr AppSec-Programm finden. Wenn sie sich beispielsweise in der Vergangenheit gegen Tests in Git-Pull-Requests (PRs) gewehrt haben, sollten Sie nicht davon ausgehen, dass Sicherheitstests in ihren PRs besser ankommen als frühere Versuche.

Bei der Einschätzung von Reife und Anpassungsfähigkeit Ihrer Entwicklungsteams sollten Sie zwischen der Einführung neuer Technologien und der Übernahme neuer Prozesse unterscheiden. Weniger reife oder jüngere Unternehmen konzentrieren sich häufig stärker auf die Einführung neuer Technologien als auf die Standardisierung von Prozessen. Start-ups müssen beispielsweise schnell veröffentlichen, um als Erste auf dem Markt zu sein. Deshalb haben die Weiterentwicklung von Prozessen und Standards oft eine niedrigere Priorität. In dieser Phase ist es meist sehr schwierig, Sicherheitspraktiken einzuführen, die als Freigabekriterium dienen.

Wie klar sind Teams und Projekte definiert?

Ein wesentlicher Unterschied zwischen der Sicht des Sicherheitsteams und der der Entwicklerinnen und Entwickler betrifft die Zuständigkeit für Assets. Aus Sicht des Sicherheitsteams gehören den Engineering-Teams verschiedene Assets, von denen einige kritischer sind als andere. Aus Sicht der Entwicklung konzentriert sich jedes Team auf bestimmte Projekte oder Services, für die es verantwortlich ist. Es arbeitet außerdem an Projekten mit, die anderen Teams gehören, sowie an Projekten, die viele Teams nutzen und auf die sie angewiesen sind, für die es aber kein klar zuständiges Team gibt.

Vor diesem Hintergrund hängt der Erfolg davon, ein Entwicklungsteam für die Sicherheit seines Codes und seiner Projekte verantwortlich zu machen, davon ab, wem die einzelnen Projekte gehören. Je klarer der Zuständigkeitsbereich definiert ist, desto eher übernimmt ein Entwicklungsteam die Verantwortung für die Sicherheit des jeweiligen Projekts.

Auch das Alter eines Teams kann die Einführung beeinflussen. Im Idealfall lassen sich Standards und Prozesse von Anfang an in einem neuen Team verankern. Wahrscheinlicher ist jedoch, dass sich natürliche Umbrüche nutzen lassen. Wenn ein Team beispielsweise eine größere Veränderung erlebt, die nichts mit Ihrem Programm zu tun hat – etwa eine neue Führungskraft oder eine Neuaufstellung –, ist es eher bereit, im Rahmen der eigenen Arbeitsweise zusätzliche Entwicklungsstandards zu übernehmen.

Wie viel Kapazität hat Ihr Team derzeit?

Wie die meisten Teams sitzen Entwicklerinnen und Entwickler nicht untätig herum und warten auf neue Aufgaben. Sie entscheiden, was als Nächstes am wichtigsten ist, und wissen genau, dass sie ihre ständig wachsende To-do-Liste nicht vollständig abarbeiten können. Entwicklerinnen und Entwicklern oder Teams, deren Aufgabenliste ohnehin schon überquillt, einfach weitere Aufgaben aufzubürden, ist weder konstruktiv noch hilfreich. Besonders problematisch ist das bei unterbesetzten Teams, die sich von Sprint zu Sprint kämpfen und gleichzeitig versuchen, über Wasser zu bleiben.

„Uns ist bewusst, dass sie viele andere Aufgaben haben. Sie müssen Features und Produkte entwickeln und sich um die Performance und Zuverlässigkeit kümmern. Wir möchten ihnen die Beteiligung an Sicherheitsthemen so einfach wie möglich machen.“

Jason Chan, VP Security bei Netflix

Wie unterschiedlich sind die Kompetenzen der Teams in Ihrer Organisation?

Es lohnt sich, die Dynamik Ihrer Entwicklungsteams zu verstehen, weil jedes Team anders ist. Häufig gibt es einige wenige Teams, die eine Vorreiterrolle übernehmen und neue Technologien und Prozesse zuerst einführen. Die übrigen Teams ziehen mit der Zeit nach. Die breite Einführung geht zunächst meist langsam voran, nimmt aber Fahrt auf, sobald genügend Automatisierungen und Best Practices die Hürden für andere Teams senken. Natürlich dauert es viel länger, bis viele Teams eine Lösung übernehmen – wenn sie es überhaupt tun –, wenn die Hürden dafür nicht deutlich genug gesenkt werden. Bevor Sie die Einführung bei Entwicklerinnen und Entwicklern vorantreiben, müssen Sie wissen, bei wie vielen Teams die Hürden gesenkt werden müssen und welche Teams als Pilotgruppe Automatisierungen und Best Practices entwickeln können.

Ein Beispiel für die unterschiedlichen Kompetenzen von Teams ist ihre Bereitschaft, Integrationen einzurichten und Feedback zu erhalten. Reife Teams wünschen sich Feedback möglichst früh – in ihrer IDE, in automatisierten lokalen Build-Prozessen und in ihren Git-Repositories. Weniger reife Teams möchten vielleicht nur den CI-Prozess automatisieren und erhalten Feedback entsprechend spät, meist kurz vor der Bereitstellung in der Produktion. Diese beiden Teamtypen gemeinsam in dieselbe Einführungsgruppe aufzunehmen, wird wahrscheinlich nicht erfolgreich sein und die weniger reifen Teams vermutlich überfordern.

Unterschiede bei der Einführung gehen häufig auf die Komplexität und das Alter der Projekte zurück. Ein alter, komplexer Service, der nur noch gewartet und nicht aktiv weiterentwickelt wird, eignet sich beispielsweise nicht gut dafür, da Änderungen an Prozessen wahrscheinlich auf größeren Widerstand stoßen. Wenn Ihre Organisation außerdem durch Übernahmen gewachsen ist, müssen Sie mit unterschiedlichen Technologien, Pipelines und Unternehmenskulturen umgehen. Das verringert die Einheitlichkeit in der gesamten Organisation und erhöht das Risiko, dass Annahmen über die Teams falsch sind.

Wie integrieren Ihre Entwicklungsteams derzeit Sicherheitspraktiken in ihre Pipeline?

Nachdem Sie sich ein Bild von den Entwicklungsteams in Ihrer Organisation gemacht haben, sollten Sie herausfinden, welche Sicherheitspraktiken sie derzeit befolgen und wie sie diese umsetzen. So können Sie eine Ausgangsbasis für die nächsten Schritte festlegen. Entwicklungsteams beginnen oft mit einem zurückhaltenden Ansatz: Sie führen vielleicht regelmäßig Tests durch, die zunächst nur der Transparenz dienen, und integrieren sie, wo möglich, in die Pipeline. Anfangs gibt es wahrscheinlich keine blockierenden Maßnahmen oder Freigabekriterien. So können die Entwicklungsteams weiterhin in ihrem gewohnten Tempo veröffentlichen.

Halten Sie anschließend fest, welche Integrationen sie bevorzugen. Scannen oder testen sie beispielsweise in CI oder früher in PRs? Nutzen sie eine sofort einsatzbereite Integration oder haben sie eigene Skripte und Automatisierungen entwickelt, damit sie zu ihrer Pipeline oder ihrem Projekt passt? Testen sie in IDEs oder gehen sie eher reaktiv vor? Teams, die großen Wert auf Integration legen, übernehmen mit höherer Wahrscheinlichkeit eine integrierte Sicherheitslösung für Entwicklerinnen und Entwickler.

„Entscheidend ist aus meiner Sicht, die bevorzugte Vorgehensweise unserer Engineering-Teams zu verstehen. Welche Muster gibt es, damit wir gemeinsam Leitplanken statt Kontrollen einführen können? Wir möchten die Teams dabei unterstützen, ihre Ziele zu erreichen. Wir müssen sicherstellen, dass die von ihnen als sinnvoll erachteten Praktiken und Prozesse eingehalten werden. In der Regel erarbeiten wir sie gemeinsam. Vereinfacht gesagt suchen wir stets nach Lücken – in unseren Prozessen, in unserer [Zusammenarbeit].“

Tim Crothers, SVP und Chief Security Officer bei Mandiant

Welche Priorität hat Sicherheit während der Sprints?

Ein weiterer guter Indikator für den Stand eines Teams auf seinem Weg zu mehr Sicherheit ist, ob es sich eher auf die zukünftige Entwicklung oder auf den Backlog konzentriert. Backlogs können mit Tausenden von Problemen oder Schwachstellen schnell überwältigend groß werden, während ein neues Feature vielleicht nur wenige davon mit sich bringt. Wichtig ist auch zu verstehen, wie das Team Probleme priorisiert, um zu entscheiden, was wichtig oder notwendig zu beheben ist und wann und wie eskaliert werden sollte. Wenn ein Team OKRs für seinen Backlog festgelegt und Prozesse eingerichtet hat, die kontinuierliche Fortschritte ermöglichen, übernimmt es eher Tools, mit denen es dieses Ziel schneller erreicht.

Wie integrieren sie Sicherheitstests und Fehlerbehebungen in ihre Sprints? Müssen sie vor der Code-Auslieferung einen Sicherheitstest ohne Befunde bestehen oder nehmen sie Sicherheitsaufgaben in ihren Backlog für technische Schulden auf und verwenden alle paar Monate einen Sprint auf die Behebung? Letzteres ist bei weniger reifen Teams häufig der Fall. Es betrifft auch manche leistungsschwächeren Teams, die ihre Arbeit nicht innerhalb der Sprints bewältigen können. Bei diesen Teams gibt es oft ebenso spezielle Sprints für Skalierung, Performance oder Zuverlässigkeit – Bereiche, die mit Sicherheits-Sprints um Zeit konkurrieren.

Gibt es schließlich interne Dokumentationen dazu, wie das Team testet, oder SLAs, an denen es sich bei der Bearbeitung von Problemen orientiert? All das sind gute Fragen, die Ihnen nicht nur zeigen, wo das Team heute steht, sondern auch, was der nächste Schritt ist, damit das Testen für das Team einfacher wird und es sich auf die richtigen Dinge konzentrieren kann.