Balanceakt: Sechs Schlüssel für eine erfolgreiche Zusammenarbeit zwischen Security- und Entwicklungsteams

Zwischen Cybersecurity-Teams und Entwicklerinnen und Entwicklern wird es immer eine natürliche Spannung geben. Schließlich besteht die Aufgabe der Entwicklung darin, Software zu entwickeln. Entwicklerinnen und Entwickler möchten neue Anwendungen und Funktionen erstellen und bereitstellen, die das Unternehmen voranbringen – und werden dafür bezahlt. Die Aufgabe der Security-Teams besteht hingegen darin, dafür zu sorgen, dass bei der Bereitstellung neuer Software nichts schiefgeht, etwa dass es zu einer Datenschutzverletzung kommt oder Business-Services aufgrund anfälliger Software nicht verfügbar sind.

Diese Dynamik sorgt zwar für eine natürliche Spannung zwischen den beiden Rollen, aber meiner Erfahrung nach muss das nicht so sein. Vorausgesetzt, es werden die richtigen Schritte unternommen, um das gegenseitige Verständnis der beiden Gruppen zu verbessern.

Leider unternehmen viele Unternehmen nicht die nötigen Schritte. Dadurch sehen Entwicklungsteams Security-Teams als „Blockade“, die es zu überwinden gilt. Gleichzeitig wächst der Unmut der Security-Teams gegenüber den Entwicklungsteams, weil sie den Eindruck haben, dass Entwicklerinnen und Entwickler „Security nicht ernst genug nehmen“.

Es wurde viel darüber geschrieben, wie sich die Beziehung zwischen Entwicklung und Security verbessern lässt. Im Laufe des letzten Jahrzehnts haben sich DevOps-Praktiken rasant verbreitet, die diese Spannungen abbauen sollen. Es gab einige Erfolge, aber meiner Meinung nach nicht genug. Deshalb möchte ich meine Erfahrungen teilen: Ich habe das Application-Security-Team eines großen Telekommunikationsunternehmens geleitet und dabei einige Erfolge erzielt, die Spannungen zwischen Entwicklung und Security auszubalancieren.

Jedes Unternehmen ist anders. Manche Entwicklungs- und Security-Teams arbeiten hauptsächlich vor Ort, andere überwiegend remote und wieder andere in einer Mischung aus beidem. Einige Teams verfügen über sehr erfahrene Application-Security-Expertinnen und -Experten, andere nicht. Mein Team arbeitete hauptsächlich vor Ort. Was für uns funktioniert hat, muss also nicht für alle funktionieren. Dennoch bin ich überzeugt: Wer diese Schlüssel berücksichtigt, verbessert die wichtige Beziehung zwischen den Security- und Entwicklungsteams.

Schlüssel Nummer eins: Schulungen in den Mittelpunkt stellen.

Unternehmen sollten neuen Entwicklerinnen und Entwicklern Application-Security-Schulungen anbieten, die vom AppSec-Team geleitet werden. Die Schulungen sollte eine Person mit ausreichender Entwicklungserfahrung durchführen, der die Entwicklerinnen und Entwickler vertrauen können. AppSec-Expertinnen und -Experten mit Entwicklungserfahrung verstehen die Herausforderungen und Frustrationen, mit denen Entwicklerinnen und Entwickler konfrontiert sind, wenn Security-Teams nicht optimal kommunizieren.

Das gilt grundsätzlich auch für das AppSec-Team. Wenn ein AppSec-Team ausschließlich aus Security-Fachleuten besteht, die nie in der Entwicklung gearbeitet haben, führt das wahrscheinlich zu Spannungen zwischen den Gruppen, weil sie vermutlich unterschiedliche „Sprachen“ sprechen. Keine der beiden Gruppen versteht dann die Probleme und Herausforderungen der anderen. Umfasst das AppSec-Team hingegen ehemalige Entwicklerinnen und Entwickler, verändert sich die Beziehung zwischen den Teams deutlich.

Schlüssel Nummer zwei: Verwenden Sie in AppSec-Schulungen Beispiele aus der Praxis, die die Entwicklungs- und Security-Teams intern gefunden haben.

In allen AppSec-Schulungen erklären die Schulenden, wie Schwachstellen in den Code gelangen, etwa durch Injection-Schwachstellen, Cross-Site-Scripting (XSS) und unzureichende Zugriffskontrollen. Außerdem erläutern sie, was diese Schwachstellen für die Sicherheit der Anwendung und der Daten bedeuten. Diese Darstellung mag zwar korrekt sein, ist aber auch sehr trocken.

Um für Abwechslung und Aufmerksamkeit zu sorgen, haben wir gute Erfahrungen damit gemacht, Application-Schwachstellen einzubeziehen, die das Security-Team bei internen Sicherheitsprüfungen gefunden hatte. Dabei geht es nicht darum, die AppSec-Schulung persönlich zu machen. Einzelne Entwicklerinnen und Entwickler sollten auf keinen Fall bloßgestellt werden.

Es geht darum, gemeinsam aus diesen Problemen zu lernen. Es geht darum zu zeigen, dass sich Entwicklerinnen und Entwickler auf die Geschäftslogik und die Funktionsweise der Anwendung konzentrieren, die sie entwickeln – nicht auf Security. Manchmal spielt Security für sie nur eine untergeordnete Rolle, und das ist nachvollziehbar. Mit einigen Beispielen für häufige, intern gefundene Schwachstellen, die die Sicherheit des Unternehmens beeinträchtigen, gewinnen Sie jedoch ihre Aufmerksamkeit und ihr Interesse.

Schlüssel Nummer drei: Nehmen Sie der Entdeckung von Schwachstellen ihr Stigma.

Zu Beginn unserer Präsentation zeigten wir eine Folie, die dabei half, das Stigma von Schwachstellen im eigenen Code abzubauen. Den Namen der Person hinter der Geschichte werde ich nicht nennen, aber die Folie handelte von einem bekannten Security-Experten. Er entwickelt Security-Software, die als Open Source veröffentlicht wird. In einer von ihm entwickelten und als Open Source veröffentlichten Software wurde eine Schwachstelle gefunden – und zwar eine sehr schwerwiegende.

Wenn diese Person Software mit schwerwiegenden Schwachstellen veröffentlichen kann, kann jeder Entwicklerin und jedem Entwickler derselbe Fehler unterlaufen. Mit der Folie wollten wir zeigen, dass Sicherheitslücken im Code normal sind – selbst bei Menschen mit viel Erfahrung im Bereich Application Security. Wichtig ist, sie zu finden und zu beheben.

Schlüssel Nummer vier: Vermitteln Sie die tatsächlichen Auswirkungen von Schwachstellen.

Wir präsentierten nicht nur Schwachstellen, die wir intern entdeckt hatten, sondern nutzten sie auch aus. Wir sollten den Entwicklerinnen und Entwicklern zeigen, wie sich eine Schwachstelle ausnutzen lässt und was ein Angreifer damit tun kann.

In einer der ersten Schulungen kommentierte eine Entwicklerin oder ein Entwickler XSS und behauptete, solche Schwachstellen könnten nicht besonders schädlich sein. Wir zeigten, was ein Angreifer mit einem XSS-Angriff erreichen kann, etwa sich als Opfer ausgeben, auf sensible Daten zugreifen, Sitzungen übernehmen, Tastatureingaben protokollieren, Malware verbreiten und vieles mehr.

Das war sehr aufschlussreich. Tatsächlich glaube ich, dass hier ein Problem von AppSec liegt: Wenn Entwicklerinnen und Entwickler die Auswirkungen von Schwachstellen nicht verstehen, sind sie nicht motiviert, diese zu beheben oder zu vermeiden. Es liegt in der menschlichen Natur, Risiken zu ignorieren, wenn man ihre Auswirkungen nicht versteht. Deshalb kann die Veranschaulichung des tatsächlichen Risikos so viel bewirken. Diese Inhalte in unsere Schulungen aufzunehmen, hat unsere Beziehung zu den Entwicklungsteams deutlich verbessert.

Schlüssel Nummer fünf: Security-Teams müssen wissen, was zumutbar ist.

Meiner Erfahrung nach entstehen Spannungen zwischen diesen beiden Teams oft dadurch, dass das Security-Team Aufgaben verlangt, deren Erledigung unzumutbar ist. In Schulungen sollte das Entwicklungsteam unbedingt erfahren, wie es am besten mit dem Security-Team zusammenarbeitet. Genauso wichtig ist es aber, dass das Security-Team darauf achtet, angemessene Anforderungen zu stellen.

Manchmal sind Anforderungen unzumutbar, weil das Security-Team die Behebung von Problemen verlangt, die gar keine tatsächlichen Probleme sind. Das geschieht, wenn ein Schwachstellen-Scanner eine nicht vorhandene Schwachstelle meldet oder ein tatsächliches Risiko aufzeigt. Das Security-Team leitet den Fund dann ungeprüft an die Entwicklung weiter, damit diese ihn behebt. Wenn das häufig passiert, werden die Entwicklerinnen und Entwickler frustriert sein und Sie ignorieren.

Auch bei ihren Erwartungen müssen Security-Teams realistisch bleiben. Dazu gehört, ausreichend Zeit für die Behebung von Schwachstellen einzuplanen – und bei komplexen Schwachstellen mehr Zeit einzuräumen.

Schlüssel Nummer sechs: Setzen Sie präzise Tools ein, die Entwicklerinnen und Entwickler stärken.

Die Auswahl präziser Assessment-Tools ist entscheidend. Sie erklären erkannte Probleme verständlich, stufen deren Schweregrad angemessen ein und geben Hinweise zur Behebung der Schwachstellen. So können Entwicklerinnen und Entwickler nachvollziehen, wie sie die jeweiligen Probleme angehen. Noch besser sind Tools, die speziell für die Entwicklung konzipiert wurden, denn damit können Entwicklerinnen und Entwickler eigenständig arbeiten.

Auch wenn es immer ein gewisses Maß an Spannungen zwischen Security- und Entwicklungsteams geben wird und Unternehmen kontinuierlich daran arbeiten müssen, diese abzubauen, haben wir festgestellt: Schon wenige einfache Schritte, die Verständnis und Einfühlungsvermögen zwischen den Teams fördern, tragen wesentlich dazu bei, ihre Beziehungen zu verbessern.

Mit der Snyk AI Trust Platform Entwicklung und Security für bessere Ergebnisse zusammenbringen

Die sechs oben beschriebenen Schlüssel sind grundlegende Prinzipien, um die Kluft zwischen Entwicklungs- und Security-Teams zu überbrücken. Sie sind keine bloßen Theorien, sondern praktische Schritte, die Empathie fördern, ein gemeinsames Verständnis schaffen und gegenseitigen Respekt stärken. Doch Prinzipien allein reichen nicht aus. Sie müssen durch Tools unterstützt werden, die diese Arbeitsweise in die Praxis umsetzen.

Wenn Ihre Tools für Entwicklerinnen und Entwickler entwickelt wurden, verschwindet die traditionelle Kluft zwischen schneller und sicherer Entwicklung. Security ist dann kein Gatekeeper mehr, sondern ein vertrauenswürdiger Partner für Innovation. Die Snyk AI Trust Platform schafft eine gemeinsame Grundlage, auf der beide Teams dieselbe Sprache sprechen und auf dasselbe Ziel hinarbeiten können: sichere, hochwertige Software schneller bereitzustellen.

Die Snyk AI Trust Platform wurde dafür entwickelt, Security nahtlos in den SDLC einzubetten und so die Ursachen für Spannungen direkt anzugehen. Sie stärkt Entwicklerinnen und Entwickler mit schnellen, präzisen und umsetzbaren Security-Informationen genau dort, wo sie arbeiten: in ihrer IDE, ihrem Repository und ihrer CI/CD-Pipeline.

Möchten Sie eine echte Partnerschaft zwischen Ihren Entwicklungs- und Security-Teams aufbauen? Buchen Sie eine Live-Demo und erfahren Sie, wie Sie Ihre Teams dabei unterstützen können, Security von Anfang an einzubauen.