Comment intégrer vos propres scanners de sécurité dans GitLab

GitLab, la plateforme DevSecOps la plus complète, dispose de toutes les fonctionnalités nécessaires pour planifier, gérer, compiler, déployer, sécuriser, gouverner et surveiller vos applications. Vous pouvez toutefois utiliser en complément des outils tiers ou personnalisés, par exemple si vous devez migrer vers une plateforme DevSecOps à partir de solutions distinctes, évaluer des outils tiers ou intégrer des solutions propriétaires ou personnalisées dans GitLab.

Extensibilité de la plateforme DevSecOps de GitLab

La plateforme DevSecOps de GitLab peut être enrichie de nombreuses façons afin de prendre en charge les fonctionnalités améliorées dont votre entreprise a besoin.

Voici quelques exemples d'intégrations courants :

• Intégrations d'applications externes, telles que Jenkins et Slack
• Intégrations de systèmes externes de gestion des tickets, tels que Bugzilla et Jira
• Intégrations de fournisseurs d'authentification externes, tels que LDAP et SAML
• Intégrations de scanners de sécurité externes, tels que Fortify et Checkmarx
• Détection et gestion de secrets exposés, tels que les clés d'accès AWS et GCP

Consultez notre documentation pour connaître toutes les intégrations disponibles (liste non exhaustive).

Intégration de scanners de sécurité dans GitLab

Il est possible d'intégrer des scanners de sécurité tiers ou des scanners de sécurité personnalisés dans GitLab. Ces scanners peuvent ainsi alimenter plusieurs sections clés de l'interface GitLab, telles que le widget de sécurité des merges requests, la section Sécurité des pipelines, le rapport de vulnérabilités, les pages de vulnérabilités, le tableau de bord de sécurité ainsi que les politiques d'approbation des merge requests.

Passons en revue chacune de ces intégrations.

Widget de sécurité des merge requests

Une merge request contient un widget de sécurité qui affiche un résumé des vulnérabilités récemment détectées.

Widget de sécurité des merge requests

Lorsque vous cliquez sur une vulnérabilité, la fenêtre contextuelle qui s'affiche contient les informations suivantes :

• Statut
• Description
• Projet
• Fichier
• Identifiants
• Gravité
• Outil
• Fournisseur du scanner

Vulnérabilités exploitables et détails associés

Ces vulnérabilités sont également exploitables, ce qui signifie qu'elles peuvent être rejetées ou qu'un ticket confidentiel peut être créé.

Les résultats d'un scanner personnalisé peuvent être utilisés pour alimenter le widget de sécurité. Les données de vulnérabilité sont renseignées à partir du schéma JSON généré par le scanner.

Section Sécurité des pipelines

Tous les scanners de sécurité activés s'exécutent dans le pipeline et génèrent leurs résultats sous forme d'artefacts qui font l'objet d'un traitement (déduplication incluse). Les résultats sont ensuite répertoriés dans l'onglet Sécurité des pipelines. À partir de là, vous pouvez également télécharger les fichiers JSON générés.

Onglet Sécurité des pipelines

Les résultats d'un scanner personnalisé peuvent être utilisés pour alimenter l'onglet Sécurité des pipelines. Les colonnes sont remplies à l'aide du schéma JSON émis par le scanner.

Rapport de vulnérabilités

Le rapport de vulnérabilités fournit des informations sur les vulnérabilités issues des scans de la branche par défaut, notamment :

• Le nombre total de vulnérabilités par niveau de gravité
• Les filtres d'attributs de vulnérabilité courants
• Les détails de chaque vulnérabilité, présentés sous forme de tableau

Rapport de vulnérabilités

Les résultats d'un scanner personnalisé sur la branche par défaut peuvent être utilisés pour alimenter le rapport de vulnérabilités.

Pages de vulnérabilités

En cliquant sur une vulnérabilité présente dans le rapport de vulnérabilités, vous accédez à une page dédiée comprenant les informations suivantes :

• sa description
• la date de détection
• son statut actuel
• son emplacement
• les actions disponibles pour y remédier
• les tickets liés à cette vulnérabilité
• le log des actions effectuées sur cette vulnérabilité
• les solutions proposées
• un identifiant
• des ressources de formation pour prévenir ce type de faille

Vous pouvez utiliser les données fournies dans la page de vulnérabilité pour évaluer l’importance du problème et prendre les mesures nécessaires pour corriger la vulnérabilité efficacement.

Page de vulnérabilité pour une faille relative à la détection des secrets

Les résultats d'un scanner personnalisé peuvent être utilisés pour alimenter la page de vulnérabilité. Les données de vulnérabilité sont renseignées à partir du schéma JSON généré par le scanner.

Tableau de bord de sécurité

Les tableaux de bord de sécurité permettent d'évaluer la posture de sécurité de vos applications. GitLab vous fournit un ensemble d'indicateurs, d'évaluations et de graphiques correspondant aux vulnérabilités détectées par les scanners de sécurité exécutés sur votre projet. Le tableau de bord de sécurité fournit différentes données, notamment :

• Les tendances des vulnérabilités sur une période de 30, 60 ou 90 jours pour tous les projets d'un groupe
• Une note sous forme de lettre pour chaque projet en fonction de la gravité de la vulnérabilité
• Le nombre total de vulnérabilités détectées au cours des 365 derniers jours et leurs niveaux de gravité

Tableau de bord de sécurité au niveau du groupe

À partir du tableau de bord de sécurité au niveau du groupe, vous pouvez cliquer sur un projet pour accéder au tableau de bord de sécurité associé, qui fournit une vue sur 365 jours.

Tableau de bord de sécurité au niveau du projet

Intégration des politiques d'approbation des merge requests

Les politiques d'approbation des merge requests, anciennement désignées comme stratégies de sécurité basées sur les résultats de scan dans les versions précédentes de GitLab, sont utilisées pour exiger une approbation en fonction des résultats d'un ou de plusieurs jobs de scan de sécurité. L'objectif est d'éviter que du code non sécurisé ne soit fusionné et déployé en production. Ces politiques sont évaluées après l'exécution complète des jobs de scan dans les pipelines CI, en s'appuyant sur les rapports générés par les artefacts de job et publiés dans le pipeline une fois celui-ci terminé.

Par exemple, vous pouvez créer une politique d'approbation des merge requests qui exige l'approbation des chargés de maintenance du projet dans le cas où le scanner de détection de secrets détecte des vulnérabilités. Voici comment procéder :

1. Dans la barre latérale gauche, cliquez sur Rechercher ou accéder à et recherchez le projet auquel vous souhaitez ajouter une politique.

2. Dans la barre latérale gauche du projet, accédez à Sécurisation > Politiques

3. Sélectionnez Nouvelle stratégie de sécurité

4. Dans la section Politiques d'approbation des merge requests, sélectionnez Sélectionner une stratégie de sécurité.

5. Renseignez les champs suivants :

• Nom : le nom de la politique d'approbation
• Description : la description de la politique d'approbation
• État : indique si la politique d'approbation est activée ou non
• Règles : les conditions qui doivent être remplies pour déclencher une action (comme exiger une approbation)

Règles de la politique d'approbation des merge requests

• Actions : l'action à entreprendre chaque fois que les conditions définies dans les règles (vulnérabilités/licences détectées) sont remplies

Actions associées à la politique d'approbation des merge requests

• Remplacer les paramètres d'approbation du projet : si cette option est sélectionnée, les choix suivants écraseront les paramètres du projet, mais uniquement pour les branches spécifiées dans la politique d'approbation des merges requests.

Paramètres d'approbation de la politique d'approbation des merge requests

6. Cliquez sur le bouton Configurer avec une merge request.

Une fois que la politique d'approbation des merge requests a été fusionnée, chaque fois que vous créez une merge request et que les critères définis dans les règles sont remplis, l'action définie est déclenchée. Dans ce cas, au moins une approbation de la part d'un chargé de maintenance sera requise avant que le code puisse être fusionné.

Merge request bloquée en raison de vulnérabilités détectées

Les résultats d'un scanner personnalisé peuvent être entièrement intégrés aux politiques d'approbation des merge requests. Si le scanner personnalisé détecte une vulnérabilité, une approbation sera alors requise avant que le code puisse être fusionné. Le scanner que vous sélectionnez dans une telle politique doit utiliser le schéma JSON approprié.

Tutoriel : intégration de scanners de sécurité personnalisés

Passons maintenant à la partie la plus intéressante : l'intégration d'un scanner de sécurité personnalisé. Dans ce tutoriel, vous apprendrez à créer un scanner de sécurité personnalisé, ainsi qu'à l'intégrer à GitLab. Nous nous appuierons sur les projets suivants :

• Fern Pattern Scanner : analyse vos fichiers à la recherche de motifs spécifiques tels que les mots de passe, les clés privées et les numéros de sécurité sociale.
• Secret List : contient une liste répertoriant des mots de passe d'utilisateurs et de clients, et des clés. Ce projet sert à démontrer comment un scanner de sécurité personnalisé peut être intégré à GitLab.

Pour en savoir plus, consultez la vidéo suivante :

Création d'un scanner de sécurité personnalisé

Créons maintenant un scanner personnalisé qui peut être intégré à GitLab. Avant qu'un scanner personnalisé puisse être entièrement intégré à GitLab, il doit respecter les conditions suivantes :

• scanner un répertoire à la recherche de motifs définis
• générer un fichier JSON conforme au schéma approprié
• être conteneurisé et accessible depuis GitLab
• fournir un template autorisant son exécution sur un autre projet

Lorsque le Fern Pattern Scanner est exécuté sur un projet à l'aide du template fourni, il effectue les étapes suivantes :

1. Il charge un ensemble de règles qui définissent les motifs (regex) à détecter.

• Il permet la configuration des règles afin de s'adapter aux besoins en constante évolution de votre entreprise.

2. Il scanne les fichiers à la recherche des motifs définis.
3. Il génère un rapport JSON conforme au schéma de détection des secrets.

• Il utilise des templates Go pour créer ce fichier JSON.
• Veillez à utiliser le schéma adéquate, selon les éléments que votre scanner doit rechercher.

Une fois le rapport JSON chargé en tant qu'artefact dans GitLab, il alimente le widget de sécurité des merges requests, le rapport de vulnérabilités, les pages de vulnérabilités, les politiques d'approbation des merge requests ainsi que les tableaux de bord de sécurité, comme décrit précédemment.

Intégration d'un scanner de sécurité personnalisé à GitLab

Une fois que vous avez créé votre scanner personnalisé qui répond à tous les besoins d'intégration, vous pouvez l'exécuter sur GitLab.

Exécuter un scanner personnalisé est aussi simple que d'ajouter un template. Par exemple, le template Fern Pattern Scanner est chargé dans le fichier .gitlab-ci.yml sur le projet Secret List.

Voici les étapes à suivre :

1. Créez un fichier .gitlab-ci.yml dans le projet sur lequel vous souhaitez exécuter le scanner.

2. Incluez le template du scanner personnalisé.

   • Vous pouvez également configurer ce template avec des variables d'environnement.

3. Validez ce fichier dans la branche principale.

Une fois le fichier validé, vous pouvez constater que le scanner personnalisé s'exécute dans votre pipeline. Une fois le pipeline terminé, le scanner alimentera toutes les zones définies ci-dessus dans la section Intégration de scanners de sécurité dans GitLab.

Pour en savoir plus, consultez les ressources ci-dessous et les autres possibilités d'extension de votre plateforme DevSecOps :

• Intégration du scanner de sécurité dans GitLab
• Intégrations des partenaires GitLab
• Groupe de projets du scanner de sécurité personnalisé
• Réponse automatique à une fuite de secret