Créer un pipeline CI/CD sécurisé avec GitHub Actions pour votre application Java

GitHub Actions n’a jamais rendu aussi simple la création d’un pipeline d’intégration et de livraison continues (CI/CD) sécurisé pour vos projets GitHub. En intégrant votre pipeline CI/CD à votre dépôt GitHub, GitHub Actions vous permet d’automatiser le processus de build, de test et de déploiement. Vous pouvez créer des workflows qui compilent et testent chaque pull request envoyée à votre dépôt, ou déploient en production les pull requests fusionnées. En intégrant Snyk à votre CI/CD GitHub, vous pouvez automatiser l’analyse de sécurité au cours du cycle de build, avant la mise en production.

Configurer un pipeline CI GitHub Actions pour Java

Les workflows GitHub Actions sont des fichiers YAML dans le dossier .github/workflows. Si vous n’avez pas encore de workflow ou souhaitez en ajouter un, sélectionnez Actions, puis Nouveau workflow.

Pour ce projet Java Spring Boot, j’ai créé un pipeline CI avec Maven comme suit :

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

Cette action s’exécute à chaque push ou pull request sur la branche master. Basée sur Ubuntu, elle récupère le dépôt et utilise l’action GitHub setup-java — avec Java 17 et Maven — pour créer le fichier JAR Java. Si vous connaissez la syntaxe, ce workflow est relativement simple, mais vous pouvez consulter la documentation GitHub Actions pour découvrir toutes les possibilités.

Intégrer Snyk à votre CI/CD GitHub

Avec Snyk, vous pouvez intégrer des tests de sécurité à votre nouveau projet Java. Il existe deux méthodes principales pour cela. Mais commençons par vérifier que deux éléments sont configurés. Connectez-vous à votre compte Snyk — ou créez-en un gratuitement si ce n’est pas déjà fait. Définissez ensuite votre clé API comme secret SNYK_TOKEN pour votre dépôt GitHub.

Option 1 : intégrer l’interface de ligne de commande Snyk à une étape de build de votre GitHub Action

Vous pouvez utiliser l’interface de ligne de commande Snyk pour lancer automatiquement des analyses de sécurité dans votre build actuel. Suivez les étapes ci-dessous — y compris les quelques étapes supplémentaires après Build with Maven — pour commencer.

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

Configurez NodeJS version 14 et téléchargez l’interface de ligne de commande Snyk avec npm. Analysez ensuite vos dépendances avec Snyk Open Source et utilisez Snyk Code pour rechercher des vulnérabilités dans votre code personnalisé.

Déclarez ensuite SNYK_TOKEN comme variable d’environnement contenant votre clé API. Vous pouvez utiliser le secret SNYK_TOKEN que vous avez configuré précédemment, ou reprendre l’exemple complet de code de la GitHub Action.

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

L’avantage de cette approche est que vous n’avez à compiler et à builder votre application qu’une seule fois, ce qui peut vous faire gagner beaucoup de temps pour les applications volumineuses. En revanche, les étapes s’exécutent en série et peuvent se révéler inefficaces si l’une des dernières échoue.

Option 2 : utiliser les GitHub Actions prédéfinies de Snyk pour créer votre pipeline CI/CD

Snyk a créé un ensemble de GitHub Actions pour détecter les vulnérabilités dans vos projets. L’action à utiliser dépend de votre langage de programmation ou de votre outil de build. Pour notre projet Java, nous allons par exemple utiliser l’action GitHub basée sur Maven présentée ci-dessous.

Les actions prédéfinies vous garantissent de disposer des prérequis nécessaires au build de votre application et incluent la dernière version de l’interface de ligne de commande pour analyser votre code. Même si vous devez builder vos applications plusieurs fois, ces actions peuvent s’exécuter individuellement et en parallèle — un avantage considérable de cette approche.

Commençons par analyser nos dépendances. Nous avons déjà un compte Snyk et notre clé API est stockée sous forme de secret nommé SNYK_TOKEN. Plutôt que d’ajouter une étape supplémentaire au job de build, créons un nouveau job nommé 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 }}

Selon la documentation, la commande par défaut est test. Sans configuration supplémentaire, elle analyse votre application à la recherche de vulnérabilités connues dans vos dépendances. Pour définir un argument CLI spécifique, comme --all-projects afin de prendre en charge les projets imbriqués, utilisez le mot-clé with et définissez la propriété args.

Pendant que Snyk analyse nos dépendances, vérifions la présence de vulnérabilités dans le code Java de notre GitHub Action. Pour cela, répétez le processus précédent en configurant un troisième job dédié, puis définissez la propriété command sur 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

Notez que les trois jobs s’exécutent en parallèle, ce qui est souvent plus efficace.

Ajouter une livraison continue sécurisée à votre CI/CD GitHub

Abordons maintenant la partie déploiement — ou livraison — de votre CI/CD GitHub. Une fois le build et les tests terminés, il est temps de publier le package sur GitHub. Pour cela, nous allons utiliser le plug-in Maven Release dans notre projet Java.

Nous voulons publier le package uniquement une fois le job de build et les deux jobs de sécurité terminés avec succès. Nous allons donc ajouter une propriété needs contenant la liste des jobs prérequis à la publication. Nous pouvons ainsi nous assurer que le package n’est pas déployé avant d’avoir été entièrement compilé et sécurisé.

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 }}

Les commandes Maven release:prepare et release:perform vérifient que la version de la publication est correcte et publient effectivement le package dans notre dépôt GitHub. Puisque nous confions cette tâche à Maven, apportez les modifications suivantes à votre fichier pom.xml.

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>

Même si notre application nouvellement publiée ne présente actuellement aucune vulnérabilité, rien ne garantit qu’elle restera sécurisée indéfiniment. De nouvelles vulnérabilités peuvent apparaître à différents endroits. Il est donc essentiel de surveiller en continu votre code et vos dépendances après le déploiement de l’application.

En plus des analyses effectuées pendant le développement, vous pouvez aussi utiliser Snyk pour surveiller les dépendances après le déploiement. Une fois la publication terminée, utilisez à nouveau l’action Snyk prédéfinie, mais définissez cette fois la propriété command sur 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

L’arborescence des dépendances, qui reste statique après la publication, sera alors envoyée à Snyk pour être surveillée. Vous pouvez désormais consulter votre projet dans l’interface Snyk et recevoir automatiquement des notifications si une nouvelle vulnérabilité est détectée dans l’une de vos dépendances. Vous vous assurez ainsi que votre projet Java publié reste exempt de vulnérabilités.

Intégrer la sécurité à vos GitHub Actions

Avec GitHub Actions, créer un pipeline CI/CD pour votre projet GitHub est très simple. Et grâce aux actions Snyk, vous pouvez facilement intégrer des analyses de sécurité à plusieurs niveaux pour toutes vos applications.

GitHub représente dans l’image ci-dessous le pipeline que nous avons créé aujourd’hui. Certains jobs s’exécutent en parallèle, tandis que d’autres dépendent de la réussite d’autres jobs. Vous pouvez consulter le projet complet dans ce dépôt GitHub.

Aujourd’hui, nous avons utilisé Snyk Code et Snyk Open Source pour analyser le code source Java et les dépendances du pipeline. Vous pouvez également étendre cette approche en analysant les fichiers Docker avec Snyk Container et les fichiers Kubernetes avec Snyk IaC.

Avec les Snyk GitHub Actions, vous pouvez ajouter automatiquement des analyses à votre workflow GitHub Actions et combiner les actions selon les besoins de votre projet, afin de garantir la sécurité de votre code aujourd’hui et à l’avenir.