So führen Sie eine entwicklerorientierte Lizenz-Compliance erfolgreich ein

Lizenz-Compliance wurde von Entwicklern traditionell als Hindernis wahrgenommen, muss es aber nicht bleiben. Sie ist entscheidend, um Geschäftsrisiken zu minimieren. Doch skalierbar und ohne die Entwicklung auszubremsen gelingt das nur mit einer entwicklerorientierten Denkweise.

Letztendlich entscheiden Entwickler, was sie in ihrer Software verwenden. Die Einhaltung von Softwarelizenzen lässt sich nur erreichen, wenn Entwickler angemessen befähigt werden, die richtigen Compliance-Entscheidungen zu treffen, dafür die passenden Tools erhalten und mit Compliance-Teams zusammenarbeiten, die für das richtige Maß an Governance sorgen.

Die Bedeutung der Autonomie von Entwicklern

Software ist der Motor der digitalen Transformation, und die Welt dreht sich heute um die Menschen, die diese Software entwickeln: die Entwickler. Damit wir in unseren jeweiligen Märkten wettbewerbsfähig bleiben, erwarten wir von ihnen, dass sie alles daransetzen, schnell Mehrwert zu schaffen. Sie müssen ihre Systeme durchgängig verantworten – das heißt, den Bedarf verstehen, eine Lösung konzipieren, sie implementieren, bereitstellen und betreiben sowie aus den Erfahrungen lernen. Und dann beginnt der Prozess von vorn.   

Damit dieser Prozess gelingt, brauchen Entwickler die Autonomie, Entscheidungen zu treffen, und die richtigen Tools, um sie umzusetzen. Jedes Mal, wenn ein externes Team hinzugezogen werden muss, verlangsamt sich der Prozess und es entsteht Reibung. Das widerspricht grundsätzlich dem Ziel des Unternehmens: schnell voranzukommen und dabei Risiken so gering wie möglich zu halten.

Lizenz-Compliance gehört bekanntlich zu den Bereichen, in denen die Zusammenarbeit mit Entwicklern bisher nicht erfolgreich war. Da Compliance-Prüfungen meist erst spät im Entwicklungszyklus stattfinden, bremsen manuelle und starre Prozesse häufig die Entwicklungsabläufe aus.

Doch das muss nicht so sein. Lizenz-Compliance lässt sich neu denken und entwicklerorientiert gestalten, wenn drei zentrale Aspekte berücksichtigt werden: die Befähigung von Entwicklern und die Benutzerfreundlichkeit für Entwickler, damit sie Lizenz-Compliance annehmen können, sowie Governance, damit die richtigen Entscheidungen getroffen werden.

Compliance-Entscheidungen ermöglichen

Entwickler treffen täglich unzählige Entscheidungen. Ziel sollte daher sein, sie dabei zu unterstützen, die richtigen Compliance-Entscheidungen zu treffen.

So früh wie möglich testen

Entwicklern erst nach dem Build-Prozess eine Liste mit Lizenzproblemen vorzulegen, ist nicht nur kontraproduktiv, sondern verstärkt auch die Spannungen zwischen Entwicklern und Kontrollinstanzen. Damit Entwickler fundierte Compliance-Entscheidungen treffen können, müssen sie nicht konforme Komponenten so früh wie möglich erkennen und sich dadurch späteren Aufwand ersparen können. Das beginnt in ihrer lokalen Entwicklungsumgebung und setzt sich im gesamten Git-Workflow sowie anschließend in CI/CD fort.

Eindeutige Fälle von unklaren unterscheiden

Da heute mehr als 200 Open-Source-Lizenzen verwendet werden, müssen Entwickler klar einschätzen können, welches Risiko sie eingehen, wenn sie sich für eine Komponente statt für eine andere entscheiden.

Nicht jede Lizenz ist eine GPL-Lizenz, die Entwicklern eine klare Grenze setzt. Manche Lizenzen sind deutlich mehrdeutiger und lassen Interpretationsspielraum. Nehmen wir zum Beispiel eine Open-Source-Komponente mit einer Lizenz, die eine Namensnennung verlangt. Entwickler können dann prüfen, ob die erforderliche Namensnennung erfolgt ist. Oder eine unbekannte Lizenz: Hier benötigen Entwickler das Wissen und die Tools, um zu entscheiden, ob sie fortfahren und das Compliance-Team im Hintergrund informieren oder die Entwicklung bis zur Freigabe unterbrechen sollen.

Je mehr Kontext Entwickler erhalten, desto besser können sie das Risiko gegen den Nutzen der infrage kommenden Open-Source-Komponente abwägen. Dieser Kontext lässt sich einerseits durch Schulungen für Entwickler vermitteln und andererseits durch Entwicklertools, die kontextbezogene Informationen zu Lizenzproblemen wie Copyright-Angaben bereitstellen.

Parallel vorankommen

Entwicklungsteams können es sich nicht leisten, bis zum Projektende zu warten, bevor sie die Kontrollinstanzen einbeziehen. Dieser sequenzielle Ansatz ist in der Welt der kontinuierlichen Entwicklung nicht mehr tragfähig und führt nur zu unnötigen Spannungen. Stattdessen sollten Entwickler und Kontrollinstanzen eine gute Zusammenarbeit aufbauen, in der Compliance parallel umgesetzt wird.

Entwickler müssen wissen, wie und wann sie frühzeitig auf die Kontrollinstanzen zugehen sollten – auch wenn es unbequem oder schwierig ist. Die Kontrollinstanzen sollten den Dialog unterstützen und durch Empfehlungen, Schulungen und den Austausch von Informationen begleiten.

Akzeptanz durch Benutzerfreundlichkeit für Entwickler fördern

Entwickler übernehmen viele neue Aufgaben, darunter auch Sicherheit und Compliance, sind aber nicht in all diesen neuen Bereichen Experten. Wenn wir möchten, dass sie Compliance annehmen, müssen wir dafür sorgen, dass sie die richtige Lizenz-Compliance-Entscheidung leicht treffen und umsetzen können.

In Entwicklungs-Workflows integrieren

Es ist äußerst unwahrscheinlich, dass ein Entwicklungsteam zeitaufwendige und kontraproduktive Workflows für die Lizenz-Compliance einführt. Werden Entwickler dazu gezwungen, führt das natürlich zu Misstrauen und Ablehnung.

Eine nahtlose, native Integration in bestehende Git-basierte Workflows – statt einer externen Integration – trägt wesentlich dazu bei, dass Entwickler die Lösung annehmen.

Transparenz schaffen

Je mehr Einblick Entwickler haben, desto leichter können sie auf erkannte Lizenzprobleme reagieren. Suchen Sie nach einer Lösung, die mehr bietet als eine einfache Liste von Lizenzproblemen und einen klaren Weg zu ihrer Behebung aufzeigt.

Snyk beschreibt Lizenzprobleme beispielsweise im Anwendungskontext statt im Artefaktkontext und zeigt Entwicklern den vollständigen Abhängigkeitsbaum. So können sie genau nachvollziehen, über welchen Pfad die Probleme eingeführt wurden. Das gibt ihnen die nötige Klarheit, um schnell fundierte Entscheidungen zu treffen.

„Kontinuierliche Compliance“

In einer Welt, in der das Wort „kontinuierlich“ nahezu jedem Prozess im modernen Softwareentwicklungszyklus vorangestellt wird, liegt es auf der Hand: Automatisierung ist ein wichtiger Faktor, um Lizenz-Compliance entwicklerfreundlicher zu gestalten. 

Die Automatisierung der Lizenz-Compliance im gesamten SDLC reduziert Reibung und steigert die Produktivität von Entwicklern. CI/CD-Builds, die Lizenztests als Schritt enthalten, sind ein guter Anfang – vorausgesetzt, die Tests sind präzise. Automatisierung ist wichtig. Wenn Builds jedoch aufgrund ungeeigneter Richtlinien immer wieder fehlschlagen, wird wahrscheinlich das Gegenteil erreicht.

Flexible statt starre Governance

Damit Entwicklungsteams mit Zuversicht arbeiten können, ist Transparenz entscheidend. Die Komponenten, die in jede Build-Iteration einfließen, müssen automatisch und konsistent erfasst werden. Dashboards sollten diese Informationen übersichtlich darstellen.

Das gilt für jedes Risikomanagement, ganz besonders aber für die Einhaltung rechtlicher Vorgaben. Unternehmen müssen wissen, was vor sich geht, und können sich nicht allein auf Besprechungen zur Prüfung verlassen – die Informationen müssen in der Technologie verfügbar sein.

Sobald diese Grundlage geschaffen ist, muss in die entscheidende Unterscheidung zwischen verbindlichen und flexiblen Vorgaben der Governance investiert werden.

Jeder Compliance-Beauftragte weiß, dass nicht alles eindeutig ist und manchmal nur der Nachweis zählt, dass angemessene Anstrengungen unternommen wurden. Betrachten wir in unserem Kontext Bereiche, in denen die Sachlage nicht eindeutig ist: Könnte es als „angemessene Anstrengung“ gelten, ein Problem kurz nach der Bereitstellung zu entdecken und dann zu beheben? Oft ist das der Fall. Mit diesem Ansatz lässt sich die Entwicklung weniger stark behindern.

Diese Unterscheidung macht für das Entwicklungsteam einen großen Unterschied. Sie bedeutet, dass Entwickler nicht daran gehindert werden, etwas bereitzustellen, und der Build nicht abgebrochen wird. Stattdessen wird das Compliance-Team darauf hingewiesen, dass eine fragwürdige Lizenz bereitgestellt wurde, damit es den Fall schnell bewerten und über mögliche Maßnahmen entscheiden kann.

Idealerweise hat dieser Austausch parallel stattgefunden. Je besser die Zusammenarbeit zwischen Entwicklungs- und Compliance-Team ist, desto eher findet dieses Gespräch bereits zu Beginn des Entwicklungs-Workflows statt. Doch wenn es erst später erfolgt, muss deshalb nicht sofort die Notbremse gezogen und alles gestoppt werden. Das schafft nur Ablehnung.

Zusammenfassung

In einer Welt, in der Autonomie und Geschwindigkeit für Entwickler immer wichtiger werden, ist Lizenz-Compliance meist alles andere als befähigend. Das muss nicht so sein: Wir können Lizenz-Compliance entwicklerorientiert gestalten.

Snyk unterstützt Entwickler dabei, Lizenz-Compliance anzunehmen: mit einer entwicklerorientierten Lösung, entwicklerfreundlichen Tools, flexibler Governance und durchgängiger Transparenz. Das Ergebnis sind konformere Code-Bestände und letztlich geringere Risiken. Erfahren Sie hier mehr oder legen Sie kostenlos selbst los.