Eine sichere CI/CD-Pipeline für Ihre Java-Anwendung mit GitHub Actions erstellen

Mit GitHub Actions ist es einfacher denn je, eine sichere Continuous-Integration- und Continuous-Delivery-Pipeline (CI/CD) für Ihre GitHub-Projekte aufzubauen. Durch die Integration Ihrer CI/CD-Pipeline und Ihres GitHub-Repositorys können Sie mit GitHub Actions den Build-, Test- und Deployment-Prozess automatisieren. Sie können Workflows erstellen, die jeden Pull Request an Ihr Repository erstellen und testen oder zusammengeführte Pull Requests in Produktion bereitstellen. Wenn Sie Snyk in Ihre GitHub-CI/CD integrieren, können Sie Sicherheitsscans als Teil Ihres Build-Zyklus automatisieren, bevor Ihre Anwendung in Produktion geht.

Eine GitHub-Actions-CI-Pipeline für Java einrichten

GitHub-Actions-Workflows sind YAML-Dateien im Ordner .github/workflows. Wenn Sie noch keinen Workflow haben oder einen neuen hinzufügen möchten, wählen Sie Actions und New workflow aus.

Für dieses Java-Spring-Boot-Projekt habe ich mit Maven folgende CI-Pipeline erstellt:

1name: Java CI with Maven
2
3on:
4 push:
5   branches: [ master ]
6 pull_request:
7   branches: [ master ]
8 workflow_dispatch:
9
10jobs:
11 build:
12
13   runs-on: ubuntu-latest
14
15   steps:
16   - uses: actions/checkout@v2
17   - name: Set up JDK 17
18     uses: actions/setup-java@v1
19     with:
20       java-version: 17
21   - name: Build with Maven
22     run: mvn -B package --file pom.xml

Diese Action wird bei jedem Push und Pull Request an den Master-Branch ausgeführt. Sie basiert auf Ubuntu und checkt das Repository aus. Dabei verwendet sie die GitHub Action setup-java mit Java 17 und Maven, um die Java-JAR-Datei zu erstellen. Wenn Sie mit der Syntax vertraut sind, ist dieser Workflow recht einfach zu verstehen. Einen vollständigen Überblick über die Möglichkeiten finden Sie in der GitHub-Actions-Dokumentation.

Snyk in Ihre GitHub-CI/CD integrieren

Mit Snyk können Sie Sicherheitstests in Ihr neues Java-Projekt integrieren. Dafür gibt es zwei Hauptmethoden. Zuvor sollten Sie jedoch zwei Dinge einrichten. Melden Sie sich zunächst bei Ihrem Snyk-Konto an oder erstellen Sie kostenlos ein Konto, falls Sie noch keines haben. Legen Sie anschließend Ihren API-Schlüssel als Secret SNYK_TOKEN für Ihr GitHub-Repository fest.

Option 1: Die Snyk CLI in einen Build-Schritt Ihrer GitHub Action integrieren

Mit der Snyk CLI können Sie Sicherheitsscans automatisch während Ihres aktuellen Builds ausführen. Folgen Sie den nachstehenden Schritten – einschließlich der zusätzlichen Schritte nach Build with Maven –, um loszulegen.

1 - name: Set up Node 14
2   uses: actions/setup-node@v3
3   with:
4     node-version: 14
5 - name: install Snyk CLI
6   run: npm install -g snyk
7 - name: run Snyk Open Source Test
8   run: snyk test
9 - name: run Snyk Code Test
10   run: snyk code test

Richten Sie NodeJS Version 14 ein und laden Sie die Snyk CLI mit npm herunter. Analysieren Sie anschließend Ihre Abhängigkeiten mit Snyk Open Source und scannen Sie Ihren eigenen Code mit Snyk Code auf Sicherheitslücken.

Deklarieren Sie dann SNYK_TOKEN als Umgebungsvariable, die Ihren API-Schlüssel enthält. Sie können auf das zuvor eingerichtete Secret SNYK_TOKEN verweisen oder den vollständigen Code der GitHub Action wiederverwenden.

1env:
2 SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

Der Vorteil dieses Ansatzes ist, dass Sie Ihre Anwendung nur einmal kompilieren und erstellen müssen. Das kann beim Erstellen großer Anwendungen viel Zeit sparen. Der Nachteil: Die Schritte werden nacheinander ausgeführt und sind möglicherweise nicht effizient, wenn einer der späteren Schritte fehlschlägt.

Option 2: Die vordefinierten GitHub Actions von Snyk für Ihre CI/CD-Pipeline verwenden

Snyk hat eine Reihe von GitHub Actions erstellt, die Ihre Projekte auf Sicherheitslücken prüfen. Welche Action Sie benötigen, hängt von Ihrer Programmiersprache oder Ihrem Build-Tool ab. Für unser Java-Projekt verwenden wir beispielsweise die unten gezeigte Maven-basierte GitHub Action.

Die vordefinierten Actions stellen sicher, dass alle Voraussetzungen für den Build Ihrer Anwendung erfüllt sind, und enthalten die neueste CLI-Version zum Scannen Ihres Codes. Auch wenn Sie Ihre Anwendungen möglicherweise mehrmals neu erstellen, können diese Actions einzeln und parallel ausgeführt werden – ein wesentlicher Vorteil dieses Ansatzes.

Beginnen wir mit dem Scannen unserer Abhängigkeiten. Wir haben bereits ein Snyk-Konto und unseren API-Schlüssel als Secret mit dem Namen SNYK_TOKEN gespeichert. Erstellen Sie daher keinen zusätzlichen Schritt im Build-Job, sondern einen neuen Job namens opensource-security.

1opensource-security:
2   runs-on: ubuntu-latest
3   steps:
4     - uses: actions/checkout@master
5     - name: Run Snyk to check for vulnerabilities
6       uses: snyk/actions/maven@master
7       env:
8         SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

Laut Dokumentation lautet der Standardbefehl test. Ohne zusätzliche Konfiguration scannt er Ihre Anwendung auf bekannte Sicherheitslücken in den Abhängigkeiten. Wenn Sie ein bestimmtes CLI-Argument wie --all-projects verwenden möchten, um verschachtelte Projekte zu berücksichtigen, nutzen Sie das Schlüsselwort with und setzen Sie die Eigenschaft auf args.

Während Snyk unsere Abhängigkeiten scannt, prüfen wir den Java-Code in unserer GitHub Action auf Sicherheitslücken. Wiederholen Sie dazu den vorherigen Vorgang, richten Sie einen dritten Job speziell dafür ein und setzen Sie die Eigenschaft command auf code test.

1 code-security:
2   runs-on: ubuntu-latest
3   steps:
4     - uses: actions/checkout@master
5     - name: Run Snyk to check for vulnerabilities
6       uses: snyk/actions/maven@master
7       env:
8         SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
9       with:
10         command: code test

Beachten Sie, dass alle drei Jobs parallel ausgeführt werden, was in vielen Fällen effizienter ist.

Sichere Continuous Delivery in Ihre GitHub-CI/CD integrieren

Sehen wir uns nun den Deployment- beziehungsweise Delivery-Teil Ihrer GitHub-CI/CD an. Sobald Build und Tests abgeschlossen sind, wird das Paket auf GitHub veröffentlicht. Dafür verwenden wir in unserem Java-Projekt das Maven-Release-Plugin.

Da wir das Paket nur veröffentlichen möchten, wenn der Build-Job und beide Sicherheits-Jobs erfolgreich abgeschlossen wurden, fügen wir eine Eigenschaft needs mit einer Liste der vorausgesetzten Jobs für die Veröffentlichung hinzu. So stellen wir sicher, dass unser Paket erst bereitgestellt wird, wenn es vollständig erstellt und abgesichert ist.

1release:
2   needs: [opensource-security, code-security, build]
3   runs-on: ubuntu-latest
4   steps:
5     - uses: actions/checkout@v2
6     - name: Set up JDK 17
7       uses: actions/setup-java@v1
8       with:
9         java-version: 17
10     - name: Set Git user
11       run: |
12         git config user.email "ghactions@brianvermeer.nl"
13         git config user.name "GitHub Actions"
14     - name: Publish JAR
15       run: mvn -B release:prepare release:perform -DskipTests
16       env:
17         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Die Maven-Befehle release:prepare und release:perform überprüfen, ob die Veröffentlichung die richtige Versionsnummer hat, und veröffentlichen sie in unserem GitHub-Repository. Da wir Maven diese Aufgabe überlassen, nehmen Sie die folgenden Konfigurationen in Ihrer Datei pom.xml vor.

1  <scm>
2       <developerConnection>scm:git:https://github.com/bmvermeer/ghaction-example.git</developerConnection>
3       <tag>HEAD</tag>
4   </scm>
5   <distributionManagement>
6       <repository>
7           <id>github</id>
8           <name>GitHub</name>
9           <url>https://maven.pkg.github.com/bmvermeer/ghaction-example</url>
10       </repository>
11   </distributionManagement>

Auch wenn unsere neu veröffentlichte Anwendung derzeit frei von Sicherheitslücken ist, heißt das nicht, dass sie dauerhaft sicher bleibt. Neue Sicherheitslücken können an verschiedenen Stellen auftreten. Deshalb ist es wichtig, Ihren Code und Ihre Abhängigkeiten auch nach dem Deployment einer Anwendung kontinuierlich zu überwachen.

Zusätzlich zu den Scans während der Entwicklung können wir mit Snyk auch Abhängigkeiten nach dem Deployment überwachen. Wenn die Veröffentlichung abgeschlossen ist, verwenden Sie erneut die vordefinierte Snyk Action. Setzen Sie diesmal die Eigenschaft command auf monitor.

1 opensource-monitor:
2   needs: [release]
3   runs-on: ubuntu-latest
4   steps:
5     - uses: actions/checkout@master
6     - name: Run Snyk to check for vulnerabilities
7       uses: snyk/actions/maven@master
8       env:
9         SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
10       with:
11         command: monitor

Dadurch wird der nach der Veröffentlichung unveränderliche Abhängigkeitsbaum zur Überwachung an Snyk übermittelt. Nun können wir unser Projekt in der Snyk-Benutzeroberfläche aufrufen und automatische Benachrichtigungen erhalten, wenn eine neue Sicherheitslücke in einer unserer Abhängigkeiten gefunden wird. So stellen wir sicher, dass unser veröffentlichtes Java-Projekt frei von Sicherheitslücken bleibt.

Sicherheit in Ihre GitHub Actions integrieren

Mit GitHub Actions lässt sich eine CI/CD-Pipeline für Ihr GitHub-Projekt ganz einfach erstellen. Mit den Snyk Actions können Sie außerdem unkompliziert Sicherheits-Scans auf mehreren Ebenen in alle Ihre Anwendungen integrieren.

GitHub veranschaulicht die Pipeline, die wir heute erstellt haben, mit der folgenden Abbildung. Einige Jobs laufen parallel, während andere erst nach dem erfolgreichen Abschluss anderer Jobs ausgeführt werden. Das vollständige Beispielprojekt finden Sie in diesem GitHub-Repository.

Heute haben wir Snyk Code und Snyk Open Source verwendet, um den Java-Quellcode und die Pipeline-Abhängigkeiten zu scannen. Sie können den Ansatz jedoch erweitern und Docker-Dateien mit Snyk Container sowie Kubernetes-Dateien mit Snyk IaC scannen.

Mit den Snyk GitHub Actions können Sie Ihrer GitHub-Actions-Workflow automatisch Scans hinzufügen und die Actions passend zu Ihrem Projekt kombinieren. So bleibt Ihr Code heute und in Zukunft sicher.