Vos répertoires GIT gardent-ils des secrets ?

# Vos répertoires GIT gardent-ils des secrets ?

Aujourd'hui, tout développeur utilise un outil de versioning de code tel que GitHub ou GitLab. Ces outils sont souvent la porte d'entrée au piratage, car ils peuvent contenir des informations sensibles (les clés de chiffrement, les clés API, les clés SSH, les certificats, les logins/mots de passe, tokens). [Une étude de GitGuardian](https://www.gitguardian.com/state-of-secrets-sprawl-report-2023) a révélé que 10 millions de nouvelles donnés sensibles ont été détectées en 2022. Ces chiffres sont explicites et sont une preuve que les bonnes pratiques de code et de sécurité ne sont toujours pas respectées.

## Analyse du GIT repository

Connaitre et détecter les failles de sécurité de son code est primordial. Pour cela, il est possible d'utiliser [Gitleaks](https://gitleaks.io/).

Gitleaks est un outil SAST ([Static Application Security Testing](https://en.wikipedia.org/wiki/Static_application_security_testing)), open source, qui permet de détecter des secrets dans le code.

Il est complet et permet de faire une analyse de votre code source, mais également de tout votre historique Git pour identifier les secrets qui ont pu être commités dans le passé. En effet, ce n'est pas parce que le secret n'est plus présent dans votre repository qu'il n'a pas existé, les données sont considérées comme corrompues dès le premier commit.

Son installation se fait facilement via [le code source](https://github.com/gitleaks/gitleaks).

Pour faire un check up de votre repository, il suffit d'exécuter la commande `gitleaks detect`, qui vous sortira un rapport de type :

```bash
$> gitleaks detect
   ○
   │╲
   │ ○
   ○ ░
   ░    gitleaks

2:03PM INF 2596 commits scanned.
2:03PM INF scan completed in 7.69s
2:03PM WRN leaks found: 5
```

## Automatiser cette analyse

Se baser sur une revue de code pour éviter la publication de secrets n'est pas des plus fiables. Une fois le code commités, il est déjà trop tard, car les données sensibles seront toujours présente dans l'historique Git. Les retirer de l'historique devient fastidieux. Sur le même principe que le test ou un linter, il faut donc l'automatiser cette analyse.

La commande suivante permet d'analyser nos dernières modifications en cours et détecter si le code comporte des données sensibles :

```bash
$> gitleaks protect --verbose --redact --staged
```

Si vos commits ne contiennent pas d'informations sensibles, vous aurez une réponse de ce type :

```raw
   ○
   │╲
   │ ○
   ○ ░
   ░    gitleaks

2:08PM INF 0 commits scanned.
2:08PM INF scan completed in 61.8ms
2:08PM INF no leaks found
```

En ce qui concerne l'automatisation, il y a plusieurs solutions disponibles :

- La mise en place de la ligne de commande dans un [Git Hooks de pré-commit](https://www.younup.fr/blog/tirer-le-meilleur-de-git-avec-les-hooks) qui empêchera tout commit ne respectant pas les règles.
- Sa mise en place dans un workflow de CI afin de détecter sur les MR / PR avant merge sur la branche de dev.

## Comment sauvegarder mes donnés sensibles ?

Au vu de l'architecture logicielle de nos jours, il est difficile de se passer d'API key ou de token d'authentification. Pour sauvegarder ces informations, il y a principalement deux solutions qui se présentent à nous.

### Chiffre ses fichiers

Pour chiffrer ses fichiers, il faut utiliser des outils tel que [git-crypt](https://github.com/AGWA/git-crypt) à l'aide de clefs GPG. Il permet de chiffrer les fichiers contenant des informations sensibles et seules les personnes préalablement autorisées pourront donc déchiffrer ce fichier.

Exemple d'un fichier chiffré par un utilisateur possédant les droits :

```bash
$ cat api.key
API_KEY_SERVICE_1="1234455"
```

Ce même fichier ne sera pas lisible par un utilisateur n'ayant pas sa clef GPG autorisée à déchiffre le fichier :

```bash
$ cat api.key
GITCRYPTZ??q?? y^j5??m?Q
```

Il a quelques points de vigilance concernant l'utilisation de git-crypt :

- Les merges avec des conflits sur les fichiers chiffrés sont compliqués.
- L'historique de modification des fichiers chiffrés n'est pas optimisé.
- Le code doit être déchiffré dans la CI si votre code a besoin de ces fichiers pour compiler.

### Secret manager

La sauvegarde dans des fichiers, même chiffrés, a ces limites.

La solution recommandée est d'utiliser un secret manager tel que Vault ou AWS Secret Manager, pour ne citer que les plus connus. Le principe reste le même (les données sensibles sont sauvegardées de manière chiffrée), mais le secret manager présente plusieurs avantages :

- Une gestion des droits plus facile et précise avec un système de droits et policies.
- Une centralisation des données sensibles au même endroit avec l'utilisation d'une seule solution pour la sauvegarde de différents secrets (token, clefs d'api, certificats, mot de passes).

## Que retenir de cet article ?

Scanner un repository ou une organisation est très simple et ne requiert pas des grandes compétences d'hacking. La sécurité d'une application ne se limite à la production et doit être intégrée à toutes les étapes du développement.

Il est impératif de sensibiliser les différents acteurs d'un projet et de mettre en place rapidement les outils permettant de stocker les secrets et ainsi empêcher qu'ils n'apparaissent dans un repository.

‍