Mehr Sicherheit, bessere Developer-UX: Pinterest gelingt beides

Geht es um Open-Source-Abhängigkeiten und ihre Nutzung im Unternehmenskontext, steht immer auch die Frage nach ihrer Sicherheit im Raum. Sie zu gewährleisten erfordert neben Security-Tools, die bereits im Dev-Workflow greifen, auch ein System zur Behebung erkannter Schwachstellen nach Priorität. Eine enorme Herausforderung, denn dies muss in einer Weise umsetzbar sein, die keine Überlastung für die Entwickler-Teams bedeutet.

So auch bei der Social-Media-Plattform Pinterest. Wie es dort gelang, mit der Hilfe von Snyk Security-Methodiken praxistauglich in den Dev-Prozess zu bringen, darüber hat Snyk Field CTO Simon Maple mit Kalpesh Dharwadkar, Product Security Engineer bei Pinterest, gesprochen.

Visibility, Scans und Priorisierung als Kernanforderungen

Open-Source-Software bildet bei Pinterest einen ganz erheblichen Teil des Dev-Stacks, daher sind Schwachstellen in den zugrunde liegenden Bibliotheken ein besonderes Risiko für das Unternehmen. Als Kalpesh zu Pinterest zustieß, fand er allerdings einen Status quo vor, bei dem Visibility für Open-Source-Bibliotheken nur ad hoc via NPM-Audit möglich war. Alles andere als zentralisiert also, und auch nicht übergreifend für alle genutzten Bibliotheken. Deshalb entschieden sich Kalpesh und sein Team nach der Evaluierung diverser Alternativen schließlich für Snyk. Überzeugen konnte die Lösung nicht zuletzt auch aufgrund ihres starken Developer-Fokus und der breiten Unterstützung für sprachspezifische Repositories wie Bazel, das Pinterest im Build-Prozess nutzt. Seine zentralen Prioritäten im Security-Kontext beschreibt Kalpesh dabei wie folgt:

Insbesondere wichtig war es in dieser Hinsicht, uns Klarheit über anfällige Bibliotheken im gesamten Stack verschaffen, neben Scans auf Schwachstellen auch Fixing-Strategien für sie erhalten und diese zudem nach Prioritäten umsetzen zu können.

Zu sprechen kommt Kalpesh hier auch auf Jenkins, mit dem das Team Build-Prozesse löst. Scans führt es dabei über die Snyk CLI aus, die Ergebnisse lädt es dann in die Web-UI der Lösung hoch. Ziel ist es dabei, Visibility für sämtliche Abhängigkeiten in den Code-Repositories von Pinterest zu erhalten und erkannte Schwachstellen nach Priorität zu beheben. Als Referenz dient dabei das Common Vulnerability Scoring System (CVSS): Besteht danach für eine erkannte Schwachstelle ein Exploit, beurteilt das Team anhand der Informationen von Snyk den Schweregrad und darüber die Priorität zur Behebung.

Durchgängiges Security-Testing für die gesamte Dev-Pipeline

Gefragt, wie kompliziert es gewesen sei, Snyk durchgängig für Testing-Prozesse in die Dev-Pipeline zu implementieren, speziell in punkto Einarbeitung der Entwickler in das Tool, nannte Kalpesh eine so einfache wie pragmatische Lösung: Anfangs führte er den Scan innerhalb der Dev-Pipeline nur für den auf Jenkins gestützten Build-Prozess ein, statt Entwickler direkt mit der Konsole von Snyk zu konfrontieren. Weniger komplexe Problemstellungen behob er dabei selbst und ließ die Ergebnisse dann von den Tech-Leads und Projektverantwortlichen gegenprüfen. So wuchs zunehmend ihr Interesse daran, Fixes mithilfe der Snyk Tools selbst umzusetzen. Entsprechend nahm die Nutzung sukzessive immer weiter zu.

Effiziente Fixing-Priorisierung, effektive Log4Shell-Prävention

Spannend war im Gespräch freilich auch die Frage danach, wie Kalpesh den Schweregrad von Schwachstellen kategorisiert bzw. nach welchen Warnsignalen er beurteilt, welche die Entwickler-Teams mit höchster Priorität angehen müssen. Für ihn am wichtigsten ist dabei, ob für eine erkannte Schwachstelle bereits ein Exploit bekannt ist und ob der ihr zugehörige Service an das Internet angebunden ist. Werden diese Parameter erfüllt, wird der mit dem jeweiligen Service betraute Entwickler bzw. Service Owner über ein Ticket mit der Behebung beauftragt. Die Meinung zur Behebung der jeweiligen Schwachstelle der Entwickler wird dabei mit der von Kalpeshs Team abgeglichen.

Möglich wäre, dass ein Entwickler ein Ticket zur Behebung einer Schwachstelle in einer Abhängigkeit erhält, wir die dafür anfällige Funktion aber gar nicht nutzen. In dem Fall setzen wir die Priorität zur Behebung dann herunter.

Aus aktuellem Anlass ein Thema war zudem, wie Kalpesh und sein Team reagierten, als mit Log4Shell eine der brisantesten Zero-Day-Schwachstellen der jüngeren Vergangenheit aufkam. Seinen Schilderungen nach reagierte man hier zunächst mit der Dokumentation und internen Kommunikation als Incident und untersuchte, wie viele Services betroffen waren. Zwar stand mit einem JVM-Flag ein Workaround zur Verfügung, den man auf die jeweiligen Java-Services hätte anwenden können, doch ließ sich dies nur über die jeweils für diese Verantwortlichen umsetzen. Ein zeitaufwändiges Unterfangen, für das man bis ins Wochenende auf Hochtouren arbeitete, um sicherzustellen, dass kein Service übersehen würde. Dabei fuhr man zweigleisig: Einmal galt es, eine Übersicht über sämtliche bei Pinterest genutzten Java-Services zu gewinnen. Außerdem mussten all jene Services ermittelt werden, die nicht durch den JVM-Flag abgedeckt wurden und somit nur durch ein Update gegenüber der Bedrohung sicher gemacht worden konnten. Eine zentrale Erkenntnis von Kalpesh in diesem Kontext: Wenn es um Zero-Day-Bedrohungen wie Log4Shell geht, ist ein zentrales Dashboard für sämtliche in der Produktion ausgeführten Services unabdingbar.

Nahtlose Dev-Workflows dank Auto-Scans

So kam auch die Frage auf, inwieweit die Technologie von Snyk manuelle Aufgaben im Entwickler-Team durch Self-Service ersetzen und zu mehr Visibility für Dev-Workflows beitragen konnte.

Für die einzelnen Programmiersprachen, mit denen wir arbeiten, verwenden wir jeweils ein eigenes Mono-Repository. Nach dessen Einbindung in Snyk wird jedes darin neu erstellte Projekt automatisch hinzugefügt. So erhalten wir ganz ohne unser Zutun Aufschluss darüber, welche Abhängigkeiten bei der Überführung von Code in das Repository eingeführt werden: Der Scan erfolgt direkt im Hintergrund, wenn Entwickler ein Projekt im Mono-Repository einrichten. Sie selbst nehmen davon gar keine Notiz.

Das Team von Kalpesh dagegen bekommt die Ergebnisse direkt in die Snyk UI übermittelt und damit einen umfassenden Gesamtüberblick.

Die Umgebung ist damit so aufgezogen, dass im Dev-Prozess kein Hin- und Herwechseln zwischen verschiedenen Tools vonnöten ist – etwas, dem Entwickler auch nach Ansicht von Maple zumeist eher kritisch gegenüberstehen. Wie sich dies speziell bei Pinterest ausdrückt und wie Kalpesh in diesem Zusammenhang agiert, war aber dennoch von Interesse.

Eine Ausnahme bilden hier auch die Dev-Teams von Pinterest nicht. „Am liebsten arbeiten sie mit ihren Tickets“, kommentiert er dazu. Zugleich sieht er aber Potenzial, den Teams via Snyk Learn mehr über die Web-Konsole von Snyk zu vermitteln oder relevante Informationen daraus in einem JIRA-Ticket zu verlinken. So etwa mehr Kontext zu Schwachstellen wie Cross-Service-Scripting (XSS) oder SQL Injection, um die Entwickler-Teams stärker für Security-Themen zu sensibilisieren und ihr allgemeines Interesse dafür zu fördern.

Sicherheit und Entwickler-UX im Einklang

Für Kalpesh und sein Team liegt der Schlüssel hierzu in minimal-invasiven Workflows, umgesetzt durch adäquat priorisierte Fixing-Aufgaben, die Entwickler nicht überfordern. Denn die ersten Scans nach der Implementierung von Snyk führten direkt ganze Litaneien von Schwachstellen in den bei Pinterest genutzten Abhängigkeiten zutage. Auf Dev-Seite nur die für das Unternehmen kritischen herausstellen zu können, war also ein wichtiger Faktor. Hierbei half die Möglichkeit, die Ergebnisse der mit Snyk automatisierten Scans zunächst im Security-Team auszuwerten, während Entwickler in ihrem gewohntes Tooling arbeiten und die Feature-Entwicklung ungebremst fortsetzen können.

Entwickler legen Wert auf zwei Punkte: Wo ein Problem liegt und welche Priorität sie ihm beimessen müssen. Genau das vermitteln wir ihnen mit unserem Ticket-System so kompakt wie effektiv.