Wie Mulesoft mit Snyk eine entwicklerorientierte Shift-Left-Kultur fördert

Obwohl Shift Left seit rund einem Jahrzehnt ein viel diskutiertes Thema ist, fällt es vielen Unternehmen noch immer schwer, das Konzept in die Praxis umzusetzen. Es gibt viele Missverständnisse darüber, was Shift Left bedeutet und wie Entwicklungsteams Verantwortung für Sicherheit übernehmen können, ohne ihre bestehenden Arbeitsabläufe zu beeinträchtigen. So leiten viele Teams Sicherheitsprobleme zwar früher im Softwareentwicklungszyklus (SDLC) an Entwickler weiter, versorgen sie dabei aber nicht mit dem nötigen Kontext oder den passenden Tools, um diese Probleme gezielt zu beheben.

Das Team von Mulesoft wollte mehr tun, als Entwicklern einfach nur Sicherheitswarnungen zu schicken. Es war überzeugt, dass echter DevSecOps-Erfolg davon abhängt, die Developer Experience in den Mittelpunkt zu stellen. Um diese Ziele zu verwirklichen, musste Mulesoft jedoch mit den richtigen Lösungen und Prozessen den Weg dorthin einschlagen.

In einem kürzlich geführten Kamingespräch sprachen Clinton Herget, Field CTO bei Snyk, und Martin Adolfi, Senior Engineering Manager bei Mulesoft, über Mulesofts DevSecOps-Weg. Sie erörterten, was Entwicklersicherheit für die schnelllebigen Unternehmen von heute wirklich bedeutet, und beleuchteten die Herausforderungen und Erfolge, die Mulesoft beim Erreichen seiner Shift-Left-Ziele erlebt hat.

Mulesofts Herausforderung: Shift Left in die Praxis umsetzen

Als Adolfi und sein Team ihre DevSecOps-Initiativen genauer unter die Lupe nahmen, hatten sie eine klare Vorstellung davon, was Shift Left bedeutet – und was nicht. Dem Team fiel eine Diskrepanz zwischen den Sicherheitserwartungen und der typischen Denkweise von Entwicklern auf. Adolfi bezeichnete es als „Throwing Left“ statt Shift Left: Warnungen und Berichte werden ohne tieferen Kontext oder konkrete Anleitung an Entwickler geschickt, die dann selbst für die Behebung sorgen sollen. Dieser Ansatz kostet Entwickler Zeit und mentale Kapazität. Sie müssen zwischen verschiedenen Kontexten wechseln und werden aus einem Zustand konzentrierten, produktiven Arbeitens gerissen. Das hält sie von dem ab, was sie gerne tun – programmieren und innovativ sein –, mindert die Arbeitszufriedenheit und führt zu Spannungen zwischen Entwicklungs- und Sicherheitsteams.

Entwickler zu motivieren, in Sachen Sicherheit erfolgreich zu sein und schließlich zu Security Champions zu werden, beginnt damit, ihnen einen möglichst einfachen Weg zu bieten. Adolfi zufolge kommt es darauf an, Entwickler zu befähigen, Probleme innerhalb ihrer bestehenden Feedbackschleifen zu beheben. Er sagte: „Wenn ein Problem erst als Ticket vorliegt, ist es schon zu spät … Man sollte Tools entwickeln, die direkt in den Arbeitsablauf der Entwickler eingebunden sind, statt zu sagen: ‚Wir haben dieses neue Dashboard oder diesen neuen Bericht, und Sie müssen in diesem Tool nach den benötigten Informationen suchen.‘ … [Als Entwickler] werde ich ständig davon abgehalten, das zu tun, was ich möchte und was mich begeistert. Um meine Arbeit zu erledigen, muss ich sieben verschiedene Datenquellen durchsuchen.“

Das Team wusste, dass es Sicherheits-Feedbackschleifen in die bestehenden Arbeitsabläufe der Entwickler integrieren wollte. Zuvor galt es jedoch, einige Herausforderungen zu bewältigen.

Zunächst musste das Team auf das Feedback der Entwickler eingehen, dass der Anwendungssicherheitsprozess „zu bürokratisch“ sei. Die Entwicklungsteams von Mulesoft standen unter dem Druck, bestehende Projekte durch regelmäßige Patches zu pflegen und bei neuen Anwendungen Compliance-Vorgaben und SLAs einzuhalten. Sie brauchten einen Sicherheitsansatz, der die Bürokratie nicht noch weiter verschärfte.

Zudem unterschieden sich die Pipelines der Entwicklungsteams stark voneinander. Die Entwickler schätzten diese Freiheit und wollten sie nicht aufgeben. Die Vielfalt an Programmiersprachen, Frameworks und Microservices erschwerte es, im gesamten Unternehmen einen einheitlichen Sicherheitsprozess zu etablieren.

Mulesofts DevSecOps-Erfolge

Um diese Herausforderungen zu bewältigen, brauchte Mulesoft einen Sicherheitspartner, der Entwickler in den Mittelpunkt stellt. Das Team entschied sich für die Plattform von Snyk, da sie eng mit seinen DevSecOps-Zielen übereinstimmte.

Adolfi sagte: „Snyk teilt unsere Denkweise: Sicherheit nach links zu verlagern, mehr Mehrwert zu liefern, Erkenntnisse bereitzustellen und Entwicklern zu zeigen, wie sie Probleme beheben können – mit allen Informationen, die sie brauchen, um die Auswirkungen und den Schweregrad zu verstehen.“

Da Snyk in den verschiedenen nativen Umgebungen der Entwickler eingebunden ist und sofortiges Feedback sowie Lösungsvorschläge liefert, konnten Adolfi und sein Team den Prozess zur Erkennung und Behebung von Schwachstellen für die Entwickler bei Mulesoft erfolgreich vereinfachen.

Adolfi sagte: „Der Hauptgrund, warum sich das Team für Developer Experience auf Snyk und nicht auf den Rest unseres Tech-Stacks konzentriert hat, ist, dass Snyk den Entwicklern am nächsten ist.“

Snyk + Mulesoft: Ein Blick in die Zukunft

Während das Team von Mulesoft den SDLC weiterhin mit einer DevSecOps-Denkweise absichert, wird es am Prinzip Shift Left festhalten und Entwickler befähigen. Dazu erhalten Entwicklungsteams die Tools und Prozesse, die sie brauchen, um Schwachstellen erfolgreich in Echtzeit zu beheben und Kontextwechsel so weit wie möglich zu vermeiden.

Als nächsten Schritt auf ihrem Entwicklungsweg plant das Team von Mulesoft, weitere KI-Tools in seine Pipelines einzubinden. Es sieht Möglichkeiten, KI sowohl zum Schreiben als auch zum Überprüfen von Code einzusetzen.

Wenn Sie mehr über Mulesofts Weg zu mehr Entwicklersicherheit und die DevSecOps-Erfolge erfahren möchten, hören Sie sich das vollständige Gespräch mit Adolfi und Herget an.

Play Video: How Mulesoft Achieved Developer Security at Scale