Die Einstellung von Entwicklern zu Sicherheit verstehen

Sie tun es, weil sie es sollen

Am besten bewegen Sie Entwicklungsteams dazu, Sicherheit als festen Bestandteil ihrer Rolle und Ziele zu betrachten. So erhalten sie den Auftrag und die Möglichkeit, Sicherheit zu priorisieren. Bei diesem Modell ist eine klare Zuständigkeit wichtig, damit Teams nicht davon ausgehen, dass ein anderes Team die Verantwortung für die Sicherheit eines gemeinsam genutzten oder älteren Projekts übernommen hat.

Zu wissen, was zu tun ist, reicht nicht aus. Ebenso wichtig sind Prozesse, die Teams dabei unterstützen, ihre Sicherheitsziele zu erreichen. Dazu gehören beispielsweise Einblicke in Testergebnisse oder Erklärungen zu den zusätzlichen Angriffsflächen und Risiken, die entstehen, wenn ein Entwickler ein neues Feature schreibt. Die Übersichtlichkeit und Transparenz einer Scorecard können dazu beitragen, die nötige Verantwortlichkeit zu schaffen und sicherzustellen, dass einzelne Entwickler Sicherheitsaufgaben in ihren Workflow integrieren. Diese Methode eignet sich auch besonders für externe Teams, die oft zwischen Projekten wechseln und sich weniger mit einem Projekt verbunden fühlen oder dafür verantwortlich sind.

Sie tun es, weil sie es sollen

Das ist ein so guter Grund, dass wir ihn gleich zweimal nennen! Es gibt noch einen weiteren Antrieb dafür, dass Entwickler sichere Software entwickeln sollten: Es ist einfach das Richtige. Ein Teil Ihrer Entwickler legt Wert auf Sicherheit oder ist besonders stolz darauf und fühlt sich persönlich oder beruflich dafür verantwortlich, nachhaltig und sicher zu programmieren.

Machen Sie den sicheren Weg zum einfachen Weg (auch bekannt als „Paved Road“)

Jedes Hindernis, das Entwickler davon abhält, eine Sicherheitsaufgabe zu erledigen, kann dazu führen, dass sie die Aufgabe abbrechen. Das kann von mangelndem Verständnis über einen quälend langsamen Workflow bis hin zu einer überwältigenden Zahl von Problemen reichen, bei denen unklar ist, wo man anfangen soll. Damit Sicherheitspraktiken angenommen werden, muss sich Sicherheit problemlos in bestehende Workflows integrieren lassen.

Ein „Paved Road“-Ansatz fördert die Anwendung einheitlicher Praktiken und bietet hilfreiche Unterstützung sowie bewährte Best Practices. Außerdem lassen sich so präzise und aktuelle Dokumentationen und Empfehlungen erstellen, die andere regelmäßig wiederverwenden und aktualisieren können.

„Wir nennen dieses Konzept Paved Road. Sie können sich natürlich auch durchs Unterholz schlagen und durch den Wald gehen. Aber wenn es eine schöne, glatte Straße gibt, die Sie ans Ziel bringt, werden Sie wahrscheinlich diese nehmen.“

Jason Chan, VP Security bei Netflix, in The Secure Developer über Empathie für Entwickler

Überlegen Sie, was Entwickler brauchen, um voranzukommen. Scannen, Testen und Identifizieren von Problemen sind im Vergleich zu deren Behebung relativ einfache Schritte. Entwickler möchten nicht von zehn Sicherheitslücken in ihrem Dependency-Graph erfahren. Sie möchten wissen, ob ein kleines Upgrade einer Abhängigkeit die Probleme behebt, die ihre Veröffentlichung blockieren. Denken Sie also an Lösungen statt an Probleme – die Liste der Lösungen ist meist viel kürzer!

Berücksichtigen Sie auch genau, womit Entwickler ihre Zeit verbringen möchten und wie sie Sicherheitsergebnisse und Maßnahmen nutzen wollen. Alles außerhalb ihres gewohnten Workflows lenkt ab und muss ihnen erst wieder einfallen. Integrationen in bestehende Workflows, die von Personen entwickelt wurden, die mit den vorhandenen Prozessen und der zugrunde liegenden Technologie vertraut sind, können für eine hervorragende Developer Experience sorgen. Achten Sie darauf, Ergebnisse nützlich, Feedback verständlich und umsetzbar sowie den Workflow schnell und reibungslos zu gestalten. Kurz gesagt: Gehen Sie bei der Umsetzung empathisch auf Ihre Entwickler ein.

Automatisieren, automatisieren, automatisieren

Die leistungsfähigsten DevOps-Pipelines sind umfassend automatisiert. In einer aktuellen Studie stellte Snyk fest, dass Automatisierung auch stark mit erfolgreichen Shift-Left-Sicherheitsprogrammen korreliert. Den Daten zufolge setzen Unternehmen mit vollständig automatisierten Deployment-Pipelines doppelt so häufig Tools für statische Anwendungssicherheitstests (SAST) und Software Composition Analysis (SCA) in ihrem SDLC ein. Außerdem beheben Unternehmen mit umfassender Automatisierung Sicherheitsprobleme mehr als viermal so häufig innerhalb eines Tages und mehr als doppelt so häufig innerhalb einer Woche.

Es ist klar: Je mehr wir automatisieren, desto mehr Tests können wir ausführen und desto mehr Probleme erkennen wir. Mit sorgfältiger Planung können wir Sicherheitsleitplanken und Richtlinien in unsere Pipelines einbauen, um Probleme sichtbar zu machen, die unsere Aufmerksamkeit und Maßnahmen erfordern. Das ist besonders sinnvoll, weil Entwickler bereits mit Automatisierungen für Aufgaben wie Integrationstests vertraut sind.

Darüber hinaus verringert die Automatisierung von Sicherheit auch die Reibung zwischen Sicherheits- und Entwicklungsteams. Denn dann weist ein Prozess – und nicht ein Team oder eine einzelne Person – auf ein zu behebendes Problem hin. So kann das Sicherheitsteam das Entwicklungsteam unterstützen und bei Problemen helfen, für die spezielles Fachwissen erforderlich ist, anstatt zum Engpass oder Überbringer schlechter Nachrichten zu werden.

„Ich würde sagen, sie sollten alle sinnvollen Sicherheitstools in ihre DevOps-Pipeline integrieren und automatisieren. Ich wünschte, wir hätten das früher getan, als wir es tatsächlich umgesetzt haben. Ein Entwickler muss so früh wie möglich automatisch über ein Problem im Code informiert werden. Wenn das schon beim Einchecken des Codes geschieht, versteht er es sofort. Oder ein Tool markiert beim Schreiben im IDE direkt ein Problem. Diese Automatisierung einzurichten, ist entscheidend. Ein Problem erst kurz vor der Veröffentlichung eines Produkts zu beheben, ist viel schwieriger.“

Ryan Ware, Security Architect und Leiter des Teams für Produktsicherheit und Sicherheitstools bei Intel

Schulungen und Wissen über sichere Entwicklung

Schulungen kommen bei Entwicklungsteams unterschiedlich gut an. Oft müssen Teams viele irrelevante Kurse und Materialien absolvieren und anschließend einen kurzen Test machen. Das Ergebnis landet vermutlich lediglich als Häkchen auf einer Checkliste zur Einhaltung von Schulungsanforderungen.

Wenn Schulungen einen relevanten Teil des Entwickleralltags bilden und dabei helfen, die Arbeit zu erledigen, einen Fehler zu beheben oder sicherer zu entwickeln, beschleunigt das die Einführung von Sicherheitspraktiken. Ein Kurs oder Schulungsmodul muss für Entwickler wertvoll sein, ihre Sicherheit verbessern und schnell Wirkung zeigen.

Überlegen Sie bei der Planung von Schulungen, wie sie Ihren Teams helfen, sich auf sichere Entwicklung zu konzentrieren. Welche Maßnahmen nehmen sie mit und setzen sie tatsächlich in ihren Prozessen oder Workflows um? Überlegen Sie, wie Sie Schulungen gezielt gestalten können, damit Ihre Teams genau dann relevante Unterstützung erhalten, wenn sie sie am dringendsten brauchen. Achten Sie darauf, dass Ihre Schulungen über technische Themen hinausgehen und auch Prozesse und Kultur behandeln.

Hier einige Tipps, wie Sie den größtmöglichen Nutzen aus Sicherheitsschulungen ziehen:

• Schulungen sollten so ansprechend sein, dass die Teilnehmenden sie machen möchten. Eine einfache Möglichkeit, die Qualität Ihrer Schulungen zu steigern: Führen Sie Pilotprogramme durch, holen Sie Feedback ein und passen Sie die Inhalte an, bevor Sie sie für alle bereitstellen.

• Bedenken Sie, dass sich die Angriffsflächen von Entwicklungsteams deutlich unterscheiden können, und bieten Sie entsprechend passende Lektionen an. Angriffe durch Directory Traversal betreffen beispielsweise möglicherweise eher Ihre Backend-Entwickler.

• Bei Schulungen zu Sicherheitslücken sollten Sie sich auf solche konzentrieren, die für das jeweilige Team relevant sind – abhängig von Programmiersprache, Framework, Bibliotheken usw. Berichte über Vorfälle bei anderen Unternehmen mit einem ähnlichen Technologie-Stack können das mögliche Ausmaß eines Schadens veranschaulichen.

• Es ist sinnvoll, reale Beispiele für Sicherheitsprobleme zu zeigen. Angst sollte jedoch nicht der wichtigste Anreiz sein. Kurzfristig können Sie damit vielleicht etwas erreichen, doch als langfristige Strategie eignet sie sich nicht. Eine Ausnahme sind wirklich erschreckende Sicherheitsprobleme – etwa solche, die ein Unternehmen ruinieren könnten!

• Nehmen Sie Schulungen in Scorecards auf, damit Teams für ihren Abschluss verantwortlich sind.

• Achten Sie darauf, dass Ihre Schulungen vermitteln, wie konkrete Angriffe verhindert werden können. Wenn Sie eine Sicherheitslücke erklären, zeigen Sie, wie sie ausgenutzt werden kann. Wenn Sie erläutern, wie ein Teil einer Pipeline abgesichert wird, erklären Sie, welche Angriffsfläche dadurch reduziert wird. Machen Sie es anschaulich und konkret.

• Stellen Sie sicher, dass es für alle Aufgaben, die Entwickler erledigen sollen, eine Dokumentation gibt. Lassen Sie Entwickler prüfen, ob die Dokumentation hilfreich ist – oder noch besser: Lassen Sie sie diese für den nächsten Entwickler oder das nächste Team selbst schreiben. Denken Sie daran: Dokumentation ersetzt keine Sicherheitsleitplanken, aber auch diese sollten Sie dokumentieren.

• Wenn ein Red Team einen Vorfall entdeckt, nutzen Sie ihn als Gelegenheit für relevante und praxisnahe Schulungen. Detaillierte Informationen zum Vorfall machen das reale Risiko greifbar. Binden Sie nach Möglichkeit das Red Team in eine Frage-und-Antwort-Runde ein.

Warum vermeiden Entwickler Sicherheit?

Wir haben besprochen, warum Entwickler sich die Zeit nehmen, sichere Software zu entwickeln. Mindestens genauso wichtig ist jedoch, zu verstehen, warum sie sich dagegen sträuben und zusätzliche Schritte vermeiden, die sicherstellen sollen, dass sie sicheren Code liefern.

Reibung

Je nachdem, wie weit Ihre Teams bei der Einführung von Sicherheit sind und wie gut sie mit moderner Entwicklung vertraut sind, können die Hindernisse unterschiedlich ausfallen. Teams, die gerade erst mit Sicherheit beginnen, wehren sich häufig, wenn die Gründe und Vorteile von Prozessänderungen nicht klar kommuniziert werden. Der neue Prozess sollte die Entwicklungsteams und ihre Workflows möglichst wenig beeinträchtigen und ihre Bedürfnisse berücksichtigen. Um die Akzeptanz zu fördern, sollten Sie umfassend kommunizieren, Reibung durch die Integration in bestehende Prozesse minimieren und, wenn möglich, Tools zusammenführen, um die Komplexität zu verringern.

„Ich denke, eine unserer größten Herausforderungen war es, wichtige Stakeholder in der Technologieorganisation und Entwickler dafür zu sensibilisieren, wie wichtig und wertvoll Sicherheit ist. In einer idealen Welt wäre dieses Verständnis bereits vorhanden. Entwickler haben kaum einen Anreiz, etwas zu tun, wenn sie den Nutzen nicht erkennen. Das gilt ebenso für Product Owner, Entwicklungsmanager und sogar für Direktoren im Software Engineering. Wenn sie den Wert von Sicherheit nicht nachvollziehen können, gibt es für sie kaum einen Grund, [ihre Priorität gegenüber] der Entwicklung von Features höher einzustufen.“

Nicholas Vinson, DevSecOps Lead bei Pearson

Misstrauen

Damit Teams einen Prozess langfristig und nachhaltig befolgen, müssen Sie ihnen einen Mehrwert bieten und ihr Vertrauen erhalten oder gewinnen. Verlieren sie das Vertrauen in Daten, Tools oder Prozesse, werden sie diese als Hindernis betrachten und versuchen, sie zu umgehen. Wiederholt auftretende False Positives eines Tools oder Prozesses entmutigen oder verärgern Entwickler nicht nur: Sie ignorieren oder verwerfen dann auch eher Ergebnisse zu echten Sicherheitslücken oder Problemen, wenn sie den Daten nicht vertrauen.

Komplexität

Ebenso schaffen Tools, die bestehende Probleme komplizierter machen und nicht dabei helfen, eine Lösung zu finden oder anzubieten, nur zusätzliche Arbeit für Entwickler. Zu wissen, dass eine Sicherheitslücke existiert, ist nur der Anfang. Entwickler müssen noch herausfinden, auf welchen Wegen und an welchen Stellen die Sicherheitslücke in der Anwendung erreichbar ist – zum Beispiel über verschiedene Pfade im Dependency-Graph. Sie müssen sofort wissen, ob sich das Problem beheben lässt und, falls ja, wie. Entwickler wünschen sich intuitive und hilfreiche Tools, mit denen sie schnell Lösungen umsetzen können.

Zuständigkeit

Ein weiterer Grund dafür, dass eine Aufgabe vom Tisch einer Person verschwindet, ohne bei jemand anderem zu landen, ist die Zuständigkeit. Bei neuen Projekten oder Features ist oft klar geregelt, wer zuständig ist: Nur ein Team arbeitet an dem Code mit dem Problem. Doch was ist, wenn ein Teil der Anwendung ein gemeinsamer Dienst ist, den viele Teams nutzen und zu dem sie beitragen, für den sich aber niemand vollständig verantwortlich fühlt? Wer kümmert sich um einen Bug oder ein Sicherheitsproblem, das das eigene Team nicht direkt betrifft? Ein weiteres typisches Beispiel ist ein Container-Image, das viele verschiedene Teams verwenden. Wenn jedes Team damit beschäftigt ist, die eigenen Features bereitzustellen, bleiben Probleme in gemeinsam genutztem Code oft unbearbeitet.

Zeit

Selbst wenn die Zuständigkeit klar geregelt ist, bleibt natürlich die Herausforderung, Zeit zu finden, um Sicherheit in den Workflow zu integrieren. Selbst wenn die Automatisierung Ihren Code testet, ist das noch der einfache Teil. Die eigentliche Arbeit besteht darin, dass Entwicklerinnen und Entwickler die Ergebnisse auswerten und die Probleme beheben. Je häufiger die Tools falsche Ergebnisse liefern oder bei der Behebung keine konkreten Anweisungen geben und nicht autonom vorgehen, desto größer ist die Wahrscheinlichkeit, dass sie nicht mehr genutzt werden. Wenn das Unternehmen außerdem Sicherheitskorrekturen und -aktivitäten keine Priorität einräumt, werden Entwicklerinnen und Entwickler zurückhaltend reagieren oder Anfragen der Sicherheitsteams ignorieren, etwas zu testen oder zu beheben.

Rechenschaftspflicht

Rechenschaftspflicht ist eine wichtige Säule dafür, dass Entwicklerinnen und Entwickler Sicherheitsaufgaben übernehmen sollten. Doch wem gegenüber sie rechenschaftspflichtig sind, ist genauso wichtig. So wird eine Entwicklerin oder ein Entwickler Aufgaben wahrscheinlich eher erledigen, wenn das eigene Team, ein Security Champion im Team oder die Führungskraft dies einfordert. Wenn dagegen nur das Sicherheitsteam die Erledigung verlangt und keine klaren Konsequenzen folgen, fühlen sie sich weniger unter Druck, sicher zu entwickeln.

Fehlende Vorbilder

Menschen orientieren sich im Verhalten an ihrem Umfeld. Wenn wir nicht sehen, dass andere sicher entwickeln oder andere Teams Sicherheit bei ihren Projekten priorisieren, passen wir uns leicht an und ignorieren Sicherheitsaufgaben. Dem lässt sich auf verschiedene Weise entgegenwirken. So kann Sicherheit bei Code-Reviews stärker in den Fokus gerückt werden, indem Fragen zur Sicherheit gestellt werden, die zum Nachdenken anregen und das Thema ins Bewusstsein rücken. Eine weitere Möglichkeit: Schaffen Sie Vorbilder!

Würdigen Sie Menschen für Verhaltensweisen, die Sie sich in der Organisation häufiger wünschen. Heben Sie hervor, wo Teams besonders erfolgreich waren oder Fortschritte dabei gemacht haben, Sicherheit in ihre Pipeline zu integrieren oder ihren Sicherheits-Backlog abzubauen. Achten Sie darauf, dass Erfolge im Bereich Sicherheit sichtbar sind, von den Engineering-Führungsteams gewürdigt werden und sich mithilfe von Dokumentation, Automatisierung usw. von anderen wiederholen lassen.