Die 5 Prinzipien der Developer Experience von Snyk

Im Zeitalter der KI-gestützten Entwicklung ist Geschwindigkeit der neue Standard. Doch während KI-Agenten das Tempo beim Programmieren erhöhen, verstärken sie auch das Risiko von Sicherheitsengpässen. Bei Snyk sind wir überzeugt, dass eine erstklassige Developer Experience (DX) der einzige Weg ist, diese neue Ära abzusichern. DX ist keine zusätzliche Produktschicht. Sie bildet das Fundament, auf dem Entwickler KI-Innovationen sicher vorantreiben können.

Wir verstehen DX als ein System von Entscheidungen, deren Wirkung sich im Laufe der Zeit verstärkt. Jede Interaktion, jede Standardeinstellung und jede Information, auf die Entwickler stoßen, beeinflusst, wie effektiv sie unsere Plattform nutzen können.

Die fünf Prinzipien, die sich aus der Weiterentwicklung und Verfeinerung der Snyk-Plattform ergeben haben, bilden heute das Fundament für eine hervorragende DX. Sie leiten kontinuierlich Tausende kleiner Entscheidungen über die gesamte Produkterfahrung hinweg und unterstreichen unser Engagement für diesen fortlaufenden Prozess.

1. Gehen Sie dorthin, wo Entwickler arbeiten – statt sie zu sich zu bitten

Eine der häufigsten Herausforderungen bei Entwicklertools ist die Annahme, dass ein ansprechendes Dashboard das zentrale Ziel sei. Die Erfahrung zeigt jedoch, dass Entwickler ihre bestehenden, über Jahre optimierten Workflows bevorzugen: ihre IDE, das Terminal, ihren Git-Workflow und ihren Pull-Request-Prozess (PR). Diese Workflows zu verlassen und den Kontext zu wechseln, ist mit erheblichen Kosten verbunden.

Bei Snyk haben wir das selbst erlebt. Wir hatten in der Snyk-Plattform eine detaillierte Oberfläche für Ergebnisse entwickelt – mit priorisierten Schwachstellenlisten, Empfehlungen zur Behebung und vollständigen Datenflussanalysen. Doch Entwickler riefen sie nicht auf. Wir haben gelernt: Selbst die wertvollsten Daten bleiben oft unbeachtet, wenn dafür ein Kontextwechsel nötig ist. Indem wir Sicherheitsinformationen direkt in die bestehende PR-Konversation einbrachten, orientierten wir uns am natürlichen Arbeitsablauf der Entwickler.

Wir änderten unser Modell. Statt Entwickler zu Snyk zu bitten, brachten wir Snyk zu ihnen. Sicherheitsergebnisse wurden Teil der Pull-Request-Konversation und direkt im SCM angezeigt – im selben Thread, in dem ohnehin bereits Code-Reviews stattfanden. Dieselben Informationen. Kein Kontextwechsel, aber eine deutlich höhere Akzeptanz.

Dieses Prinzip geht über PRs hinaus. Deshalb investieren wir stark in IDE-Plugins, KI-Programmierassistenten, CLI-Integrationen und CI/CD-Gates. Wir stellen uns immer dieselbe Frage: Wo arbeiten Entwickler bereits, und wie können wir dort präsent sein?

Derzeit findet ein grundlegender Wandel statt: von traditionellen IDEs hin zu agentischen Entwicklungsumgebungen. Bei dem Tempo, das KI-Programmierassistenten ermöglichen, wird der Kontextwechsel zu einem noch größeren Engpass, denn die höhere Produktivität von Agenten verstärkt die Kosten von Unterbrechungen. Da agentische Plattformen zu einem festen Bestandteil von Entwickler-Workflows werden, ist Snyk bereits in diese Umgebungen integriert, um KI-generierten Code von Anfang an abzusichern.

2. Entwickler sind keine Sicherheitsspezialisten – sprechen Sie ihre Sprache

Bei der Gestaltung von Sicherheitsergebnissen in PRs orientierten wir uns an der Denkweise von Entwicklern. CVSS-Werte oder CWE-Klassifizierungen sind für Sicherheitsexperten sinnvoll, für Entwickler jedoch Fachjargon, der erst übersetzt werden muss.

Wir zeigen kontextbezogene Beschreibungen in natürlicher Sprache an, die auf den eigenen Datenflussanalysen von Snyk basieren. Bei einer SQL-Injection-Schwachstelle würden wir beispielsweise statt eines allgemeinen Hinweises erklären, dass nicht bereinigte Nutzereingaben aus dem HTTP-Anfragebody direkt in eine SQL-Abfragezeichenfolge eingefügt werden – und dabei Quelle, Ziel und Mechanismus im eigenen Code der Entwickler benennen.

Dieser eine Satz erklärt Entwicklern, die häufig keine Sicherheitsspezialisten sind, genau, was das Problem ist und wo es auftritt – bis hin zur konkreten Datei und Zeilennummer – und zwar in Begriffen, die sie bereits verstehen. Für alle, die mehr wissen möchten, steht weiterhin die vollständige Ablaufanalyse zur Verfügung. Doch die meisten Entwickler müssen nicht tiefer einsteigen. Sie müssen genug verstehen, um handeln zu können.

Wir bemühen uns, dieses Prinzip auf jeder Oberfläche des Snyk-Produkts umzusetzen. Unsere Leitfrage lautet: „Was muss dieser Entwickler angesichts seines Wissensstands genau jetzt verstehen?“

3. Jede Information ist entweder ein Signal oder Rauschen – dazwischen gibt es nichts

Sicherheitstools neigen dazu, alles anzuzeigen. Das wirkt umfassend, überfordert aber oft, statt zu helfen. Als wir uns unsere PR-Erfahrung genauer ansahen, formulierten wir die Frage neu: Welche Informationen gehören wirklich in die Ansicht der Entwickler?

Wir entschieden uns für einen bewussten Ansatz. Was wir anzeigen, hängt vom Workflow ab. Bei der Prävention benötigen Entwickler schnelle, umsetzbare Hinweise. Bei der Behebung brauchen sie mehr Tiefe und weitere Optionen, um Risiken zu reduzieren. In einem PR sollte jede Information entweder eine unmittelbare Frage beantworten oder einen klaren nächsten Schritt ermöglichen. Dieser Kontext ist entscheidend: Entwickler konzentrieren sich in einem PR darauf, Funktionen bereitzustellen. Die Behebung von Schwachstellen tritt dabei in den Hintergrund. Das unterscheidet sich deutlich vom Backlog, in dem die Behebung von Problemen im Mittelpunkt steht.

Auch eine schrittweise Offenlegung von Informationen trägt zu dieser Balance bei. Die Hauptansicht konzentriert sich auf das Problem, seinen Schweregrad und den nächsten Schritt. Bei Bedarf liefern weitere Ebenen zusätzlichen Kontext, etwa zu Datenflüssen. So bleibt die Erfahrung fokussiert und frei von unnötigem Rauschen.

4. Das Produkt ist nicht die Erkennung, sondern die Behebung

Lange Zeit maßen Sicherheitstools ihren Erfolg daran, was sie fanden. Je mehr Schwachstellen sie aufdeckten, desto vollständiger schien das Tool. Dabei blieb jedoch die entscheidende Frage außen vor: Wurden diese Schwachstellen auch behoben?

Die meisten Entwickler wollen nicht einfach nur informiert werden. Sie wollen wissen, was als Nächstes zu tun ist. Ein Schwachstellenbericht ohne klaren nächsten Schritt ist nichts als Rauschen mit einem Schweregrad – und Entwickler lernen völlig nachvollziehbar, ihn auch so zu behandeln.

Mit direkt in die PR-Erfahrung integrierten Fix-Vorschlägen wollten wir den Kreis schließen: Schwachstellen nicht nur erkennen, sondern beheben, ohne den Workflow zu verlassen. Erkennt Snyk eine Schwachstelle im Code, weist es nicht nur darauf hin. Es schlägt einen konkreten, KI-generierten Fix als Diff vor – direkt im PR als Review-Kommentar, mit entfernten roten und hinzugefügten grünen Zeilen, der sich mit nur einer Aktion als Commit übernehmen lässt.

Im Beispiel der SQL-Injection ersetzt der AI Fix-Vorschlag die Zeichenfolgeninterpolation durch eine parametrisierte Abfrage, statt nur darauf hinzuweisen und Entwickler mit der Lösung allein zu lassen. Entwickler müssen sich nicht erst über sichere SQL-Praktiken informieren – der Fix ist bereits vorhanden. Der Weg zur Behebung wird zum Standardweg.

Eine gute DX zeigt, wie sich ein Problem beheben lässt. Eine hervorragende DX macht die Behebung zum Standardweg.

5. Vertrauen entsteht, wenn Entwickler verstehen, warum etwas funktioniert – nicht nur, was zu tun ist

Als wir den Fix-Vorschlag einführten, tauchte in den Rückmeldungen von Entwicklern immer wieder dieselbe Frage auf: nicht „Funktioniert der Fix?“, sondern „Warum funktioniert dieser Fix?“ Entwickler übernahmen Vorschläge und konnten sie anschließend nur schwer ihren Kollegen erklären. Der Fix löste das unmittelbare Problem und schuf gleichzeitig ein neues.

Deshalb ergänzten wir eine Funktion, die sich als eine der wirkungsvollsten Änderungen an unseren PR-Checks erwies: eine Erklärung in einfacher Sprache, die genau erläutert, warum die vorgeschlagene Änderung die Schwachstelle beseitigt. Kein Link zur Dokumentation. Kein Verweis auf die CVE. Sondern eine Erklärung, die sich auf die konkreten Details des Codes stützt und zeigt, wie der Fix die Schwachstelle behebt.

Im Beispiel der SQL-Injection würde die Erklärung darlegen, wie der Ersatz dynamischer Zeichenfolgeninterpolation durch parametrisierte Abfragen dafür sorgt, dass Nutzereingaben als Daten statt als ausführbarer Code behandelt werden – und warum genau dieser Unterschied die Schwachstelle schließt.

Diese beiden Funktionen – der Fix-Vorschlag und seine Erklärung – entsprechen der Art und Weise, wie ein erfahrener Sicherheitstechniker Code mit einem Kollegen prüfen würde: zunächst sicherstellen, dass das Problem verstanden wurde, und dann zeigen, wie eine gute Lösung aussieht.

Vertrauen entsteht durch nachvollziehbare Begründungen. Jedes Mal, wenn Snyk seine Überlegungen erklärt, gibt es Entwicklern die Werkzeuge an die Hand, um ein eigenes Gespür für Sicherheit zu entwickeln – und genau das ist letztlich das nachhaltigste Ergebnis.

Eine hervorragende Developer Experience entsteht nicht zufällig

Diese fünf Prinzipien haben sich daraus entwickelt, dass wir beobachteten, was nicht funktionierte, die Ursachen verstanden und unseren Ansatz änderten.

Eine hervorragende Developer Experience braucht Prinzipien wie diese, die Tausende kleiner Entscheidungen in Produktentwicklung, Engineering und Design leiten können. Auf dem Weg in eine Zukunft, in der KI und menschliche Entwickler enger zusammenarbeiten, sorgen diese Prinzipien dafür, dass Sicherheit Rückenwind gibt statt zum Hindernis zu werden. Bei Snyk arbeiten wir kontinuierlich daran, besser zu werden – mit jeder Entscheidung, jedem Fix und jedem erfolgreichen Deployment.

Erfahren Sie, wie die von Snyk entwickelte Developer Experience Ihr Programm voranbringen kann. Buchen Sie noch heute eine Demo.