SnykCon Top-Insights: Automatisierung für konsequente Compliance und agile Feedback-Loops

Eine der Kernsäulen für die Umsetzung einer modernen DevSecOps-Kultur ist Automatisierung. Denn erst sie sorgt für die nötige Effizienz, um verschiedene Prozesse innerhalb des SDLC nahtlos abwickeln und diverse Tools in Dev-Workflows integrieren zu können. Hierdurch wiederum wird es Entwicklern und Maintainern wie auch Security Champions möglich, komplexe Problemstellungen durch kreative Lösungen zu adressieren und sich so mühseliger manueller Aufgaben zu entledigen.

Automatisierung gehörte freilich auch zu den Fokusthemen auf der SnykCon 2021. Etwa in einem Gespräch mit den Citrix Software Engineers Sam Hodgkinson und Ben Davies, bei dem es um die Automatisierung von Genehmigungsprozessen für Open-Source-Lizenzen ging. Daneben begeisterte David Wiggs vom Consulting-Unternehmen Bain in einem Deep-Dive dazu, wie er und sein Team gestützt auf Automatisierung ein Konzept für Pipeline as a Service umsetzen und dabei auch Security-Themen durchgängig in CI/CD-Prozesse integrieren konnten. Die wichtigsten Insights dazu, wie diese Automatisierung in ihre Dev-Workflows brachten, haben wir im Folgenden für Sie zusammengefasst.

Auto-Genehmigung von Open-Source-Lizenzen

Was Open Source im Software-Kontext bedeutet, ist den meisten wohlbekannt. Etwas anders sieht es dagegen mit der zugehörigen Lizenzierung aus. Der Code, auf dem Open-Source-Software basiert, ist das Ergebnis des Engagements der weltweiten Dev-Community und wird zur Nutzung frei zur Verfügung gestellt. Dies aber unterliegt einer spezifischen Lizenz, die regelt, wie und für welche Szenarien ein entsprechendes Open-Source-Paket genutzt werden darf. Genau hier wollten Hodgkinson und Davies bei Citrix ansetzen: Gestützt auf Automatisierung sollten Entwickler ihren Code dahingehend analysieren können, welche Open-Source-Pakete darin eingebunden sind und welchen Lizenzen sie unterliegen. So wiederum würde sich erkennen lassen, ob lizenzrechtliche Einschränkungen der jeweils genutzten Open-Source-Pakete mit den unternehmensinternen Policy-Frameworks vereinbar sind oder nicht, bevor der Code ins Deployment geht.

Herausforderungen auf dem Weg dorthin

Ihre Ziele hatten die beiden Citrix Engineers klar abgesteckt: sämtliche Open-Source-Lizenzen innerhalb ihrer Projekte identifizieren, dies übergreifend für die diversen Package-Manager und Programmiersprachen, die in den Dev-Prozessen des Unternehmens zum Einsatz kommen. Ergänzt werden sollte dies zudem um einen Mechanismus, der die Freigabe von CI/CD-Builds erst nach verifizierter Lizenz-Compliance zulassen würde. Hierzu wiederum sollte das Legal-Team entsprechende Policies nahtlos und für alle Teams klar nachvollziehbar einrichten können.

Für die Umsetzung erwies sich die Plattform von Snyk als ideal: Sie bot nahtlose Workflows und entsprechend keine Reibungspunkte oder Bremsen für Entwickler und Legal-Teams, außerdem ließen sich mit den Toolsets effiziente Interaktionsketten zwischen allen Beteiligten einrichten.

Darauf aufbauend wollte man zudem den gesamten Prozess rund um Policies für verschiedene Compliance-Frameworks in eine automatisierte API überführen. Hierdurch würde man dann auch auf künftige Anforderungen adaptiv reagieren können.

Konzeptionell umsetzen ließ sich dies anhand von Daten aus der Snyk Plattform, die die beiden Engineers in eine Entscheidungslogik innerhalb ihrer Policy-API einspeisten. So wurde es möglich, Entwicklern direkt in ihren Workflows konkret umsetzbares Feedback dazu zu geben, ob in ihrem Code genutzte Lizenzen genehmigt wurden oder nicht.

Methodik der Lösung

Die Citrix Engineers zogen eine CI/CD-Pipeline auf, innerhalb derer der Quellcode zunächst an der Snyk CLI analysiert wird. Die so ermittelten Lizenzdaten gehen dann an ein Security Gate, an dem entschieden wird, ob der Code entsprechend den in ihm genutzten Lizenzen abgewiesen oder freigegeben wird. Entschieden wird dies durch die am Gate implementierte Policy-API, gemäß den vom Legal-Team definierten Vorgaben. In 90 % der Fälle läuft dieser Prozess komplett automatisch ab, bei spezifischeren Fragen kann das Legal-Team via Ticket zur manuellen Prüfung eingeschaltet werden. Interessant hierbei: Das Ergebnis einer solchen Prüfung geht nicht verloren, sondern fließt ebenfalls in die Policy-API ein. So können Entwickler einen gleich gelagerten Fall künftig ohne Unterbrechung ihrer Arbeit abschließen.

„Den Prozess haben wir komplett automatisiert – inklusive 90 % der Policy-Entscheidungen. Ein Vorgang, der sich früher über 2 Wochen hinzog, ist damit in nicht mehr als ein paar Sekunden abgeschlossen. Einfach phänomenal!“

Herzstück dieses Konzepts bildet eine Policy-Engine, in die es ein hochkomplexes lizenzrechtliches Framework komplett custom zu integrieren galt. Nicht zuletzt auch dank der professionellen Unterstützung der Teams von Snyk meisterte man dies mit Bravour, ebenso wie technische Hürden rund um die Automatisierung sämtlicher Security-Prozesse innerhalb der CI/CD-Pipeline. Im Ergebnis ließ sich so auch die Lösungszeit deutlich verkürzen: Policy-Entscheidungen werden binnen Sekunden über die Engine abgewickelt, und da die Technologie von Snyk in die Build-Konfiguration eingebettet ist, erfolgt auch an diesem Ende alles autonom ohne manuelle Eingriffe.

Feedback-Loop smart umgesetzt

Die Integration von Security-Prozessen in die Dev-Pipeline ist per se nichts Neues. Häufig liegt der Fokus dabei aber auf der strukturellen Funktionsweise der Pipeline und nicht darauf, wie sie sich in der Praxis gestaltet wird. So jedenfalls lautete Wiggs’ Befund bei Bain. Deshalb war für ihn die Frage danach wichtig, wie Entwickler innerhalb der Dev-Pipeline arbeiten und ob dies im Einklang mit ihren Anforderungen stand. Die Pipeline selbst wie auch darin eingebundene Security- und Testing-Tools sieht er dabei gewissermaßen als Produkt. Und wie bei Produkten üblich muss die Zufriedenheit bzw. der Erfolg der Verbraucher mit ihnen optimiert werden.

Automatisierung in drei Akten

Ausgangspunkt von Wiggs’ Modell für Pipeline as a Service ist ein sogenanntes „Working“-Repository. Diesem stellt er ein eigens für nutzerspezifische Aktionen eingerichtetes „Custom Action“-Repository beiseite, aus dem verschiedene Pipelines Arbeitsschritte abrufen können. Dazu kommt noch ein weiteres Repository, über das API-Wrapper sowie Repository-, beliebige Automatisierungs- und weitere Tools zur Verfügung gestellt werden.

Durch dieses Dreigespann werden Änderungen auf einen minimalen Wirkungskreis eingegrenzt und somit alles klar nachvollzieh- und dokumentierbar. So können etwa Verbesserungen, die vonseiten der Nutzer eingebracht werden, zentralisiert umgesetzt werden. Dadurch entfallen repetitive Aufgaben im Zusammenhang damit, diese an anderer Stelle ebenfalls implementieren zu müssen.

Ablauf im Workflow

Ausgehend von dieser Grundstruktur erfolgen nun die folgenden Schritte:

1. Startpunkt für Workflow ist eine sogenannte „Executing“-Pipeline, die durch die nutzerseitig definierte Aktion aus dem Repository für Custom Actions ausgelöst wird.

2. Über eine Datei namens action.yml wird ein speziell für Security-Tools eingerichtetes Repository abgerufen,

3. zudem werden toolspezifische Scripts ausgeführt. Hierdurch werden Feature-Anfragen oder -Updates zentralisiert: Alle, die Custom Actions nutzen, übernehmen die entsprechenden Änderungen automatisch.

Spannend auch, wie sich die Pipeline-Architektur am anderen Ende des Workflows gestaltet: Ausgehend vom Repository für Security-Tools lassen sich scriptbasiert flexibel Funktionen definieren. So etwa ein PowerShell-Script, das die Snyk API aufruft, um auf der Snyk Plattform die Verfügbarkeit eines gewünschten Repository zu prüfen. Ist dies nicht verfügbar, löst es dessen Import aus. In diesem Prozess führt Wiggs eine Reihe von Scripts aus, eine Reihe weiterer Elemente der Architektur macht die Übernahme der Scripts für beliebige Working-Repositories möglich.

Auf der nächsten Ebene liest das Repository für benutzerspezifische Aktionen das Repository für Sicherheitstools aus und führt aus ihm ein Script aus. Zur Orchestrierung mehrere Befehle konsolidiert in einem Schritt nutzt Wiggs dabei Composite Actions. Auf diese Weise entsteht eine Abstraktionsebene, die zu einer besseren UX beiträgt. Außerdem lassen sich dort verschiedene Scripts ausführen und Abhängigkeiten einbinden.

All dies erfolgt innerhalb der Datei action.yml, wodurch Versionierung möglich und es somit vermieden wird, Änderungen an einer Vielzahl von Working-Repositories vornehmen zu müssen.

Auf oberster Ebene hat ein Working-Repository dabei Zugriff zu einer in GitHub definierten Custom Action. So gewährleistet Wiggs, dass bei der Initialisierung des Working-Repository das Repository für Custom Actions abgerufen und dessen Inhalte in die Runtime überführt werden. Mittels Nested Checkout ermöglicht es Wiggs dabei, über die Datei action.yml und die Scripts im Tool-Repository auszuführen – dies direkt innerhalb der Runtime des Working-Repository.

Auf Nutzerseite wird so zwar eine Vielzahl von Scripts ausgeführt, doch gewissermaßen nativ. Denn Security-Checks über die Tools von Snyk sind via GitHub Actions implementiert. Dies bedeutet, dass Entwickler GitHub und damit ihre gewohnte Umgebung nicht verlassen müssen, zugleich aber Security-Insights direkt im Dev-Prozess erhalten. Das Ergebnis ist ein agiler Feedback-Loop von A bis Z – ganz ohne die Erfordernis, dass Entwickler an verschiedenen Punkten Änderungen einarbeiten müssen.

Kreativ und flexibel zu mehr Automatisierung

Automatisierte Workflows lassen sich in verschiedener Weise für mehr Effizienz in Ihren Workflows umsetzen. Die hier ausgeführten Konzepte zeigen dies eindrucksvoll, sind jedoch nur Beispiele für die verschiedensten Möglichkeiten, die die Plattform von Snyk in diesem Kontext bietet – von der Automatisierung Ihrer Workflows bis zur nahtlosen Integration und Erfüllung von Security- und Compliance-Standards.