Wie Snyk die Developer Experience priorisiert

Kontextwechsel können der größte Feind der Sicherheit sein. Die heutigen Sicherheitspraktiken erfordern die Unterstützung der Entwicklerinnen und Entwickler. Müssen Entwicklungsteams jedoch ihre etablierten Workflows verlassen, um Sicherheitsprobleme zu beheben, sinkt die Wahrscheinlichkeit, dass sie die entsprechenden Tools nutzen.

Damit Entwicklungsteams Schwachstellen in ihrem Code wirklich finden und beheben können, müssen Sicherheitsteams Security noch weiter nach links verlagern. Es reicht nicht aus, einfach benutzerfreundliche Tools und entsprechende Schulungen bereitzustellen. Wenn Entwicklerinnen und Entwickler ihren Workflow dennoch unterbrechen müssen, um sicherheitsbezogene Aufgaben zu erledigen, erhöht das die kognitive Belastung. Oft fehlt ihnen die Zeit oder die nötigen Ressourcen, um ihrem ohnehin schon vollen Aufgabenplan noch eine weitere Aufgabe hinzuzufügen.

Um diese Herausforderungen zu bewältigen, veröffentlicht Snyk neue Funktionen, die unsere Developer-First-Lösungen erweitern und Sicherheitsteams dabei unterstützen, sich weiterhin an die neuen Anforderungen heutiger Entwicklungszyklen anzupassen. Bei unserem jüngsten SnykLaunch haben wir Nutzerinnen und Nutzern bereits einen Einblick in diese neuen Funktionen gegeben. Die Aufzeichnung ist jetzt auf Abruf verfügbar. In diesem Blogbeitrag sehen wir uns die neuen Releases an, die die Developer Experience unmittelbar verbessern, und erklären, warum sie für Teams heute wichtig sind. 

Die Kosten von Kontextwechseln

Entwicklerinnen und Entwickler verbringen einen Großteil ihrer Zeit an drei Orten: in ihrer IDE, in der CLI und im SCM. Es mag einfach klingen, bei einem Sicherheitsalarm zu einem laufenden Projekt auf eine separate Plattform zu wechseln und das Problem dort zu beheben. In der Praxis ist das jedoch oft nicht der Fall. Dieser Kontextwechsel reißt Entwicklungsteams nicht nur aus ihren vertrauten Workflows, sondern fügt der Softwareentwicklung zusätzliche Schritte hinzu. Das unterbricht den Produktivitätsfluss und zwingt sie, bei sicherheitsbezogenen Aufgaben zwischen mehreren Systemen hin- und herzuwechseln. 

Entwicklerinnen und Entwickler schreiben den Großteil ihres Codes in ihrer IDE – egal, ob es sich um manuell geschriebenen Code, von generativer KI erstellten Code oder eine Mischung aus beidem handelt. Sie erstellen Branches oder Forks, übertragen ihren Code schrittweise in ihr SCM und erstellen, sobald sie bereit sind, einen „Pull Request“ (PR). Pull Requests sind auf reibungslose Zusammenarbeit und Code-Reviews ausgelegt. Wenn Entwicklerinnen und Entwickler diesen Prozess unterbrechen und den SCM-Workflow verlassen müssen, um Sicherheitsprobleme zu beheben, kommt eine unerwartete Aufgabe hinzu und ihr Arbeitsfluss wird gestört. Damit wird der Zweck eines effizienten PR-Workflows zunichtegemacht. Es ist, als würde Ihrer Aufgabenliste überraschend ein Punkt hinzugefügt, obwohl Sie glauben, fast fertig zu sein.

Diese mangelnde Abstimmung zwischen Entwicklungs- und Sicherheitsteams beeinträchtigt die DevSecOps-Bemühungen. Sicherheitsteams fragen sich oft, warum mehr Entwicklerinnen und Entwickler ihre Tools nicht nutzen. Gleichzeitig wehren sich diese möglicherweise gegen Unterbrechungen ihres Workflows durch unerwartete Aufgaben. Am Ende verlieren alle Beteiligten.

Zwei Grundpfeiler der Developer Experience

Anstatt von Entwicklerinnen und Entwicklern zu verlangen, sich bei der Behebung von Sicherheitsproblemen aus ihrer Arbeit herauszureißen, müssen Sicherheitsteams sie dort abholen, wo sie bereits arbeiten. Zwei grundlegende Ansätze helfen dabei:

1. Entwicklerinnen und Entwickler mit Informationen versorgen, die zu ihrem aktuellen Arbeitskontext passen

Um Sicherheitsprobleme in ihrem Code erfolgreich zu beheben, benötigen Entwicklerinnen und Entwickler Hintergrundinformationen. Dazu kann gehören, warum eine bestimmte Codezeile als anfällig markiert wurde und wie sich die Schwachstelle durch Änderungen beheben lässt. Sicherheitsteams können jedoch nicht erwarten, dass Entwicklungsteams allgemeine Dokumentationen durcharbeiten oder Tutorials auf einer Sicherheitsplattform absolvieren, um das Problem zu lösen. Sie müssen kurze, leicht verständliche Lerninhalte mit grundlegenden Informationen und Empfehlungen zur Behebung bereitstellen – nicht mehr und nicht weniger. 

2. Reibungsverluste reduzieren und Workflows möglichst wenig unterbrechen

Snyk unterstützt Entwicklerinnen und Entwickler bereits dabei, Sicherheitslücken direkt in ihren IDEs zu finden und zu beheben. Da sie auch viel Zeit in ihrem SCM verbringen, erweitert Snyk seine Developer-First-Tools jetzt um Security-Insights in SCM-PR-Workflows. So erhalten sie Sicherheitsfeedback nahtlos in den vertrauten Tools, die sie täglich nutzen. 

Die neuen PR-Funktionen von Snyk für eine bessere Developer Experience 

Aus unserer direkten Zusammenarbeit mit Entwicklungsteams und unserer Unterstützung bei der Integration von Security in ihre IDEs wissen wir: Am besten lässt sich Security in den Tools verankern, die Entwicklerinnen und Entwickler bereits nutzen. Wenn sie jetzt auf „Create PR“ klicken, können die PR-Prüfungen von Snyk (allgemein verfügbar für Snyk Open Souce und als Early Access für Snyk Code) direkt im standardmäßigen PR-Workflow ein Code-Review mit Fokus auf Security durchführen.

Nach Abschluss des PR-Checks fügt unsere neue Funktion „Issues Summary“ im SCM einen Kommentar mit einer Zusammenfassung der Sicherheitsbefunde direkt im PR-Workflow hinzu. Die Ergebnisse werden nach Schweregrad zusammengefasst und enthalten direkte Links, über die Entwicklerinnen und Entwickler die Probleme überprüfen und beheben können.

Außerdem bieten wir jetzt anpassbare PR-Vorlagen, mit denen Teams die von Snyk generierten PRs individuell gestalten können. Die neuen anpassbaren PR-Vorlagen von Snyk sorgen dafür, dass die von Snyk generierten Pull Requests den spezifischen Standards, Praktiken und Kommunikationspräferenzen Ihrer Organisation entsprechen. Sie können Titel und Beschreibung festlegen, auswählen, welche Sicherheitsdetails geteilt werden sollen, und sogar Jira-Ticketinformationen ergänzen – ganz nach den Erwartungen Ihrer Entwicklerinnen und Entwickler an ihre PRs. Wenn Sie unsere Funktionen an die Anforderungen Ihrer Organisation anpassen, fügt sich der Workflow noch nahtloser in bestehende Prozesse ein. 

Wenn Sie mehr über diese neuen Pull-Request-Funktionen erfahren möchten, sehen Sie sich unsere aktuelle SnykLaunch-Präsentation an.