SnykCon-Rückblick: Automatisierung für bessere Compliance und schnelleres Feedback
13. April 2022
0 Min. LesezeitAutomatisierung ist ein wichtiger Bestandteil von DevSecOps, denn sie steigert die Effizienz. Wenn Sie Aufgaben in Ihrem Softwareentwicklungslebenszyklus automatisieren, können Sie mehrere Tools in Ihren Workflow integrieren. Außerdem können sich Entwickler, Maintainer und Security Champions auf kreative Lösungen für anspruchsvolle Probleme konzentrieren, anstatt Zeit mit mühsamen manuellen Aufgaben zu verbringen.
Zwei Präsentationen auf der SnykCon 2021 widmeten sich der Automatisierung. Sam Hodgkinson und Ben Davies von Citrix erläuterten, wie sie die Automatisierung nutzten, um den Genehmigungsprozess für Open-Source-Lizenzen zu optimieren. David Wiggs von Bain gab einen detaillierten Einblick in den Einsatz von Automatisierung für Pipelines as a Service und erklärte, wie sein Team Sicherheit in die CI/CD-Pipeline integrierte. Beide Sessions zeigten, wie sich ein Entwicklungsworkflow mithilfe von Automatisierung stärken lässt.
Genehmigungen für Open-Source-Lizenzen automatisieren
Viele kennen Open-Source-Software, aber deutlich weniger wissen über Open-Source-Lizenzen. Open-Source-Code wird von Entwicklern geschrieben und steht der Öffentlichkeit kostenlos zur Verfügung. Open-Source-Lizenzen legen fest, wie und wann Sie ein Open-Source-Paket nutzen dürfen. Automatisierung kann Open-Source-Lizenzen in Ihrem Code erkennen und analysieren. So erfahren Sie, welche Lizenzbeschränkungen für Open-Source-Pakete gelten. Diese können Sie mit Ihren internen rechtlichen Richtlinien vergleichen, um sicherzustellen, dass Ihr Code einsatzbereit ist.
Die Herausforderung
Die Engineers von Citrix wollten alle Open-Source-Lizenzen in einem Projekt ermitteln und dabei die zahlreichen Paketmanager und Programmiersprachen unterstützen, die im Unternehmen verwendet wurden. Außerdem wollten sie CI/CD-Builds anhand der Lizenz-Compliance blockieren und mit ihrem Rechtsteam zusammenarbeiten, um klarere Richtlinien für alle zu erstellen.
Sam und Ben prüften, wie die Plattform von Snyk sie unterstützen könnte. Ihnen war es wichtig, einen nahtlosen, auf Menschen ausgerichteten Workflow zu schaffen, der für Engineers (und ihr Rechtsteam) keine Probleme verursacht. Außerdem gefielen ihnen die vereinfachten Benutzerinteraktionen, die sie mit den Snyk-Tools entwickeln konnten.
Anschließend prüften sie, ob sich der gesamte Prozess für rechtliche Rahmenbedingungen und Richtlinien in eine automatisierte API integrieren ließe. Dabei sollte die Lösung bei künftigem Bedarf erweiterbar sein.
Mithilfe der Snyk-Ergebnisse konnten Sam und Ben mit ihrer Policy-API Entscheidungen zu Richtlinien treffen und Entwicklern benutzerfreundliches Feedback geben. So konnten diese nachvollziehen, ob Richtlinien genehmigt oder abgelehnt wurden.
Die entwickelte Lösung
Sie erstellten eine CI/CD-Pipeline, die beim Quellcode beginnt und direkt über die Snyk CLI läuft. Snyk analysiert den Quellcode und gibt Lizenzinformationen zurück. Diese Informationen durchlaufen ein Lizenz-Gate, das anhand der Lizenznutzung entscheidet, ob ein Teil des Codes fehlschlagen soll. Code, der das Lizenz-Gate passiert, wird an eine Policy-API gesendet, die mit Ja oder Nein antwortet. (Die Richtlinien stammen vom Rechtsteam von Citrix.) In 90 % der Fälle läuft dieser Prozess vollständig automatisiert ab. In anderen Fällen wird möglicherweise ein Ticket zur manuellen Prüfung durch ein Mitglied des Rechtsteams erstellt. Die Prüfung geht jedoch nicht verloren, sondern fließt zur Genehmigung in die Policy-API zurück. So können Entwickler weiterarbeiten.
„Durch die vollständige Automatisierung dieses Prozesses … haben wir einen Ablauf, der zuvor zwei Wochen dauerte, und die meisten Richtlinienentscheidungen – 90 % davon – auf wenige Sekunden reduziert. Das ist großartig.“

Ben Davies
Software Engineer of Engineering Productivity, Citrix
Citrix entwickelte eine benutzerdefinierte Policy-Engine auf Grundlage eines komplexen rechtlichen Rahmenwerks. Snyk half dem Team, technische Hürden zu überwinden und den Prozess vollständig zu automatisieren. Dadurch wurde Sicherheit in die CI/CD-Pipeline integriert und die Zeit bis zur Lösung verkürzt. Dank des automatisierten Prozesses werden die meisten Richtlinienentscheidungen in Sekunden getroffen. Sam und Ben aktivieren ihre Snyk-Tools jetzt in der Build-Konfiguration; die Technologie erledigt den Rest.
Den Feedback-Kreislauf schließen
Sicherheit in eine Softwareentwicklungspipeline zu integrieren, ist keine neue Idee. Doch häufig konzentrieren sich die Beteiligten auf die technischen Abläufe einer Pipeline und weniger darauf, wie sie tatsächlich genutzt wird. David Wiggs von Bain fragte: Nutzen Entwickler die bereitgestellte Softwareentwicklungspipeline, und erhalten sie damit, was sie brauchen? Betrachten Sie Sicherheitstools und Testtools als _Produkte_, die Entwickler nutzen. Wenn Ihre Pipeline also ein Produkt ist: Können Ihre Nutzer – Ihre Entwickler – erfolgreich damit arbeiten?
Drei Säulen der Automatisierung
Das Modell „Pipeline as a Service“ beginnt mit einem funktionierenden Repository. Als Nächstes können Sie ein Repository für „Custom Actions“ einführen, in dem festgelegt ist, aus welchen Quellen Pipelines ihre Schritte beziehen. Anschließend können Sie ein Repository für Tools einrichten, zum Beispiel einen API-Wrapper, ein Repository-Tool oder eine beliebige toolspezifische Automatisierung.
Diese ersten drei Säulen verringern die Zahl der Orte, an denen Änderungen vorgenommen und nachverfolgt werden. Wenn Nutzer Verbesserungsvorschläge für Ihren Prozess machen, können Sie diese Änderungen zentral vornehmen, statt sie an mehreren Stellen zu wiederholen.
Den Workflow ausführen
Mit diesem Aufbau sind Sie für die folgenden Schritte gerüstet:
Der Pipeline-Workflow wird ausgelöst (stellen Sie sich das als Ausführung einer Pipeline vor). Das Repository für Custom Actions wird ausgecheckt.
Die Datei
action.ymlcheckt ein Repository für ein bestimmtes Sicherheitstool aus.Die toolspezifischen Skripte werden ausgeführt. So werden Feature-Anfragen oder Aktualisierungen an einem zentralen Ort vorgenommen, und alle, die eine Custom Action verwenden, übernehmen die Änderung.
Sehen wir uns dieselbe Pipeline-Architektur nun von unten nach oben an – beginnend mit dem Repository für Sicherheitstools. Dieses Repository kann Skripte enthalten, die mehrere Funktionen bereitstellen. Beispielsweise könnten Sie ein PowerShell-Skript aufrufen, das mithilfe der Snyk API prüft, ob ein bestimmtes Repository auf der Snyk-Plattform vorhanden ist, und es andernfalls importiert. Dabei werden einige Skripte ausgeführt, während die übrige Architektur dafür sorgt, dass diese Skripte in einem bestimmten Arbeits-Repository übernommen werden.
Gehen wir nun eine Ebene nach oben. Das Repository für Custom Actions checkt das Repository für Sicherheitstools aus und führt ein sicherheitsspezifisches Skript aus. Mit Composite Actions können Sie mehrere Befehle als einzelnen Schritt orchestrieren. Dadurch entsteht eine Abstraktionsebene, die die Nutzererfahrung vereinfacht und Ihnen zugleich ermöglicht, mehrere Skripte aufzurufen und Abhängigkeiten einzuführen.
Dies geschieht in der Datei action.yml. Mit ihr können Sie Versionen festlegen, ohne unbedingt Änderungen an mehreren Arbeits-Repositories vornehmen zu müssen.
Auf der obersten Ebene ermöglichen Sie einem Arbeits-Repository den Zugriff auf die GitHub Custom Action. Beim Start des Workflows im Arbeits-Repository wird das Repository für Custom Actions ausgecheckt und dessen Inhalt in die Laufzeitumgebung übernommen. Anschließend führen Sie erneut einen verschachtelten Checkout durch. So können Sie die Datei action.yml und die Skripte aus dem Tool-Repository in der Laufzeitumgebung des Arbeits-Repositorys nutzen.
„[Sicherheit in die Pipeline zu integrieren] ist eine großartige Möglichkeit, Entwicklerinnen und Entwicklern diese Informationen bereitzustellen, ohne dass sie dafür unbedingt ihre zentrale Arbeitsumgebung verlassen müssen.“
David Wiggs
Manager, Bain
Aus Sicht der Nutzer haben Sie mehrere benutzerdefinierte Skripte eingeführt – und zwar auf eine „native“ Weise. Mithilfe von GitHub Actions haben Sie Sicherheit mit Snyk-Tools in die Pipeline integriert. Wenn GitHub Actions Sicherheitstools in eine Pipeline integrieren können, müssen Entwickler ihre gewohnte Arbeitsumgebung (GitHub) nicht verlassen, um Sicherheitsinformationen zu ihrem Entwicklungsprozess zu erhalten. Sie haben im Hintergrund einen schnelleren Feedback-Kreislauf geschaffen, ohne Entwickler dazu aufzufordern, Änderungen an mehreren Stellen vorzunehmen.
Automatisierung für bessere Workflows nutzen
Automatisierung kann die Effizienz in Ihrem Unternehmen steigern. Diese Präsentationen zeigen zwei Beispiele dafür, wie Sie Automatisierung zu Ihrem Vorteil einsetzen können – doch es gibt noch viele weitere. Die Plattform von Snyk bietet zahlreiche Tools, mit denen Sie Automatisierung in Ihre Workflows integrieren und Sicherheitsstandards nahtlos in Ihren Entwicklungsprozess einbinden können.
