Gitleaks

Dans le domaine de la gestion de projets logiciels, la sécurité des informations est une préoccupation constante. Paradoxalement, une grande partie des fuites de données ne résulte pas d’attaques malveillantes, mais plutôt d’erreurs “involontaires”. En effet, les données sensibles sont souvent divulguées par mégarde, en particulier dans les dépôts Git utilisés pour la gestion de version et le partage de code.

Ne Sous-Estimez Pas les Fuites Git

Les dépôts Git, bien qu’indispensables pour la collaboration et la gestion efficace des projets logiciels, peuvent devenir des points faibles en matière de sécurité. Cela se produit généralement lorsque des informations confidentielles telles que des clés API, des mots de passe, des certificats SSL ou même des données personnelles sont accidentellement intégrées dans le code source ou les fichiers de configuration et ensuite poussées dans des dépôts publics ou privés.

Cette vulnérabilité est souvent le résultat d’une méconnaissance ou d’une sous-estimation du risque associé au partage non sécurisé d’informations sensibles. Les développeurs, sous la pression de respecter les délais ou de résoudre des problèmes rapidement, peuvent négliger des étapes essentielles de la sécurisation des données. Le résultat est que des informations confidentielles se retrouvent exposées dans des dépôts accessibles, mettant en péril la sécurité des systèmes et la confidentialité des données.

C’est là qu’intervient Gitleaks. Cet outil est conçu pour détecter les fuites de données dans les dépôts Git, en scannant les historiques de commits et les branches à la recherche de secrets qui n’auraient pas dû être partagés. Grâce à Gitleaks, les administrateurs système et les développeurs peuvent identifier et rectifier ces erreurs avant qu’elles ne causent des dommages réels, ce qui fait de cet outil un allié précieux dans la lutte contre la divulgation involontaire de données sensibles.

Installation

Passons maintenant à l’installation et à la configuration de Gitleaks, un processus essentiel pour commencer à sécuriser vos dépôts Git.

Sur linux

Méthode classique

Si vous préférez une méthode d’installation directe, vous pouvez télécharger la dernière version de Gitleaks depuis sa page GitHub. Voici les commandes de base pour une installation rapide sur un système Linux :

# Télécharger la dernière version de Gitleaks
wget https://github.com/gitleaks/gitleaks/releases/download/v8.18.1/gitleaks_8.18.1_linux_x64.tar.gz

# Extraire le fichier
tar -xf gitleaks_8.18.1_linux_x64.tar.gz

# Déplacer Gitleaks dans un répertoire du PATH
sudo mv gitleaks /usr/local/bin/

Installation avec asdf

Pour une gestion de versions plus flexible, asdf est une excellente option. Après avoir installé asdf et ajouté le plugin Gitleaks, vous pouvez installer Gitleaks comme ceci :

# Ajouter le plugin Gitleaks
asdf plugin add gitleaks

# Installer une version spécifique de Gitleaks
asdf install gitleaks 8.18.1

# Définir Gitleaks 8.18.1 comme la version globale
asdf global gitleaks 8.18.1

Sur MacOS

Gitleaks peut être installé sur MacOS à l’aide de Homebrew :

brew install gitleaks

Utilisation pratique de Gitleaks

Après avoir installé et configuré Gitleaks, il est temps de l’utiliser pour sécuriser vos dépôts Git. Cette section se concentrera sur la manière d’utiliser efficacement Gitleaks dans différents scénarios.

Scannage d’un Dépôt Local

Un usage courant de Gitleaks est le scannage d’un dépôt Git local. Cela peut être fait facilement avec la commande suivante :

# Analyser un dépôt Git local
gitleaks detect -v
    ○
    │╲
    │ ○
    ○ ░
    ░    gitleaks

Finding:     Root Token: hvs.T9hGPTSQ0uMxbi2Yt9onYPX3
Secret:      hvs.T9hGPTSQ0uMxbi2Yt9onYPX3
RuleID:      generic-api-key
Entropy:     4.450212
File:        docs/securiser/secrets/hashicorp-vault.md
Line:        215
Commit:      e10af0272a1745cc2c1c1e9364ad6b0baf3a18c6
Author:      Stéphane ROBERT
Email:       robert.stephane.28@gmail.com
Date:        2023-11-17T14:37:13Z
Fingerprint: e10af0272a1745cc2c1c1e9364ad6b0baf3a18c6:docs/securiser/secrets/hashicorp-vault.md:generic-api-key:215

Cette commande lancera un scan de votre dépôt à la recherche de secrets ou de données sensibles en fonction des règles définies dans votre fichier de configuration. Ici, il détecte les exemples dans les documentations.

Vérification des Commits Avant Push

Pour éviter de pousser des données sensibles sur un dépôt distant, vous pouvez utiliser Gitleaks pour analyser vos commits avant de les pousser. Cela peut être réalisé en exécutant Gitleaks en tant que hook de pré-commit dans Git.

pip install pre-commit --user
vi .pre-commit-config.yaml

Y déposer ce contenu :

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.16.1
    hooks:
      - id: gitleaks

On lance l’installation :

pre-commit install

Ce script arrêtera le commit si Gitleaks détecte des données sensibles.

Intégration dans les Pipelines CI/CD

Si vous utilisez une plateforme comme GitHub ou GitLab, vous pouvez intégrer Gitleaks dans votre processus de revue de code. En configurant un pipeline CI/CD, vous pouvez faire en sorte que Gitleaks analyse chaque pull request pour s’assurer qu’aucune donnée sensible n’est intégrée dans le code.

Intégration de Gitleaks dans Github Actions

Voici un exemple de configuration pour un pipeline CI avec GitHub Actions :

name: Gitleaks

on: [pull_request]

jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout
      uses: actions/checkout@v2

    - name: Gitleaks Action
      uses: zricethezav/gitleaks-action@master

Ce workflow exécutera Gitleaks à chaque pull request pour s’assurer que le code respecte les normes de sécurité.

En suivant ces étapes, vous pouvez intégrer Gitleaks dans différents aspects de votre flux de travail Git, offrant ainsi une protection proactive contre les fuites de données. Dans le prochain chapitre, je discuterai de l’interprétation des résultats fournis par Gitleaks et de la manière de répondre efficacement aux alertes.

Intégration de Gitleaks dans GitLab CI

Pour intégrer Gitleaks dans votre processus de revue de code sur GitLab, vous pouvez configurer un job dans votre fichier .gitlab-ci.yml. Ce job sera exécuté à chaque push ou merge request pour scanner le code à la recherche de données sensibles.

Voici un exemple de configuration pour GitLab CI :

stages:
  - security

gitleaks:
  stage: security
  image: zricethezav/gitleaks:latest
  script:
    - gitleaks detect --source="$CI_PROJECT_DIR" --verbose
  only:
    - main
    - merge_requests

Dans cet exemple :

• stages définit les différentes étapes du pipeline. Ici, nous avons une étape security.
• gitleaks est le nom du job.
• stage: security indique que ce job fait partie de l’étape security.
• image: zricethezav/gitleaks:latest utilise l’image Docker de Gitleaks.
• script contient les commandes à exécuter, ici un scan du répertoire du projet.
• only spécifie les branches et événements pour lesquels ce job doit s’exécuter, ici la branche principale (main) et les merge requests.

En ajoutant ce job à votre fichier .gitlab-ci.yml, vous activez un scan automatique de Gitleaks à chaque push important ou merge request, renforçant ainsi la sécurité de votre code.

Configuration de Gitleaks

La configuration de Gitleaks vous permet de définir précisément comment l’outil doit détecter les secrets dans vos dépôts Git.

Commencez le fichier de configuration .gitleaks.toml en définissant un titre pour votre configuration. Cela aide à identifier facilement le fichier de configuration.

title = "Gitleaks title"

Vous pouvez étendre une configuration existante en utilisant soit la configuration par défaut de Gitleaks, soit un chemin vers un autre fichier de configuration. Notez que vous ne pouvez pas utiliser useDefault et path en même temps.

[extend]
useDefault = true
# ou
# path = "common_config.toml"

Passons aux règles. Chaque règle doit avoir un identifiant unique, une description, une expression régulière pour détecter les secrets et des tags à des fins de reporting.

[[rules]]
id = "awesome-rule-1"
description = "awesome rule 1"
regex = '''one-go-style-regex-for-this-rule'''
path = '''a-file-path-regex'''
tags = ["tag", "another tag"]

Utilisez des mots-clés pour effectuer une vérification rapide avant même le lancement de la correspondance avec les regex. Cela permet d’optimiser les performances en filtrant le contenu qui ne contient aucun des mots-clés spécifiés.

keywords = ["auth", "password", "token"]

Pour réduire les faux positifs ou ignorer les commits avec des secrets connus ou déjà divulgués, vous pouvez utiliser la liste d’exclusion. Cela vous permet de spécifier des commits, des chemins et des regex à ignorer.

[rules.allowlist]
description = "ignore commit A"
commits = ["commit-A", "commit-B"]
paths = ['''go\.mod''', '''go\.sum''']
regexTarget = "match"

Vous pouvez ainsi créer un fichier de configuration sur mesure, adapté aux besoins de votre projet et des règles établies dans votre entreprise.

Un exemple de fichier complet :

# Title for the gitleaks configuration file.
title = "Gitleaks Sample"

[extend]
# useDefault will extend the base configuration with the default gitleaks config:
# https://github.com/zricethezav/gitleaks/blob/master/config/gitleaks.toml
useDefault = true
# or you can supply a path to a configuration. Path is relative to where gitleaks
# was invoked, not the location of the base config.
# path = "~/common_config.toml"

# An array of tables that contain information that define instructions
# on how to detect secrets
[[rules]]

# Unique identifier for this rule
id = "awesome-rule-1"

# Short human readable description of the rule.
description = "awesome rule 1"

# Golang regular expression used to detect secrets. Note Golang's regex engine
# does not support lookaheads.
regex = '''one-go-style-regex-for-this-rule'''

# Golang regular expression used to match paths. This can be used as a standalone rule or it can be used
# in conjunction with a valid `regex` entry.
path = '''a-file-path-regex'''

# Array of strings used for metadata and reporting purposes.
tags = ["tag","another tag"]

# Int used to extract secret from regex match and used as the group that will have
# its entropy checked if `entropy` is set.
secretGroup = 3

# Float representing the minimum shannon entropy a regex group must have to be considered a secret.
entropy = 3.5

# Keywords are used for pre-regex check filtering. Rules that contain
# keywords will perform a quick string compare check to make sure the
# keyword(s) are in the content being scanned. Ideally these values should
# either be part of the idenitifer or unique strings specific to the rule's regex
# (introduced in v8.6.0)
keywords = [
  "auth",
  "password",
  "token",
]

# You can include an allowlist table for a single rule to reduce false positives or ignore commits
# with known/rotated secrets
[rules.allowlist]
description = "ignore commit A"
commits = [ "commit-A", "commit-B"]
paths = [
  '''go\.mod''',
  '''go\.sum'''
]
# note: (rule) regexTarget defaults to check the _Secret_ in the finding.
# if regexTarget is not specified then _Secret_ will be used.
# Acceptable values for regexTarget are "match" and "line"
regexTarget = "match"
regexes = [
  '''process''',
  '''getenv''',
]
# note: stopwords targets the extracted secret, not the entire regex match
# like 'regexes' does. (stopwords introduced in 8.8.0)
stopwords = [
  '''client''',
  '''endpoint''',
]


# This is a global allowlist which has a higher order of precedence than rule-specific allowlists.
# If a commit listed in the `commits` field below is encountered then that commit will be skipped and no
# secrets will be detected for said commit. The same logic applies for regexes and paths.
[allowlist]
description = "global allow list"
commits = [ "commit-A", "commit-B", "commit-C"]
paths = [
  '''gitleaks\.toml''',
  '''(.*?)(jpg|gif|doc)'''
]

# note: (global) regexTarget defaults to check the _Secret_ in the finding.
# if regexTarget is not specified then _Secret_ will be used.
# Acceptable values for regexTarget are "match" and "line"
regexTarget = "match"

regexes = [
  '''219-09-9999''',
  '''078-05-1120''',
  '''(9[0-9]{2}|666)-\d{2}-\d{4}''',
]
# note: stopwords targets the extracted secret, not the entire regex match
# like 'regexes' does. (stopwords introduced in 8.8.0)
stopwords = [
  '''client''',
  '''endpoint''',
]

Interprétation des résultats de Gitleaks

Après avoir configuré Gitleaks dans votre environnement de développement, il est indispensable de savoir interpréter ses résultats pour agir efficacement en cas de détection de données sensibles.

Comprendre les Alertes de Gitleaks

Lorsque Gitleaks détecte une potentielle fuite de données, il génère une alerte contenant plusieurs informations clés :

1. Type de Règle Violée : Indique quelle règle de votre fichier de configuration a été déclenchée.
2. Emplacement de la Fuite : Fournit des détails sur l’emplacement de la fuite potentielle, comme le fichier et la ligne concernée.
3. Commit Incriminé : Identifie le commit spécifique qui a introduit la donnée sensible.
4. Auteur du Commit : Nomme l’auteur du commit, utile pour le suivi et la correction.

Analyse et Action

Vérification de l’Alerte

Une fois une alerte reçue, la première étape est de vérifier son authenticité. Toutes les alertes ne sont pas des fuites réelles ; certaines peuvent être des faux positifs. Par exemple, une chaîne de caractères ressemblant à une clé API, mais qui ne l’est pas en réalité.

Prise de Mesures Correctives

Attention

Lorsque vous travaillez avec Git, il est important de se rappeler que supprimer un mot de passe ou toute donnée sensible de l’historique des commits peut être une tâche complexe et fastidieuse. Une fois que des informations confidentielles sont poussées dans un dépôt Git, les effacer complètement nécessite souvent de réécrire l’historique des commits, une opération qui peut avoir des implications importantes, surtout si d’autres collaborateurs travaillent sur le même dépôt. Il est donc imoprtant d’être vigilant et de s’assurer que les données sensibles ne soient jamais commises dans Git.

Si une fuite est confirmée, il est important d’agir rapidement :

• Révoquer les Clés Compromises : Si des clés d’API ou des certificats sont exposés, révoquez-les immédiatement pour éviter un usage non autorisé.
• Corriger le Commit : Supprimez les données sensibles du dépôt et poussez un nouveau commit. Envisagez de réécrire l’historique du dépôt si nécessaire pour supprimer complètement les données des commits précédents.
• Notifier les Parties Concernées : Si la fuite implique des données clients ou d’autres parties externes, suivez les protocoles appropriés pour les informer.
• Révisez Régulièrement les Règles de Gitleaks : Assurez-vous que vos règles sont à jour et couvrent tous les types de données sensibles pertinents pour votre projet.
• Formation et Sensibilisation : Formez votre équipe sur l’importance de ne pas commettre de données sensibles et sur la façon d’utiliser Gitleaks efficacement.

Conclusion

En conclusion, Gitleaks est un outil indispensable dans l’arsenal de tout administrateur système et développeur soucieux de la sécurité. Son intégration dans les processus de développement et d’administration système offre une couche supplémentaire de protection contre les fuites de données sensibles, un enjeu majeur dans notre environnement actuel.

Je recommande vivement à tous les consultants DevSecOps de prendre en compte la sécurité des dépôts Git et d’intégrer Gitleaks ou des outils similaires dans leur workflow. Commencez par tester Gitleaks dans un projet pilote et évaluez son impact sur la sécurité de votre code.

En adoptant une approche proactive en matière de sécurité, vous pouvez non seulement protéger vos données, mais aussi contribuer à la création d’un environnement de développement plus sûr et plus fiable pour l’avenir.

Plus d’infos

• Le site Officiel ↗