Snyk & Intuit im Roundtable: Silos aufbrechen und Security- und Entwickler-Communities einbinden

Ich habe kürzlich an einem Snyk-Roundtable mit Intuit teilgenommen. Die Diskussion war so spannend, dass ich einige Erkenntnisse und Highlights in diesem Beitrag teilen möchte – angefangen mit dieser großartigen künstlerischen Darstellung der Veranstaltung! Hier sind die wichtigsten Erkenntnisse im Überblick:

• Vermitteln Sie Entwicklern Security-Aufgaben als Möglichkeit, ihre Arbeit zu erleichtern, etwa indem sie Nacharbeit vermeiden.

• Sorgen Sie dafür, dass die Behebung von Problemen für Entwickler der Weg des geringsten Widerstands ist – mit Tools, die sie gerne nutzen.

• Versuchen Sie nicht, alle Entwickler zu Security-Experten zu machen. Konzentrieren Sie sich auf diejenigen, die mehr lernen möchten.

• Die Teilnahme an einem Champions-Programm sollte freiwillig sein. Belohnungen, Anerkennung und Vorteile sollten das organische Wachstum der Community fördern.

• Messen Sie Erfolge statt des Ausbleibens von Verstößen.

• Teilen Sie Erfolgsgeschichten von Teams, die gute Arbeit leisten, um weitere Erfolge anzustoßen.

Interessiert Entwickler Security überhaupt?

Die Diskussion begann mit der provokanten Aussage, dass Entwickler sich größtenteils nicht für Security interessieren. Security wird oft als zusätzliche Arbeit wahrgenommen, für die es nicht die Anerkennung gibt, die man beispielsweise für die Bereitstellung eines neuen Features erhält. Das bedeutet natürlich nicht, dass Entwickler nicht das Richtige tun möchten – meistens ist das durchaus der Fall. Doch wie können wir Security attraktiver machen?

Ein weiterer Faktor, der Entwickler von Security abschrecken kann, ist die verwendete Terminologie. Wenn undurchsichtige Begriffe wie SCA, SAST, DAST und RASP zum Einsatz kommen, die den meisten Entwicklern nichts sagen, kann das ihre Arbeit erschweren und für Verwirrung sorgen. Es ist wichtig, diese drei- und vierbuchstabigen Akronyme, die für das Security-Team sinnvoll sind, aufzuschlüsseln und für Entwickler verständlicher zu machen.

Wie können wir Security also für Entwickler attraktiver machen?

Hier einige Vorschläge, um Security für Entwickler zu verbessern:

• Stellen Sie die Informationen so dar, dass sie Entwicklern helfen, etwa indem Sie Nacharbeit vermeiden.

• Sorgen Sie dafür, dass die Behebung von Problemen der Weg des geringsten Widerstands ist.

• Wählen Sie Tools, die Entwickler gerne nutzen.

Nacharbeit vermeiden

Ein Vorschlag, der bei den Teilnehmenden am Tisch gut ankam, war, Security so zu vermitteln, dass sie Anklang findet. Jeder Entwickler hasst Nacharbeit. Wenn Security dazu beiträgt, Nacharbeit zu vermeiden, sprechen wir nicht mehr über Security, sondern darüber, bestimmte Aktivitäten frühzeitig durchzuführen, damit später weniger Aufwand für die Behebung von Security-Problemen anfällt.

Security zum Weg des geringsten Widerstands machen

Natürlich ist es sehr wichtig, Security-Probleme zu verhindern. Sie sind nicht nur kostspielig zu beheben, sondern werfen auch ein schlechtes Licht auf ein Projekt – etwas, das Entwickler vermeiden möchten. Um dem entgegenzuwirken, brauchen Sie verständliche Richtlinien und Transparenz, die in einen natürlichen Security-Feedbackkreislauf eingebettet sind. So können Entwickler Fehler leichter vermeiden. Bieten Sie ihnen einen Weg des geringsten Widerstands, der zur Behebung statt zur Vermeidung anregt.

Tools, bei denen Entwickler im Mittelpunkt stehen

Natürlich spielen auch Tools eine Rolle dabei, wie Entwickler Security-Probleme finden und beheben. Vlad Nikolov von Intuit betonte, wie wichtig es ist, Entwickler dazu zu ermutigen, eigene Security-Tools einzubringen. Menschen möchten mitwirken und Verantwortung übernehmen. Vlad erzählte, wie Snyk bei Intuit eingeführt wurde: Das Entwicklungsteam stellte es dem Security-Team als das Tool vor, das es nutzen wollte.

Wie können wir Entwickler besser weiterbilden?

Hier einige wichtige grundlegende Gedanken, die wir von Anfang an berücksichtigen sollten:

• Security wird an Schulen nicht als Teil der Softwareentwicklung gelehrt. Das stellt von Anfang an eine Hürde dar.

• Versuchen Sie nicht, alle Entwickler zu Experten zu machen. Konzentrieren Sie sich auf diejenigen, die mehr lernen möchten.

Security-Schulungen

Damit Security im Arbeitsalltag von Entwicklern einen festen Platz hat, muss sie sich natürlich in ihre Arbeitsabläufe und ihr Verständnis von Softwareentwicklung einfügen. Es wurde festgestellt, dass Entwickler während ihrer Ausbildung an Hochschulen und Universitäten häufig weder vom OWASP Top Ten noch von sicheren Entwicklungs- und Designprinzipien hören, während sie Softwareentwicklung lernen. Damit Security wirklich in den Softwareentwicklungsprozess integriert wird, muss sie gemeinsam mit Softwareentwicklung an Schulen vermittelt werden. So lernen Ingenieure, sicheres Programmieren als selbstverständlichen Teil der Softwareentwicklung zu verstehen.

Teams brauchen umfassendes Security-Know-how, nicht einzelne Experten

Haben wir diese Diskussion nicht damit begonnen, dass Entwickler sich nicht wirklich für Security interessieren? Wie stellen wir sicher, dass Entwicklungsteams gut über Security-Praktiken informiert sind und sich damit auskennen, wenn Security nicht immer im Vordergrund steht und sie nicht unbedingt mehr darüber lernen möchten? Entscheidend ist hier, wie tief das Security-Know-how der Entwicklungsteams reichen sollte. Entwickler müssen keine Security-Experten sein, sollten aber in verschiedenen Bereichen kompetent sein, zum Beispiel bei der Bedrohungsmodellierung. Wenn Entwickler sich fragen: „Was wäre, wenn?“, können sie die richtigen Abläufe durchdenken, um Security-Risiken zu verringern.

Neugier durch ein Security-Champions-Programm fördern

Zu diesem Thema habe ich zwei wichtige Erkenntnisse mitgenommen:

• Investieren Sie Zeit in Entwickler, die von Natur aus neugierig sind und mehr über Security lernen möchten.

• Die Teilnahme an einem Champions-Programm sollte freiwillig sein. Belohnungen, Anerkennung und Vorteile sollten das organische Wachstum der Community fördern.

Neugier in Fachwissen verwandeln

Wir müssen berücksichtigen, dass es verschiedene Arten von Entwicklern gibt: solche, die sich für Security interessieren und mit denen wir eng zusammenarbeiten möchten, und solche, die Security nur aus der Notwendigkeit heraus berücksichtigen. Letztere tun nur das Nötigste, um ihre Aufgaben zu erledigen. Deshalb sollten die Anforderungen an sie niedrig und der Security-Prozess einfach sein. Bei Entwicklern, die sich für Security interessieren, sollten wir dagegen diese Neugier fördern und nutzen – möglicherweise im Rahmen eines Security-Champions-Programms.

Security Champions sollten sich freiwillig engagieren

Die Gruppe war sich einig, dass die Teilnahme an einem Security-Champions-Programm freiwillig sein sollte. Aus Sicht eines Security-Teams ist ein solches Programm eine großartige Möglichkeit, engagierte Verbündete aus verschiedenen Entwicklungsteams zusammenzubringen. Erfolgreich umgesetzt, können nach und nach weitere Personen dazukommen – ebenfalls auf freiwilliger Basis –, wenn sie sehen, welche Vorteile, Belohnungen und Anerkennung die Teilnahme mit sich bringt.

Erfolge feiern und belohnen

Alle waren sich einig, dass es wichtig ist, Erfolge zu feiern und die Beteiligten zu belohnen. Hier einige Ideen, wie das gelingen kann:

• Messen Sie Erfolge statt des Ausbleibens von Verstößen.

• Teilen Sie Erfolgsgeschichten von Teams, die gute Arbeit leisten, um weitere Erfolge anzustoßen.

• Gehen Sie über operative Messwerte hinaus und feiern Sie Erfolge, etwa bei der Einführung von Prozessen und einer Security-Haltung.

Es lässt sich beobachten, dass die meisten Unternehmen die Security ihrer Projekte anhand von Verstößen messen, statt Erfolge zu betrachten. Das liegt vor allem daran, dass sich Verstöße über verschiedene Entwicklungsteams hinweg leichter kontinuierlich erfassen lassen. Dieser Ansatz konzentriert sich jedoch darauf, was bei den Projekten falsch läuft, statt auf das, was gut funktioniert. Wenn alles gut läuft, gibt es in den Entwicklungsteams kaum etwas hervorzuheben – außer dass weniger Probleme auftreten.

Stattdessen sollten wir darüber sprechen, wie oft Entwickler eine Schwachstelle gefunden und behoben haben, bevor sie zu einem Verstoß führt. Das ist ein aussagekräftiger Maßstab für ein erfolgreiches Security-Programm, dessen KPI sich an Maßnahmen orientiert, die die Security verbessern. Außerdem sollten diese Aktivitäten belohnt und spielerisch gestaltet werden, um die großartige Arbeit von Entwicklern und Teams an ihrer Security-Haltung anzuerkennen und andere dazu zu ermutigen, es ihnen gleichzutun.

Das ist leichter gesagt als getan. Es war zwar beruhigend zu hören, dass sich alle in dieser Einschätzung einig waren, doch konkrete Beispiele für eine solche Umsetzung gibt es bislang nur wenige. Einige der Teilnehmenden wollten konkrete Schritte angehen, etwa eine verständlichere Sprache zu verwenden, damit die Terminologie für Entwickler zugänglicher wird. Außerdem könnten Erfolgsgeschichten, Anerkennung und Beispiele von Entwicklern, die Schwachstellen besonders gut beheben, andere ermutigen, ihrem Beispiel zu folgen und ihr Verhalten stärker an Security auszurichten.

Ein Erfolg muss nicht immer anhand einer operativen Kennzahl gemessen werden. Er kann sich beispielsweise auch auf Security in Ihrer Pipeline oder Ihren Prozessen beziehen. Eine Idee war ein Bewertungssystem, das zeigt, wo Sie und Ihr Team aktuell in Sachen Security stehen und was Sie ändern und verbessern möchten. So lässt sich auch nachvollziehen, wo Personen und Teams angefangen haben und welche Fortschritte sie gemacht haben.

Wie lässt sich messen, dass ein Security-Problem nicht auftritt?

Bei KPIs und Messwerten kann man es leicht übertreiben. Eine wichtige Kennzahl, die wir erfassen möchten, ist das Ausbleiben von Security-Problemen. Um Nacharbeit in der Entwicklung zu vermeiden, müssen wir verstehen, was getan wurde, um sie zu verhindern. Die Erfassung von Security-Gewohnheiten gibt Aufschluss darüber, wie Probleme erkannt werden. Ermitteln Teams beispielsweise selbst, wo Security-Bedrohungen bestehen, etwa durch gute Praktiken bei der Bedrohungsmodellierung?

Um die Wirkung von Shift Left zu verstehen, sollten Sie am besten rechts beginnen. Letztendlich möchten wir eine sicherere Produktionsumgebung mit weniger Security-Risiken und Schwachstellen. Wenn wir links Prozesse und Gewohnheiten einführen, sollten die Messwerte und Zahlen rechts zurückgehen. So wird die Wirkung und der Erfolg der links eingeführten Maßnahmen sichtbar. Sehen Sie sich also Ihre Security-Kennzahlen an, setzen Sie auf Shift-Left-Security (mit Entwicklern im Mittelpunkt) und prüfen Sie anschließend erneut Ihre Kennzahlen. Erfahren Sie unter https://snyk.io/events/, wo Sie uns als Nächstes treffen können. Wenn Sie Einladungen zu kommenden interaktiven Roundtables erhalten möchten, wenden Sie sich für weitere Informationen an Ihre Snyk-Ansprechperson!