SurveyMonkey im Gespräch mit Snyk über die Rolle von Developer-First Security für Hypergrowth-Unternehmen

In punkto Sicherheit in der Software-Entwicklung sehen viele Unternehmen den CISO oder die Teams vom Compliance-Management in der Pflicht. Entwickler dagegen fungieren dabei zumeist eher als Randfiguren, die Security-Aufgaben zu erledigen haben, die ihnen quasi „von oben“ zugewiesen werden. Doch so erhalten Entwickler nur äußerst unregelmäßig Einblick in die Materie, entsprechend leichter wird also auch etwas übersehen. Abhilfe schaffen kann hier ein Security Engineering Lead oder eine ähnliche Rolle, die als Security Champion direkt im Dev-Team im Einsatz ist, um Security-Methodiken näher zu vermitteln und den Blick für die Thematik zu schärfen.

Snyk Field CTO Simon Maple hatte jüngst Gelegenheit, im Gespräch mit Craik Pyke, Senior Director Security, Cloud & DataStores Engineering bei SurveyMonkey (jetzt Teil von Momentive), zu eruieren, wie der Anbieter von Umfrage-Software diese Themen angeht. Neben dem Einsatz von Tools, die in punkto Security die nötige Visibility vermitteln, ging es dabei insbesondere auch darum, wie es dem Hypergrowth-Unternehmen gelang, Security nachhaltig in seine Dev-Prozesse zu tragen. Eine nicht unwesentliche Rolle spielten Snyk Open Source, Snyk Containerund Snyk Code, wie die nachfolgende Zusammenfassung des Gesprächs zeigt.

Konsistenz trifft auf Transparenz

Als Pyke seine Rolle bei SurveyMonkey antrat, setzte das Unternehmen methodisch auf eine Microservices-Architektur. Per se natürlich durchaus am Zahn der Zeit, doch die einzelnen Teams kümmerten sich allesamt nur um Design, Entwicklung, Deployment und Support der Services aus ihrem eigenen Verantwortungsbereich. So tat quasi jeder, was er wollte: Pipelines wurden fleißig um Plug-ins ergänzt und alle nutzten die Tools, die ihnen gerade gelegen kamen. Den Überblick zu behalten war hier also kaum möglich. Dies umso weniger angesichts dessen, dass nirgendwo klar festgehalten wurde, von welchen Quellen die Entwickler ihre Container bezogen oder wie viele Abhängigkeiten ihre Projekte aufwiesen. Entsprechend große Sorge bestand bei Pyke darum, wie es bei alldem um das Open-Source-Management bestellt war. Denn auf die Frage, ob sich die Lizenznutzung in irgendeiner Art würde nachvollziehen lassen oder eine zuverlässige Möglichkeit zur Ausarbeitung von Urhebervermerken bestünde, bekam er zumeist keine zufriedenstellende Antwort. Wie auch, wurde all dies doch nur manuell gehandhabt.

Von den Entwicklern bekam ich dann in etwa so etwas zu hören: „Ich habe um die 80.000 Abhängigkeiten in meinen Projekten. Wie bitte soll ich da noch durchblicken? Soll ich die ganzen Lizenzen jetzt etwa von Hand heraussuchen?“ Womit sie ja nicht Unrecht hatten. Ganz ohne irgendeine Art von Hilfestellung konnten wir ihnen das ja nicht einfach aufoktroyieren.

Was es hier brauchte, waren also zunächst einmal Strukturen für mehr Visibility und klare Governance. Das wusste Pyke nur zu gut aus der Erfahrung im Unternehmen vor seiner Rolle bei SurveyMonkey. Als oberstes Gebot galt dort eine möglichst schnelle Software Delivery. Mit Fragen zum Tracking von Paketversionen und den mit Open-Source-Tools verbundenen Risiken beschäftigte man sich dagegen erst, wenn Kunden danach fragten. Genau diesem Narrativ wollte Pyke bei SurveyMonkey ein Ende setzen, hier also direkt für die nötige Visibility sorgen. Bevor das überhaupt möglich war, brauchte es jedoch zunächst einmal Konsistenz in der Dev-Kultur des Unternehmens. Stichwort DevOps also: Entwickler sollten im Hinblick auf die Einrichtung ihrer Pipeline die Zügel aus der Hand geben und dies einer eigens dafür eingerichteten Arbeitsgruppe überlassen. Nachdem man die Betroffenen von den Vorteilen dieser Methodik überzeugt hatte, gestaltete sich die Umsetzung einer zentralen, konsistenten Dev-Pipeline erstaunlich einfach. Denn den ersten Schritt auf dem Weg dorthin – dass Entwickler sich perspektivisch nur noch auf ihr Build-Artefakt konzentrieren – hatte man damit geschafft. So dauerte es auch nicht lange, bis man sich dem Thema Visibility annehmen konnte. Dies nicht nur für die Pipeline selbst, sondern auch dafür, was sich auf den Systemen der Entwickler abspielte.

Bessere Datenqualität durch adäquates Tooling

Entwickler sind Pragmatiker: Gibt es etwas, mit dem sie ein Problem lösen können, fackeln sie nicht lange und binden es in ihre Systeme bzw. ihre IDE ein. In dieser Hinsicht galt es für Pyke daher nur, ihnen klar zu vermitteln, welche Tools sie künftig zu ihrem Vorteil einsetzen sollten. Zentral war dabei, dass diese in der Build-Pipeline genau das widerspiegelten, was die Entwickler in ihrer IDE oder CLI vorfanden.

Wir brauchten also Tools, die Entwicklern in ihren lokalen Dev-Systemen die gleiche UX boten wie in der Build-Pipeline. Nachdem wir diese gefunden hatten, war es nicht mehr allzu schwer, die Teams auch von ihrer Nutzung zu überzeugen. Der entscheidende Faktor liegt hier in der Konsistenz.

Daneben war es ein wichtiges Kriterium, dass die Entwickler zielführende Daten an die Hand bekamen. So sollten sie etwa direkt nachvollziehen können, ob ein bestimmtes Paket für ihr jeweiliges Projekt adäquat ist oder ob sie besser auf eine Alternative umschwenken sollten. Eben solche Daten konnte ihnen der Snyk Advisor liefern: Neben Metrics zum Paket ihrer Wahl können sie dort auch einsehen, wie weit es verbreitet ist und welche Probleme dafür bekannt sind. Das vermittelt ihnen ein Verständnis von der Komplexität der Thematik. Genau das war für Pyke auch mit am wichtigsten. Denn nur mit verlässlichen Daten würden die Entwickler auch in der Lage sein, eigenständig fundierte Entscheidungen zu treffen.

Klare Struktur als Wegbereiter

Im nächsten Schritt stand die Umsetzung einer konsistenten Build-Infrastruktur an. Hierzu implementierte Pyke mit Artifactory eine Lösung, mit der sich alle Build-Artefakte unter einem Repository vereinen lassen. So war es möglich, dass das Dev-Team Build-Artefakte von zentraler Stelle beziehen konnte – ein entscheidender Punkt, denn bei Hypergrowth-Unternehmen wie SurveyMonkey nimmt die Zahl der Entwickler oft schnell zu. In der Folge wächst logischerweise auch die Infrastruktur, allerdings allzu oft nicht klar reguliert oder kontrolliert. Eben das wollte Pyke verhindern, zugleich aber mit seinem Security-Team nicht zur Bremse werden. Pyke blickt zurück: „Wir erklärten den Entwicklern, dass sie in ihren Konfigurationsdateien einfach nur auf dieses System verweisen müssen. Ist das Benötigte dann gerade nicht darin vorhanden, besorgt es das System automatisch für sie. Wir machten es ihnen damit also tatsächlich leichter.“ Nach etwas Überzeugungsarbeit hatten sich die Dev-Teams dann auch mit dem System anfreunden können, und so bezogen sie Artefakte nur noch von dort. Und erhielten damit die nötige Visibility, um nachvollziehen zu können, was sie wann von wo bezogen hatten – echte Versionskontrolle also.

Dabei behielten die Entwickler durchaus die Freiheit, außerhalb ihrer Pipeline zu arbeiten. Dies jedoch nur bis zum Pull-Request, den Pyke und sein Team fehlschlagen ließen. Hierzu richteten sie eine Regel dazu ein, dass die Build-Pipeline, die ihre Tests von GitHub aus durchführt, keine Artefakte aus dem Internet beziehen darf, sondern nur aus dem hierfür eingerichteten Repository. Alles, was Entwickler tun mussten, war also, ihre Artefakte gemäß dieser Regel aus dem Repository und nicht von anderswo abzurufen.

Um hier nicht als Bremse für die Entwickler dazustehen, positionierten wir konsequent die Vorteile strategisch. Wir erklärten ihnen: „Bei den Artefakten aus diesem Repository braucht ihr euch um Schadpakete oder problematische Lizenzen keine Gedanken mehr machen. Um die dazu nötigen Scans haben wir uns schon gekümmert. Keine Mehrarbeit für euch also, und ihr seid immer auf der sicheren Seite.“ So wurden wir für die Entwickler von Gegenspielern zur nützlichen Anlaufstelle für wichtige Fragen. Und genau das wollen wir als Security-Team: helfen, nicht behindern.

Security Champions: Support von der Basis

Die Strategie von Pyke und seinem Team, nur minimal-invasiv im Hintergrund den Weg vorzugeben, hatte einen bedeutenden Effekt: Einige der Entwickler übernahmen zunehmend die Rolle von Security Champions: Als schon länger mit den Security-Konzepten Vertraute vermittelten sie Neuzugängen in ihren Teams, was es mit dem Artefakt-Repository auf sich hatte, wie sie Signale für potenzielle Probleme in Pull-Requests erkennen und an wen sie sich bei Fragen wenden konnten. Pyke beschreibt dies äußerst treffend als „Laissez-faire-Methode, First-Level-Support ins Dev-Team einzubringen“. Dabei hatte er gar kein formelles Programm für Security Champions aufgezogen. Vielmehr integrierten die Entwickler Security-Themen quasi von ganz allein in ihren Dev-Alltag.

So übernehmen sie nun die Funktion einer Kontrollinstanz für die Sicherheit ihres eigenen Codes, während das Security-Team als Enabler fungiert, der ihnen bei Bedarf stets zur Seite steht. Zentral hierfür waren Pyke zufolge zwei Faktoren: Die klare Struktur, mit der das Security-Team Entwicklern den Weg weist, und Tools wie etwa auch die von Snyk, mit denen Entwickler Schwachstellen auf einfache Weise erkennen und beseitigen können. Müssen er und sein Team in dieser Hinsicht eingreifen, können sie dank dieser Tools zudem auch Rebuilds betroffener Artefakte einleiten, ohne dass das Dev-Team damit behelligt wird.

Dank der Daten aus unseren Toolsets und Pipelines sind unsere Entwickler bestens aufgestellt, um eigenständig punktgenaue Entscheidungen zu treffen.

Geteilte Verantwortlichkeiten, gemeinsame Ziele

Entscheidend für die kulturelle Umsetzung des Shift Left bei SurveyMonkey außerdem: Man trug der Tatsache Rechnung, dass Entwickler Security ohne Umschweife angehen und direkt die Bestätigung erhalten möchten, dass sie die Anforderungen erfüllt haben. Denn so können sie verzögerungslos ihren eigentlichen Aufgabe nachgehen: Feature-Entwicklung und damit Value-Generierung. So erreichte Pyke, dass er und sein Team Entwickler gar nicht mehr explizit auf Security-Themen aufmerksam machen müssen. Denn die Entwickler kommen nun tatsächlich auf sie zu. So etwa, um sich bei Erkennung eines Problems in einem Paket zu erkundigen, wie sie damit verfahren sollen. Dieser Team Spirit findet sich zudem auch im Hinblick auf Verantwortlichkeiten wieder: Gelangt doch einmal eine Schwachstelle an den Kontrollen vorbei, hält man sich nicht mit Schuldzuweisungen auf. Vielmehr behebt man das Problem so schnell wie möglich und eruiert dann, welche Erkenntnisse man daraus ziehen kann.

Wichtig war außerdem, dass man es Entwicklern ermöglichte, sich gegenseitig zu unterstützen. So hatte man den Rollout von Snyk so angelegt, dass die Schwachstellen-Scans der Lösung den Build-Prozess in GitHub nicht blockierten. Stattdessen ließ man Entwickler, die mit der Materie bereits besser vertraut waren, die weniger Erfahrenen bei Reviews von Code- und Pull-Requests anleiten. Pyke dazu: „Neuzugänge bekommen etwa erläutert, wie die Angaben von Snyk bei Erkennung einer Schwachstelle zu deuten sind. Sie können den Code zwar noch immer ins Repository einspielen, allerdings mit entsprechenden Konsequenzen für die Sicherheit.“ Von Anfang an hatte man also darauf gesetzt, Entwicklern nicht etwa etwas aufzuzwingen, sondern eine Kultur des Austauschs und der engen Zusammenarbeit zu etablieren. Genau darin ließen sich die Tools von Snyk optimal einpassen – ein entscheidender Faktor für den Security-Erfolg bei SurveyMonkey.

Noch mehr spannende Insights zur Umsetzung von Dev-First Security bei SurveyMonkey erhalten Sie in der Aufzeichnung des Gesprächs.