Aller au contenu principal

Audit d’un projet DevOps

Identifier et corriger les failles dans un environnement automatisé

Notions théoriques​

Un projet DevOps combine le développement logiciel et l’administration système pour automatiser le cycle de vie des applications.

Cependant, cette automatisation introduit des risques de sécurité qui doivent être identifiés et corrigés.

Pour détecter les vulnérabilités, l’audit de sécurité d’un projet DevOps consiste à analyser :

  • les configurations,
  • les pipelines CI/CD
  • et les dépendances logicielles.

Les principales menaces en environnement DevOps​

  1. Fuites d’informations sensibles :

    • Clés API et mots de passe stockés en clair dans les dépôts Git
    • Variables d’environnement mal protégées

  2. Dépendances vulnérables :

    • Utilisation de bibliothèques obsolètes avec des failles connues
    • Absence de mise à jour des conteneurs et des packages

  3. Mauvaises configurations des conteneurs et orchestrateurs :

    • Exécution des conteneurs en tant que root
    • Permissions excessives sur les volumes partagés
    • Mauvaise gestion des secrets dans Kubernetes

  4. Failles dans les pipelines CI/CD :

    • Scripts exécutés sans restrictions de permissions
    • Absence de contrôle sur les artefacts générés

  5. Attaques sur l’infrastructure en tant que code (IaC) :

    • Mauvaise configuration des fichiers Terraform ou Ansible
    • Ouverture involontaire de ports sensibles

Outils utilisés pour l’audit de sécurité​

  • Trivy : Scanner de vulnérabilités pour conteneurs et dépendances
  • GitLeaks : Détection de secrets exposés dans un dépôt Git
  • Checkov : Analyse de sécurité des fichiers Terraform et Kubernetes
  • Grype : Scanner de vulnérabilités pour les images Docker
  • OWASP Dependency-Check : Analyse des bibliothèques utilisées dans un projet

Un audit de sécurité DevOps consiste à exécuter ces outils sur les différents composants du projet et à analyser les résultats pour appliquer des correctifs.

Exemple pratique​

Il est possible d’auditer un projet DevOps en utilisant des outils automatisés pour détecter les vulnérabilités.

Voici un exemple d’audit sur un projet contenant une application Docker avec un pipeline CI/CD.

astuce

Cet exemple permet d’illustrer comment un audit de sécurité peut être réalisé sur un projet DevOps existant. Il est possible d’appliquer ces mêmes étapes sur n’importe quel projet pour détecter et corriger les vulnérabilités.

1. Vérification des secrets exposés dans le dépôt Git​

Un projet open-source contenant des erreurs de sécurité est disponible sur GitHub :

git clone https://github.com/cybersecsi/DevOps-Project.git
cd DevOps-Project
gitleaks detect -v

Si des secrets sont détectés, il est nécessaire de les supprimer et de les remplacer par des variables d’environnement sécurisées.

2. Scan des vulnérabilités dans l’image Docker​

L’image Docker utilisée dans ce projet peut contenir des vulnérabilités connues. Il est possible d’analyser cette image avec Trivy :

trivy image cybersecsi/devops-project

Si des vulnérabilités critiques sont trouvées, il faut mettre à jour les dépendances et reconstruire l’image.

3. Analyse de la configuration des fichiers Terraform​

Si le projet contient des fichiers d’infrastructure en tant que code, il est possible d’utiliser Checkov pour détecter des erreurs de configuration :

checkov -d infrastructure/

Checkov signale les erreurs de configuration qui pourraient exposer l’infrastructure à des attaques.

4. Vérification des dépendances utilisées dans le projet​

Certaines bibliothèques utilisées dans l’application peuvent être obsolètes et contenir des failles de sécurité. Il est possible d’utiliser Grype pour analyser les dépendances :

grype cybersecsi/devops-project

Si des bibliothèques vulnérables sont détectées, il faut les mettre à jour dans le fichier requirements.txt ou package.json.

5. Sécurisation du pipeline CI/CD​

Il est nécessaire de vérifier que les scripts de déploiement n’exécutent pas de commandes avec des droits excessifs et que les artefacts générés sont signés pour éviter les attaques par substitution.

Test de mémorisation/compréhension​


Quel est le principal risque lié aux secrets stockés dans un dépôt Git ?


Quel outil permet de détecter des secrets exposés dans un dépôt Git ?


Pourquoi est-il dangereux d’exécuter un conteneur en tant que root ?


Quel outil est utilisé pour scanner les vulnérabilités dans une image Docker ?


Quelle est la meilleure pratique pour gérer les secrets dans un projet DevOps ?


Pourquoi est-il important de scanner les dépendances d’un projet ?


Quel est l’intérêt d’utiliser Checkov dans un audit DevOps ?


Comment éviter les attaques par substitution d’artefacts dans un pipeline CI/CD ?


Pourquoi est-il important de mettre à jour les images Docker régulièrement ?


Que faut-il faire si un scan Trivy détecte une vulnérabilité critique ?


TP pour réfléchir et résoudre des problèmes​

L’objectif de ce TP est d’auditer un projet DevOps open-source en analysant ses vulnérabilités et en appliquant des correctifs.

Contrairement à l’exemple pratique, ce TP se concentre sur l’amélioration de la sécurité d’un pipeline CI/CD en identifiant et en corrigeant ses failles.

Étape 1 - Récupération du projet et analyse initiale​

Le projet utilisé pour ce TP est un dépôt GitHub contenant une application Node.js avec un pipeline CI/CD.

Cloner le projet :

git clone https://github.com/snoopysecurity/dvna.git
cd dvna

Analyser la structure du projet pour identifier les fichiers liés à l’intégration et au déploiement continu. Rechercher des fichiers tels que :

  • .github/workflows/ (GitHub Actions)
  • .gitlab-ci.yml (GitLab CI/CD)
  • Jenkinsfile (Jenkins)
  • docker-compose.yml (orchestration de conteneurs)
info

Le projet contient un fichier .github/workflows/main.yml, indiquant l’utilisation de GitHub Actions pour automatiser les tâches CI/CD. Ce fichier définit les étapes du pipeline, y compris la construction et le déploiement de l’application.

Étape 2 - Détection des secrets exposés​

Vérifier si des secrets sont exposés dans le dépôt Git en utilisant GitLeaks :

gitleaks detect -v

Si des secrets sont détectés, identifier leur emplacement et leur nature.

info

GitLeaks peut détecter des clés API, des tokens d’authentification ou des mots de passe en clair dans le code. Si des secrets sont trouvés, il faut :

  1. Supprimer les secrets du code source.
  2. Révoquer les secrets compromis et en générer de nouveaux.
  3. Utiliser des variables d’environnement ou un gestionnaire de secrets (ex : AWS Secrets Manager, HashiCorp Vault).

Étape 3 - Analyse des vulnérabilités dans l’image Docker​

Vérifier si l’image Docker du projet contient des vulnérabilités connues :

trivy image snoopysecurity/dvna

Lister les vulnérabilités critiques et proposer des solutions pour les corriger.

info

Trivy peut détecter des vulnérabilités dans les bibliothèques et les dépendances de l’image Docker. Pour corriger ces vulnérabilités :

  1. Mettre à jour la base de l’image Docker (FROM dans le Dockerfile).
  2. Mettre à jour les dépendances de l’application (package.json).
  3. Reconstruire l’image et vérifier à nouveau avec Trivy.

Étape 4 - Sécurisation du pipeline CI/CD​

Analyser le fichier .github/workflows/main.yml pour identifier les failles potentielles dans le pipeline CI/CD.

Vérifier les points suivants :

  • Les scripts exécutés ont-ils des permissions excessives ?
  • Les artefacts générés sont-ils signés pour éviter les attaques par substitution ?
  • Y a-t-il des accès non sécurisés à des secrets ?
info
  1. Éviter l’exécution en tant que root : Vérifier si les conteneurs utilisés dans le pipeline s’exécutent en tant que root et, si c’est le cas, modifier la configuration pour utiliser un utilisateur non privilégié.
  2. Utiliser des secrets sécurisés : Si des secrets sont utilisés directement dans le fichier YAML, les remplacer par des variables d’environnement GitHub Actions (secrets.GITHUB_TOKEN).
  3. Signer les artefacts : Ajouter une étape pour signer les artefacts générés avec une clé privée afin d’éviter les attaques par substitution.

Étape 5 - Vérification de la configuration de l’infrastructure​

Si le projet utilise Terraform ou un autre outil d’infrastructure en tant que code, analyser la configuration avec Checkov :

checkov -d infrastructure/

Identifier les erreurs de configuration et proposer des corrections.

info

Checkov peut détecter des erreurs telles que :

  • Des ports ouverts inutilement.
  • Des ressources cloud mal configurées (ex : bases de données accessibles publiquement).
  • L’absence de chiffrement des données sensibles.

Pour corriger ces erreurs :

  1. Restreindre les accès réseau aux services critiques.
  2. Activer le chiffrement des bases de données et des volumes de stockage.
  3. Appliquer le principe du moindre privilège aux rôles et permissions.

Étape 6 - Mise en place des correctifs et validation​

Appliquer les correctifs identifiés dans les étapes précédentes, puis relancer les outils d’audit pour vérifier que les vulnérabilités ont bien été corrigées.

Exécuter à nouveau les commandes suivantes :

gitleaks detect -v
trivy image snoopysecurity/dvna
checkov -d infrastructure/
info

Si les correctifs ont été bien appliqués, les outils d’audit ne devraient plus signaler de vulnérabilités critiques.
En cas de persistance de certaines alertes, vérifier si elles sont justifiées ou si elles peuvent être ignorées en toute sécurité.