SurveyMonkey spricht mit Snyk über Entwicklersicherheit in Zeiten rasanten Wachstums

Viele Unternehmen verlassen sich auf CISOs oder Compliance-Teams, um die Sicherheit während der Softwareentwicklung zu verwalten. Doch dadurch bleiben Sicherheitsaspekte meist von der Arbeit der Entwickler getrennt. CISOs können Entwicklern Sicherheitsaufgaben zuweisen. Wenn Entwickler Sicherheit jedoch nicht regelmäßig mitdenken, geraten diese Aufgaben möglicherweise in Vergessenheit. Eine Möglichkeit, diese Lücke zu schließen, besteht darin, eine Leitung für Security Engineering einzusetzen (ähnlich einem Security Champion) – also jemanden, der sich dafür einsetzt, Sicherheit in den gesamten Entwicklungsprozess zu integrieren.

Bei einer kürzlich stattgefundenen Diskussionsrunde sprach Simon Maple, Field CTO bei Snyk, mit Craik Pyke, Senior Director of Security, Cloud, and DataStores Engineering bei SurveyMonkey (heute Teil von Momentive). Sie diskutierten darüber, wie Tools für Transparenz sorgen und ein „Paved-Road“-Ansatz Entwickler dazu motiviert, sich in stark wachsenden Unternehmen auf Sicherheit zu konzentrieren. SurveyMonkey nutzt Snyk Open Source, Snyk Container und Snyk Code, um Sicherheit in den gesamten Entwicklungsprozess zu integrieren. Hier fassen wir das Gespräch zusammen.

Für Konsistenz und Transparenz sorgen

Als Craik bei SurveyMonkey anfing, setzte das Unternehmen auf eine Microservices-Architektur. Jedes Team war für seine eigenen Services zuständig – vom Design über die Entwicklung und Bereitstellung bis zum Support. Dadurch arbeiteten die Teams nach eigenem Ermessen: Jeder fügte seiner Pipeline Plugins hinzu und nutzte die bevorzugten Tools. Das erschwerte die Nachverfolgbarkeit. Es gab keine klare Übersicht darüber, woher Entwickler Container bezogen oder wie viele Abhängigkeiten sie hatten. In diesem Umfeld war Craiks größte Sorge der Umgang mit Open Source. Er fragte, ob sich die Lizenznutzung nachverfolgen oder eine verlässliche Zuordnungserklärung erstellen ließe. Doch da alles manuell verwaltet wurde, lautete die Antwort meistens: nein.

[Entwickler würden sagen]: „Ich habe 80.000 Abhängigkeiten in meinen Projekten. Woher soll ich wissen, was ich einbinde? Und muss ich all diese Lizenzen selbst nachschlagen?“ Genau da setzten wir an: Wir mussten Entwicklern helfen, Antworten auf diese Fragen zu finden – statt ihnen Dinge aufzuzwingen, nur weil es um Sicherheit ging.

Aus seiner Erfahrung wusste Craik, dass dies die erste Herausforderung war, die es zu bewältigen galt: Transparenz schaffen und Governance einführen. Zuvor hatte er bei einem Unternehmen gearbeitet, das Produkte schnell auf den Markt brachte. Doch die Möglichkeit, Paketversionen und die damit verbundenen Open-Source-Risiken zu verstehen, wurde erst angegangen, als ein Kunde danach fragte. Bei SurveyMonkey stellte Craik daher zunächst Konsistenz her, bevor er sich mit Transparenz befasste. Er wollte eine DevOps-Kultur schaffen, in der Entwickler die Entwicklung einer Pipeline einer dafür zuständigen Gruppe überlassen konnten. Als er die Mitarbeitenden für diese Idee gewonnen hatte, ließ sich problemlos eine zentrale Build-Pipeline einrichten. Der Weg zu diesem Build-Artefakt war der erste Schritt. Anschließend suchte er schnell nach Tools, die über die Pipeline hinaus Einblick in die Aktivitäten der Entwickler auf ihren Rechnern boten.

Bessere Tools und Daten bereitstellen

Entwickler finden gerne selbst Lösungen – sie binden alles ein, was sie brauchen, um ein Problem auf ihrem Rechner oder in ihrer IDE zu lösen. Craik wollte sichtbar machen und definieren, was Entwickler während der Prototyping-Phase einbinden. Dafür sollten sie Tools nutzen können, die die Vorgänge in der Build-Pipeline in ihrer IDE oder auf der Kommandozeile abbildeten.

Wie stellen wir Entwicklern gute Tools zur Verfügung, die auf ihren Rechnern genauso funktionieren wie in der Build-Pipeline? Das zu erkennen und bereitzustellen … war für Entwickler tatsächlich leicht anzunehmen, sobald sie wussten, dass die Tools die Pipeline abbildeten. Konsistenz ist entscheidend.

Außerdem wollte Craik Entwicklern aussagekräftige Daten bereitstellen. So sollten sie beispielsweise einfach feststellen können, ob ein Paket für ein Projekt geeignet ist oder ob sie nach einer Alternative suchen sollten. Am besten gelingt das mit Daten. Wenn Entwickler wissen, dass ihnen etwa Snyk Advisor zur Verfügung steht, und sie schnell Kennzahlen finden können – etwa zur Beliebtheit eines Pakets oder zu seinem jüngsten Problem –, verstehen sie die Zusammenhänge. Craik zufolge war dies einer der ausschlaggebenden Gründe für seine jetzige Position: verlässliche Daten in die Hände der Entwickler zu legen und ihnen dann zu vertrauen, die richtigen Entscheidungen zu treffen.

Einen klaren, sicheren Weg schaffen

Als Nächstes arbeitete Craik an einer gemeinsamen Build-Infrastruktur. Er verwendete ein zentrales Artefakt-Repository (in seinem Fall Artifactory, doch es gibt viele geeignete Lösungen). Das Hauptziel bestand darin, dass Entwickler Artefakte stets aus der Registry beziehen. In einem schnell wachsenden Unternehmen ist das ein entscheidender Schritt, denn mit einem wachsenden Entwicklerteam kann auch die Infrastruktur wachsen – und unkontrolliert größer werden. Craik wollte jedoch nicht, dass das Security-Team zum Hindernis wird. Es sagte zu den Entwicklern: „Richten Sie Ihre bevorzugte Konfigurationsdatei auf dieses Artefaktsystem aus. Wenn das Gewünschte noch nicht vorhanden ist, lädt das System es für Sie herunter. Es unterstützt Sie.“ Anfangs mussten sie die Entwickler erst dafür gewinnen, die Änderung vorzunehmen. Doch sobald alle ihre Artefakte über dieses zentrale Artefakt-Cluster bezogen, erhielten sie den nötigen Überblick darüber, was wann wohin gelangte – und welche Versionen verwendet wurden.

Craiks Team erlaubte Entwicklern durchaus, außerhalb ihrer Pipeline zu arbeiten – doch sobald sie einen PR einreichen wollten, schlug der Vorgang fehl. Die Build-Pipeline, die ihre Tests von GitHub ausführt, durfte nicht direkt aus dem Internet abrufen, sondern nur aus dem Artefakt-Repository. Wenn Entwickler sich also von Anfang an an das erwartete Vorgehen hielten und den Artefaktspeicher nutzten, gab es keine Probleme.

Wie gelang es, dass Entwickler Sicherheit nicht als Hindernis empfanden? Wir gingen freundlich vor und setzten durchgehend auf positive Anreize. Wir sagten: „Wenn Sie das zentrale Artefakt-Repository nutzen, müssen Sie sich keine Sorgen über schädliche Pakete oder problematische Lizenzen machen, denn wir können die Pakete beim Eingang scannen. So können wir sicherstellen, dass Sie nichts Falsches tun.“ Dadurch änderte sich die Sicht der Entwickler auf Sicherheit: Sie sahen das Security-Team nicht länger als Gegner, sondern als Anlaufstelle für Fragen und Antworten. Wir sind da, um zu helfen, nicht um zu behindern.

Security Champions: eine Initiative aus der Belegschaft

Während Craiks Team den klaren, sicheren Weg aufrechterhielt, entwickelten sich einige Entwickler bei SurveyMonkey nach und nach zu Security Champions. Erfahrenere Entwickler erklärten neuen Teammitgliedern das Artefakt-Repository, wie man Hinweise in PRs erkennt und an wen man sich mit Fragen wenden kann. Craik nennt das „die informelle Verlagerung des First-Level-Supports in die Entwicklerteams“. Er führte kein formelles Security-Champions-Programm ein, denn wer neu zum Team kam, eignete sich sicherheitsbewusstes Arbeiten einfach als Verhalten an.

Wenn Entwickler den Code selbst auf Sicherheitsprobleme prüfen, kann das Security-Team sie unterstützen und ihnen bei Bedarf helfen. Craik weist darauf hin, dass das Security-Team mit einem gut ausgebauten sicheren Entwicklungspfad und den passenden Tools – darunter Snyk-Tools, mit denen sich Schwachstellen leicht erkennen und beheben lassen – bei Bedarf Artefakte neu erstellen lassen kann, ohne die Entwickler damit zu belasten.

Die Daten aus unseren Tools und unserer Pipeline ermöglichen es Entwicklern tatsächlich, fundierte Entscheidungen zu treffen.

Verantwortung und Ziele gemeinsam tragen

In einer erfolgreichen Shift-Left-Kultur möchten Entwickler Sicherheitsanforderungen von Anfang an berücksichtigen. Die Validierung hilft ihnen, umsatzrelevante Aufgaben schneller abzuschließen. Das Security-Team sagt nicht zu den Entwicklern: „Sie müssen diese Schritte aus Sicherheitsgründen durchführen.“ Vielmehr kommen die Entwickler zum Security-Team und fragen: „Ich sehe ein Problem mit diesem Paket. Kann ich trotzdem fortfahren?“ Das Team bemüht sich außerdem um gemeinsame Verantwortung: Statt Schuldzuweisungen vorzunehmen, wenn eine Schwachstelle durchgerutscht ist, behebt es das Problem so schnell wie möglich und bespricht anschließend die Erkenntnisse daraus.

Entwickler zu unterstützen heißt auch, ihnen zu ermöglichen, sich gegenseitig zu helfen. Als Craiks Team Snyk zur Suche nach Schwachstellen einführte, machte es das Tool nicht zu einer blockierenden Prüfung in GitHub. Stattdessen konnten erfahrenere Entwickler jüngere Kolleginnen und Kollegen bei Code- und PR-Reviews unterstützen. Ein erfahrener Entwickler konnte beispielsweise sagen: „Das rote X bedeutet, dass ein Problem vorliegt. Ja, technisch können Sie den Code trotzdem zusammenführen, aber das ist die aktuelle Situation.“ Am ersten Tag gab es keine strikte Durchsetzung. Stattdessen entwickelte sich eine Kultur der Zusammenarbeit. Für SurveyMonkeys Teams war es am besten, die Snyk-Tools passend zu ihrem jeweiligen Reifegrad einzuführen.

Sehen Sie sich das vollständige Gespräch an, um weitere wertvolle Einblicke in die Sicherheit für Entwickler zu erhalten.