Ihre Entwickler stärken

Entwickler zu stärken bedeutet, ihnen den Freiraum zu geben, auf Grundlage verschiedener Informationen eigene Entscheidungen zu treffen, Sicherheitsprobleme selbst zu lösen und letztlich Verantwortung für die Sicherheit ihrer Anwendungen zu übernehmen. Stärkung erfordert Unterstützung. Sie wird von anderen Teams ermöglicht, gefördert und unterstützt. Beginnen wir mit der Unterstützung von oben, die erforderlich ist, damit Entwickler die nötige Zeit für die Bereitstellung sicheren Codes aufwenden können.

„Wenn Sie das Netflix-Kulturmemo auf der Website lesen, fällt vielen unter anderem die Diskussion über Freiheit und Verantwortung auf. Dieses Konzept prägt die Arbeitsweise der Entwicklungsorganisation. Interessant ist, dass wir als Menschen meist zuerst an die Freiheit denken. Wir sagen: ‚Oh, toll. Ich kann tun, was ich will. Und sicher muss ich für irgendetwas verantwortlich sein. Aber das klären wir schon.‘ In Wirklichkeit tragen Sie eine enorme Verantwortung, wenn Sie Software für ein Unternehmen wie Netflix entwickeln. Der Dienst darf nicht ausfallen, deshalb ist Zuverlässigkeit von zentraler Bedeutung. Er darf nicht gehackt werden, deshalb ist Sicherheit von zentraler Bedeutung. Als Entwickler müssen Sie also auch sehr verantwortungsbewusst handeln. Als Sicherheitsorganisation sahen wir unsere Aufgabe oft darin, das Unternehmen zu unterstützen und zu befähigen. Wir wollten den Softwareentwicklern im Unternehmen ermöglichen, sich auf die Bereiche zu konzentrieren, für die sie im Wesentlichen eingestellt worden waren. Wenn Sicherheit für ihre Arbeit jedoch wirklich, wirklich kritisch wurde, sollten sie sich an uns wenden können. Wo genau diese Grenze liegt, ist eine Ermessensfrage. Wenn die Sicherheitsabteilung und die Entwickler ein gutes Verhältnis haben, können sie das gemeinsam klären.“

Bryan Payne, CISO bei BetterUp, ehemaliger Engineering Director für Product & Application Security bei Netflix

Was motiviert Entwickler, Zeit in Sicherheit zu investieren?

Unabhängig davon, ob Entwickler Zeit in Sicherheit investieren möchten, muss ihnen diese Zeit eingeräumt werden – und zwar so, dass Sicherheit neben anderen funktionalen und nicht-funktionalen Ergebnissen priorisiert werden kann. Entwickler sollten anhand der geschäftlichen Anforderungen entscheiden können, wie viel Zeit sie in sichere Entwicklungspraktiken im Vergleich zu Zuverlässigkeit oder Skalierbarkeit investieren. Bei ihrer Jahresbeurteilung sollten sie darlegen können, was sie getan und erreicht haben, und dafür Unterstützung von ihrer Führungskraft erhalten. Es liegt an den Führungskräften, ihre Entscheidungen anschließend zu honorieren, damit Entwickler wissen, dass sie ihre Zeit sinnvoll eingesetzt haben. Ist das nicht der Fall, befähigt das Unternehmen sie nicht dazu, Zeit in sichere Entwicklung zu investieren.

Wer sollte die Sicherheitsprioritäten für Team und Unternehmen festlegen?

Letztlich muss die Initiative von ganz oben kommen: vom CEO. Wenn Sicherheit ein geschäftliches Anliegen ist, sollte sie auch für den CEO wichtig sein. Diese Priorität muss sich durch die gesamte Organisation ziehen: über CIO und CTO, die SVPs und VPs der Entwicklung, die Directors, Führungskräfte und Teamleitungen bis hin zu den Entwicklern, die Tests ausführen und Probleme beheben. Mit Unterstützung der Geschäftsführung können Teams einen Teil ihrer Sprints der technischen Gesundheit widmen, zu der auch Sicherheit gehört, statt sich ständig auf neue Funktionen konzentrieren zu müssen.

Wenn diese Unterstützung und Priorisierung nicht von oben kommt, ist es äußerst schwierig zu argumentieren, dass Sicherheitstests genauso wichtig oder sogar wichtiger sind als die nächste Funktion oder ein Kundenanliegen. Werden solche Maßnahmen als Extras betrachtet, die erst begründet werden müssen, lautet die Standardreaktion „nichts tun“, und Diskussionen beginnen mit „Warum?“ statt mit „Wie?“.

Das heißt nicht, dass CEO und Entwickler aus denselben unmittelbaren Gründen handeln. Entwickler sind stolz auf ihren Code. Sie möchten, dass er korrekt, schnell, zuverlässig und sicher ist. Dem CEO sind Marke und Geschäftsergebnis wichtig, und er macht sich Gedanken darüber, wie sehr ein Sicherheitsvorfall oder eine Datenpanne dem Unternehmen schaden könnte. Beides sind gute Gründe für Sicherheit. Dennoch hat ein Top-down-Ansatz bei der Einführung von Sicherheitsmaßnahmen mehr Wirkung, als sich allein darauf zu verlassen, dass Entwickler zusätzliche Aufgaben übernehmen.

„Die Unterstützung der Geschäftsführung kam bei uns vom CISO, der einen direkten Draht zum CTO hatte. Dadurch ging sie in der Technologieorganisation tatsächlich von oben nach unten. Von Anfang an waren das Verständnis für und die Notwendigkeit von Sicherheit vorhanden. Bei der Umsetzung ist man jedoch auf die Softwareentwicklungsorganisation und deren Führungskräfte angewiesen.“

Nicholas Vinson, DevSecOps Lead bei Pearson

Unterstützt Ihre Sicherheitsabteilung Ihre Entwickler?

Auch wenn das Entwicklungsteam dafür verantwortlich ist, seine Anwendungen und seinen Code abzusichern, braucht es dabei die Unterstützung der Sicherheitsabteilung. Bei der Zusammenarbeit wandelt sich deren Rolle: weg von der eines Auditors, der Tests durchführt und Ergebnisse liefert – und als Hindernis wahrgenommen wird – hin zu der eines Security-Engineering-Teams. Dieses unterstützt Entwickler dabei, Sicherheit in ihre Prozesse zu integrieren und zu automatisieren, und berät sie fachkundig zu den Bereichen mit dem höchsten Risiko und deren Priorisierung.

Die Sicherheitsabteilung kann Entwickler nicht dazu zwingen, Sicherheitsaufgaben gegenüber anderen Aufgaben zu priorisieren. Wie bereits erwähnt, gehört diese Entscheidung zu den allgemeinen Prioritäten des Entwicklungsteams und des Unternehmens. In der Vergangenheit wurden Sicherheitsabteilungen von Entwicklern oft als Hindernis wahrgenommen, weil sie Sicherheitsprüfungen erst spät im Entwicklungszyklus durchführten. Wenn Entwickler befähigt werden, ihren Code selbst zu prüfen, kann sich die Sicherheitsabteilung zurücknehmen. Sie kann Entwicklungsteams dann bei Ergebnissen unterstützen, für die Sicherheitsexpertise erforderlich ist, und so vom Hindernis zum Wegbereiter werden. Außerdem erhält die Sicherheitsabteilung dadurch Spielraum, gemeinsam mit Entwicklungsteams Security Champions zu finden und so weitere Möglichkeiten zur Zusammenarbeit zu schaffen.

Die Sicherheitsabteilung kann Entwicklungsteams außerdem über Arten von Schwachstellen und das Ausnutzungsrisiko informieren. Das lässt sich in formellen Security-Champions-Programmen umsetzen, in denen auch andere Aktivitäten wie die Einführung von Prozessen gut koordiniert werden können. Entwicklungsteams arbeiten zwar selbstständiger, doch braucht es weiterhin eine übergreifende Governance-Struktur und Transparenz, damit das Unternehmen seine Risiken und Gefährdungen versteht. Die Sicherheitsabteilung kann Teams Leitplanken und Richtlinien für Sicherheitstests bereitstellen, die sich in Pipelines und Praktiken integrieren lassen. So können Entwicklungsteams Probleme frühzeitig erkennen und ihre SLAs einhalten.

„Wenn ich an Security Champions und erfolgreiche Modelle denke, identifiziert man in den Entwicklungsteams mehrere Personen, die für Sicherheit verantwortlich sind. Man erstellt eine Scorecard, für deren Inhalte sie verantwortlich sind und die zeigt, was wir unternehmen, um unser Produkt oder unsere Funktion angemessen abzusichern. Entwickler können sich bei Bedarf an die zentrale Sicherheitsorganisation wenden, und wir stellen ihnen außerdem die neuesten und besten Schulungen zur Verfügung. Wenn die Sicherheitsabteilung für den Aufbau von Tools und Ähnlichem zuständig ist, treiben die Security Champions deren Einführung voran. Security Champions müssen also in den Entwicklungsorganisationen angesiedelt sein. Sie können nicht außerhalb davon sitzen. Sie treiben Sicherheit wirklich voran.“

Rinki Sethi, VP und CISO bei Bill.com

Ein weiterer wichtiger Faktor für die Einführung durch Entwickler ist die Dokumentation. Sie wird oft von Entwicklern verfasst und beschreibt deren Erfahrungen, gibt Anwendungshinweise, erläutert Entscheidungen und geht auf Besonderheiten ein. Die Sicherheitsabteilung kann dabei helfen, diese Dokumentation mit anderen Teams zu koordinieren und zu teilen, die ähnliche Praktiken, Prozesse oder Tools einführen, und auch an ihrer Erstellung mitwirken. Eine gute Self-Service-Erfahrung für das Entwicklungsteam – wie bei allen guten Entwickler-Tools – ist ein entscheidender Faktor für eine erfolgreiche Einführung.

Wie werden Sicherheitsregeln und Prozessentscheidungen in Entwicklungsabläufen getroffen?

Ein Maß für die Stärkung von Entwicklern ist, wie viel Einfluss und Gestaltungsspielraum sie bei ihren eigenen Prozessen und Pipeline-Tests haben. Bei der Festlegung von Sicherheitsregeln und -richtlinien ist es verständlich, dass die Sicherheitsabteilung diese mitgestaltet. Anschließend werden sie den Entwicklungsteams vorgestellt, die Empfehlungen dazu erhalten, wie sie sich in bestehende Prozesse integrieren lassen und wie eine wirksame Schulung eingeführt werden kann. Entscheidend ist, wie die Regeln ausgerollt und umgesetzt werden. Entwicklungsteams müssen Verantwortung übernehmen und ihre Workflows nach eigenen Vorstellungen gestalten und anpassen können. Das bedeutet nicht, dass jedes Entwicklungsteam alles individuell umsetzen sollte – schließlich müssen Teams voneinander lernen und Best Practices übernehmen. Entwicklungsteams brauchen jedoch den Freiraum, auf Grundlage der Beiträge anderer Entwicklungsteams und der Sicherheitsgruppe Entscheidungen zu treffen, damit die gewählte Lösung den Anforderungen und Standards der Sicherheitsabteilung entspricht.

Ein Vorteil dieses Ansatzes ist die Dynamik, die er ermöglicht. Wenn Sie einem Entwicklungsteam keine Praktiken oder Prozesse vorschreiben, können Sie als Sicherheitsexperte zunächst mit dem Entwicklungsteam zusammenarbeiten, um ein Sicherheitsproblem oder eine Anforderung zu lösen. So vermeiden Sie die natürliche Abwehrreaktion, die entsteht, wenn Außenstehende etwas vorgeben. Eine beratende Rolle der Sicherheitsabteilung bietet Unterstützung, die Entwicklungsteams oft eher annehmen, und hilft ihnen, die richtigen Entscheidungen zu treffen.

Letztlich geht es um die Frage der Verantwortung. Wenn Sie Ihre Sicherheitsabteilung für die Sicherheit des von Entwicklungsteams geschriebenen Codes verantwortlich machen, erwarten Sie, dass sie ihre Leistungen organisationsübergreifend in großem Umfang erbringt – und wahrscheinlich zum Engpass wird. Traditionell nimmt die Sicherheitsabteilung oft die Rolle einer Gruppe ein, die einer Entwicklungsorganisation Anforderungen auferlegt – häufig ohne entsprechendes Mandat, zumindest aus Sicht der Entwickler.

Wenn Sie Technologien oder einen Technologie-Stack einschränken müssen, den das Entwicklungsteam Ihrer Meinung nach verwenden sollte, ist es wichtig, eine gut ausgebaute Standardoption anzubieten. Sie sollte Entwicklungsteams mehrere Wege eröffnen, die von der Sicherheitsabteilung und anderen Teams gut unterstützt werden. Ein gängiges Beispiel sind geprüfte Golden Container Images, aus denen Entwickler auswählen und auf denen sie aufbauen können. Wenn Sie Optionen anbieten, die zugleich als empfohlener Weg dienen, werden Sie nicht als Hindernis wahrgenommen, während Sie den Teams helfen, sicher zu bleiben.

Transparenz und Überblick über alle Teams hinweg

Ein Überblick über den Sicherheitsstatus Ihrer Anwendungen, Pipelines und Prozesse ist der erste Schritt, um Risiken und Gefährdungen für Ihre Teams und Ihr Unternehmen zu erkennen. Werden die Erkenntnisse jedoch nicht genutzt, ist dieser Überblick wertlos. In dieser Studie haben wir festgestellt, dass die regelmäßige Zusammenfassung des Sicherheitsstatus in Form einer Verantwortlichkeits-Scorecard oder eines Berichts ein entscheidender Faktor für die erfolgreiche Einführung durch Entwickler war.

Die Scorecards der Unternehmen mit der erfolgreichsten Einführung erfassten neben Sicherheit auch viele weitere Aspekte, darunter Funktionen, Zuverlässigkeit, Leistung und mehr. Sie wurden monatlich erstellt und enthielten operative Kennzahlen wie die Anzahl der Schwachstellen, die Nutzung von Sicherheitstools, Projekt-Testkennzahlen, den Schulungsstand und vieles mehr. Besonders wichtig war, dass die spezifischen Kennzahlen jeder Scorecard auf die Geschäftsziele abgestimmt waren. Sehen wir uns genauer an, wie diese Scorecards genutzt wurden.

Priorisierung und Begründung

Mit einer Scorecard, die auch Geschäftskennzahlen wie Sicherheit berücksichtigt, lässt sich leicht erkennen, ob Sicherheit gerade das wichtigste Thema ist oder ob es anderswo größere Probleme gibt, die zuerst angegangen werden sollten. Es ist wichtig, mehr als nur die Sicherheit zu bewerten, denn fundierte Entscheidungen sind nur möglich, wenn Ihnen alle Daten vorliegen.

Scorecards sollten auf verschiedenen Ebenen erstellt werden, wobei die Daten auf die jeweilige Zielgruppe zugeschnitten sind. Führungskräfte benötigen beispielsweise weniger Details als Teamleiter und möchten zudem einen stärkeren Bezug zu den übergeordneten Geschäftszielen sehen. Anhand der Berichtsergebnisse können Führungsteams ihre Prioritäten anpassen und entscheiden, worauf das Unternehmen den Fokus richten sollte. Teams hingegen möchten wissen, wofür sie mehr Zeit aufwenden sollten und wie ihre Ergebnisse im Vergleich zum Rest des Unternehmens ausfallen.

All diese Daten helfen Entwicklern und Teams dabei, besser zu priorisieren, woran sie in den kommenden Sprints arbeiten müssen, und liefern zugleich die Begründung dafür. Wenn jemand fragt, warum ein bestimmter Schwerpunkt auf Sicherheit gelegt wird, ist es wichtig, eine objektive Scorecard statt einer subjektiven Erklärung vorlegen zu können.

Im Rahmen dieser Scorecards sollte das Sicherheitsteam dem Entwicklungsteam auch konkrete Empfehlungen zur Priorisierung geben. Es könnte beispielsweise eine Liste der wichtigsten Sicherheitslücken (oder Arten von Sicherheitslücken) hervorheben, auf die sich das Team konzentrieren sollte, um die größtmögliche Wirkung zu erzielen.

Verantwortlichkeit

Damit Sicherheit Priorität hat, muss es auf allen Ebenen Verantwortlichkeit geben. Der CTO ist dem CEO gegenüber verantwortlich, VP Engineering sind den CTOs gegenüber verantwortlich, Manager den VP Engineering gegenüber und so weiter bis hin zu den Engineers. Wenn alle einen Grund haben, sich für Sicherheit einzusetzen, wird sie zu einem festen Bestandteil jeder Rolle.

Glücklicherweise sind Scorecards eine einfache und effektive Möglichkeit, die richtigen Personen für die Einhaltung der an sie gestellten Standards zur Verantwortung zu ziehen. Durch die Veröffentlichung von Scorecards können alle im Unternehmen schnell erkennen, wo sie im roten Bereich liegen oder auf dem richtigen Weg sind. Werden festgelegte Schwellenwerte erreicht, können die für bestimmte Kennzahlen Verantwortlichen die Ursachen, Begründungen und möglichen Lösungen ermitteln.

Wie sich auch bei der Priorisierung von Sicherheit gezeigt hat, muss die Verantwortlichkeit für Sicherheit tatsächlich bis ganz nach oben reichen. Andernfalls wird die Botschaft, dass Sicherheit für das Unternehmen wichtig ist (und deshalb auch für das Entwicklungsteam wichtig sein sollte), stark verwässert und die Unterstützung geht verloren.

Setzen Sie auf die Werte von Entwicklern und Gamification

Entwicklern ist es normalerweise wichtig, Anwendungen bereitzustellen, die nicht nur funktionieren, sondern auch schnell, zuverlässig und sicher sind. Es gibt viele Faktoren, die Entwickler daran hindern können, Code nach ihren eigenen Standards bereitzustellen. Letztlich sind sie jedoch stolz auf ihre Arbeitsergebnisse. Scorecards eignen sich hervorragend, um diesen Anspruch, den bestmöglichen Code zu liefern, spielerisch zu fördern und Verantwortlichkeit vom Druckmittel zum Anreiz zu machen.

Wenn Ihre Entwicklungsteams den Status ihrer Projekte einsehen können, erkennen sie leichter, was gut läuft und sich verbessert und wo es Schwierigkeiten gibt oder sie zurückfallen. Der Stolz von Entwicklern und Entwicklungsteams kann leiden, wenn sie sehen, dass ihre Scorecard die schlechteste im Bereich oder deutlich unter dem Durchschnitt des Geschäftsbereichs oder des gesamten Unternehmens liegt. Sie werden den natürlichen Wunsch haben, das zu ändern – müssen aber erst einmal davon wissen.

Gamification funktioniert gut, wenn sie gut umgesetzt wird. Wie Sie dabei vorgehen, hängt weitgehend von Ihrer Unternehmenskultur ab. Doch wenn Sie Scorecards teamübergreifend teilen und Einblick in die Ergebnisse geben, entsteht ein spielerischer Wettbewerb. Niemand möchte das schlechteste Team sein. Außerdem sehen die Beteiligten gern, wie sich ihre Scorecard verbessert und über dem lokalen Durchschnitt liegt – oder sogar zu den besten im Bereich zählt. Ebenso wichtig ist es, Ideen und Erfolge durch Ankündigungen und Diskussionen zu teilen. Daraus entstehen neue Initiativen in Teams, die diese Ideen übernehmen oder in ihren Bereichen weiterentwickeln möchten.