Die Developer Experience mit Sicherheitstools bei Pinterest verbessern

Der sichere Einsatz von Open-Source-Bibliotheken hat in großen Unternehmen fortlaufend hohe Priorität. Eine große Herausforderung besteht darin, Sicherheitstools in den Entwickler-Workflow zu integrieren und ein System einzurichten, das die Behebung von Schwachstellen priorisiert, ohne Entwickler zu überfordern. Doch wie sieht ein erfolgreicher Ansatz aus?

Unser Simon Maple (Field CTO bei Snyk) sprach mit Kalpesh Dharwadkar (Product Security Engineer bei Pinterest), um zu erfahren, wie Pinterest mit Snyk entwicklerfreundliche Sicherheitspraktiken etabliert.

Drei zentrale Prioritäten: Transparenz, Scans und Triage

Pinterest nutzt in seinem Entwicklungs-Stack zahlreiche Open-Source-Komponenten. Eine verwundbare Open-Source-Bibliothek kann sich daher durchaus auf das Risikoprofil des Unternehmens auswirken. Bevor Kalpesh zum Unternehmen kam, nutzte das Team ein Ad-hoc-System, um mithilfe von NPM audit Einblicke in die Open-Source-Bibliotheken zu erhalten. Als Kalpesh anfing, wollte er jedoch ein zentrales System einrichten, das Transparenz über alle verwendeten Open-Source-Bibliotheken schafft. Sein Team prüfte zahlreiche Lösungen und entschied sich aus zwei Hauptgründen für Snyk: die entwicklerfreundlichen Funktionen und die Unterstützung sprachspezifischer Repositories wie Bazel, dem bevorzugten Build-Tool des Teams. Im Gespräch nannte Kalpesh seine wichtigsten Sicherheitsprioritäten:

Beim Thema Open-Source-Sicherheit konzentrieren wir uns bei Pinterest auf drei Dinge: Transparenz über verwundbare Bibliotheken, Tools für den gesamten Stack, die über das Scannen nach Fixes hinausgehen, und schließlich die Triage der Schwachstellen.

Kalpesh erklärte, dass das Team Jenkins für Builds nutzt. Es scannt das Build-System mit der Snyk CLI und lädt die Ergebnisse anschließend in die Snyk-Weboberfläche hoch. Das erste Ziel ist, alle Abhängigkeiten in den Code-Repositories sichtbar zu machen und die Behebung von Schwachstellen zu priorisieren. Deshalb befasste sich das Team mit dem Common Vulnerability Scoring System (CVSS), das Schwachstellen transparent macht. Gibt es einen Exploit, nutzt das Team Informationen von Snyk, um festzustellen, ob die Behebung hohe Priorität hat.

Sicherheitstests in die gesamte Pipeline integrieren

Als Nächstes fragte Simon nach Tests entlang der Entwicklungspipeline und danach, welche Herausforderungen entstehen, wenn Entwickler lernen sollen, Snyk zu nutzen. Kalpesh hat für diesen Schritt eine einfache Lösung. Als er Snyk erstmals in die Entwickler-Pipeline integrierte, machte er die Snyk-Konsole nicht für seine Entwickler zugänglich, sondern ließ den Scan als Schritt im Jenkins-Build laufen. Anschließend kümmerte er sich selbst um einige der „niedrig hängenden Früchte“ – also einfache Fixes – und ließ seine Arbeit von technischen Leitern oder Projektverantwortlichen überprüfen. Dadurch wurden sie motiviert, mit den Snyk-Tools selbst Fixes umzusetzen, und die Akzeptanz im Unternehmen stieg.

Effiziente Triage, priorisierte Fixes und der Umgang mit Log4Shell

Das Gespräch kam auf die Triage von Schwachstellen. Simon fragte: „Auf welche Signale oder Warnzeichen achten Sie im Backlog, um Entwicklern sagen zu können: ‚Das sind die fünf wichtigsten Schwachstellen, mit denen Sie sich befassen sollten‘?“ Kalpesh berücksichtigt dabei den Schweregrad der Schwachstelle, ob es einen aktiven Exploit gibt und ob die Schwachstelle einen Dienst betrifft, der über das Internet erreichbar ist. Anhand dieser Kriterien legt er die Priorität der Fixes fest. Anschließend wird ein Ticket erstellt, damit ein Entwickler oder Serviceverantwortlicher die Schwachstelle behebt. Die im Ticket erfassten Informationen helfen seinem Team zu verstehen, ob seine Einschätzung der Schwachstelle mit der Einschätzung der Entwickler übereinstimmt.

Das Ticket wird einem Entwickler zugewiesen. Dieser meldet sich möglicherweise bei uns und sagt: „Wir nutzen diese bestimmte Funktion, die durch die Abhängigkeit verwundbar ist, gar nicht.“ In diesem Fall versuchen wir, die Priorität der Funktion herabzusetzen.

Als das Gespräch auf Log4Shell kam, fragte Simon Kalpesh, wie Pinterest mit einer schwerwiegenden Zero-Day-Schwachstelle umgeht. Kalpesh erinnerte sich daran, dass sein Team am Morgen nach der Bekanntgabe von Log4Shell einen Vorfall ausrief, um herauszufinden, wie viele Dienste betroffen waren. Es gab ein JVM-Flag (oder einen Workaround), das sie auf ihre Java-Dienste anwendeten. Für die Bereitstellung aller Dienste waren sie jedoch auf die jeweiligen Serviceverantwortlichen angewiesen – und das braucht Zeit. Die Bereitstellung des Workarounds beschäftigte sein Team bis zum Wochenende, denn es wollte sicherstellen, dass alle Dienste mit dem JVM-Flag ausgerollt worden waren. Das Team richtete zwei Arbeitsstränge ein: Der eine sollte alle Java-Dienste bei Pinterest erkennen, der andere alle Dienste, die nicht durch den JVM-Flag-Workaround abgedeckt waren. Bei Diensten, für die das JVM-Flag nicht ausreichte, war ein Update die einzige Möglichkeit, die Bedrohung einzudämmen. Kalpesh ergänzte, eine wichtige Lehre aus Log4Shell sei, ein zentrales Dashboard zu haben, das alles anzeigt, was in der Produktionsumgebung läuft.

Scans automatisieren, damit die Entwicklung weiterlaufen kann

Simon kam darauf zurück, wie Pinterest Snyk nutzt, und fragte, in welchem Umfang Snyk den manuellen Aufwand bei Pinterest reduziert hat, indem Entwickler Aufgaben selbst übernehmen können, und wie viel Transparenz das Team über die Entwickler-Pipelines hat.

Bei Pinterest nutzen wir sprachspezifische Monorepos. Sobald Sie ein Monorepo zu Snyk hinzufügen, wird jedes neue Projekt, das in diesem Repository erstellt wird, automatisch hinzugefügt. Wenn in diesem Repository ein neues Projekt entsteht, ist also keine zusätzliche Arbeit erforderlich. Sobald Code in das Repository gemergt und der Snyk-Scan ausgeführt wurde, sehen wir, welche Abhängigkeiten hinzugekommen sind. [Wenn ein Entwickler ein Projekt in seinem Monorepo erstellt, läuft der Scan] für den Entwickler transparent ab. Er muss nicht einmal wissen, dass Snyk läuft.

Mit dieser Konfiguration wird jedes Projekt automatisch gescannt und in die Snyk-Benutzeroberfläche übertragen, sobald ein Entwickler es erstellt. So erhält Kalpeshs Team einen Gesamtüberblick.

Simon merkt an, dass Entwickler meist lieber in ihrem gewohnten Workflow bleiben, statt zu anderen Tools zu wechseln. Er fragte Kalpesh: „Wie haben Sie es eingerichtet, damit Entwickler in ihren Pipelines bleiben können?“

Kalpesh stimmte zu, dass Entwickler gern „in ihren Tickets bleiben“ und trotzdem alles Wichtige erfahren möchten. Er erwähnte den Learning Hub von Snyk mit seinen Lernressourcen für Entwickler. Der Zugang zu diesem Lernangebot lässt ihn darüber nachdenken, Entwicklern mehr Einblick in die Snyk-Webkonsole zu geben oder möglicherweise im JIRA-Ticket einen Link zu relevanten Informationen von Snyk Learn einzufügen. So erhalten Entwickler mehr Kontext zu Schwachstellen wie XSS oder SQL-Injection. Das ist eine hilfreiche Möglichkeit, Entwickler dabei zu unterstützen, ihr Sicherheitswissen auszubauen.

Entwickler dort arbeiten lassen, wo sie möchten

Insgesamt legen Kalpesh und sein Team bei Pinterest Wert auf einen entwicklerfreundlichen Workflow und setzen auf Triage, damit Entwickler nicht überfordert werden. Er merkt an, dass bei der ersten Integration von Snyk eine große Zahl von Schwachstellen in den Abhängigkeiten sichtbar wurde. Deshalb war es wichtig, nur die Schwachstellen anzuzeigen, die für das Unternehmen hohe Priorität hatten. Scans zu automatisieren und Ergebnisse mit Snyk einzusehen, während Entwickler in ihren bevorzugten Tools bleiben können, hilft Pinterest, die Entwicklung reibungslos am Laufen zu halten.

Entwickler möchten wissen: Was ist das Problem, wie lässt es sich beheben und welche Priorität hat es? Wenn Sie diese Punkte im Ticket eines Entwicklers angeben können, sind Sie gut aufgestellt.