PR : DevSecOps - Jules - Martin - Mathéo

[martinboutier]

Mise en œuvre de l'approche DevSecOps

Ce document a pour objectif de présenter notre approche pour intégrer les principes et les outils DevSecOps au cœur de notre projet. Il détaille la manière dont nous combinons les pratiques de développement (Dev), de sécurité (Sec) et d’exploitation (Ops) afin de garantir une sécurité globale.

---

Le DevSecOps c'est quoi ?

Le DevSecOps est l'évolution naturelle de la culture DevOps. Il repose sur le principe du "Shift Left" : l'idée est d'intégrer la sécurité le plus tôt possible dans le cycle de vie du développement logiciel (SDLC), plutôt que de la traiter comme une étape finale de vérification. Il s'agit avant tout d'une culture qui regroupe aussi bien les équipes de développement, de sécurité et opérationnels. L'objectif est de traiter les enjeux de sécurité au tout début du projet et tout au long de celui-ci. Comme le DevOps avant même de penser à la mise en place et la configuration de différents outils, on s'attèle d'abord a bien organiser l'équipe autour de cette idée.

Les enjeux du DevSecOps

• Réduction des risques : Identifier et corriger les risques avant que le projet ne soit en production coûte moins cher et réduit la surface d'attaque.
• Agilite et Rapidite : L'automatisation des contrôles de sécurité évite les blocages manuels en fin de projet, ça permet de déployer plus rapidement.
• Culture de Responsabilité Partagée : La sécurité n'est plus liée à un seul département, elle devient commune à tous les développeurs et aux équipes opérationnelles.
• Conformité Continue : L'objectif est de garantir en permanence que le code et l'infrastructure respectent les standards.

---

Stack Technique & Outils Choisis

Nous avons sélectionné 3 outils pour couvrir les différentes phases du projet (Code, Build, Déploiement, Runtime).

1. SonarQube (Static Application Security Testing - SAST)

SonarQube analyse statiquement le code source pour détecter les bugs, les "code smells" et les vulnérabilités de sécurité. Dans ce projet, nous l'utilisons pour valider la conformité de notre infrastructure.

• Utilisation : Le fichier sonar-scanner.sh permet de lancer un scan. Le scanner est configuré avec un périmètre d'analyse optimisé via le fichier sonar-project.properties. Les résultats sont ensuite consultable sur le port 9000.
• Avantage : Assure une base de code propre et protégée contre les injections (SQL, XSS) ou les failles de logique. L'intégration d'une Quality Gate permet de bloquer tout build non conforme, garantissant que les corrections (comme le passage de mots de passe en clair vers l'injection dynamiquevia Vault) sont maintenues dans le temps.

2. HashiCorp Vault (Secrets Management)

Le stockage de secrets (clés API, mots de passe base de données) en clair dans le code ou les variables d'environnement est une faille majeure.

• Utilisation : Centralisation, chiffrement et rotation des secrets.
• Avantage : Injection dynamique des secrets uniquement au moment de l'exécution, sans aucune trace persistante dans le code source.
  Protéger les données sensibles est un élement important dans la démarche DevSecOps, en effet il est primordiale de protéger des clés d'API ou tout autre élement critique. Nous avons fait le choix d'implémenter Vault afin de stocker ces clés encryptées. Un script de test est par ailleurs disponible pour ajouter au Vault les clés d'etherpad et la clé de décryptage de la base de données.

3. Falco (Cloud-Native Runtime Security)

Une sécurité parfaite au build ne garantit pas l'absence d'attaques en production. Falco surveille les appels système en temps réel.

• Utilisation : Détection d'activités anormales dans les conteneurs (ex: ouverture d'un shell inattendu, modification de fichiers sensibles).
• Avantage : Alerte immédiate et visibilité totale sur l'état de sécurité de l'aplication en cours d'exécution.
  Dans une logique DevSecOps tous les élements doivent être protégés ainsi mettre ne place des secrets notamment avec Vault ou encore analyser le code avec Sonarqube serait inutile si les conteneurs eux-mêmes n'étaient pas sécurisés. C'est pourquoi nous avons fait le choix de configurer falco qui permet une approche sûr et fiable.
  Un script d'automatisations est par ailleurs disponible dans le dossier racine et permet de vérifier l'état des conteneurs les plus critiques. Il donne un compte rendu de son analyse dans le fichier falco_tests.txt.

Base de données

Le projet initial utilise une base de données mysql. Nous avons décidé de crypté la base de données. La configuration du cryptage se fait via le fichier docker-compose.yaml. Ce cryptage s'accompagne forcément d'une clé de décryptage, que nous protégeons dans Vault. Cette configuration passe par les fichiers component_keyring_file.cnf, mysql_encryption_keys.key et mysqld.my dans la racine de l'api. Malheureusement nous n'avons pas réussi à faire communiquer l'api avec la base de données.

---

Lancement du Projet

Pour lancer les conteneurs on a le docker-compose.yml à la racine du projet:
docker compose up -d
Dans le répertoire api/:
./mvnw quarkus:dev
Dans le répertoire front/:
npm start
Les fichiers de tests sont situés dans le dépôt racine:

• init-vault.sh
• init-falco.sh
• sonar-scanner.sh

---

Difficultés rencontrées

• SonarQube : Il a été compliqué de lancer le scanner sans que ce dernier ne prenne trop de temps et de RAM. La mise en place et et configuration du scanner ont également pris beaucoup de temps du fait que chaque debug était associé à un long scan. Finalement, il a été décidé de se concentrer sur l'analyse des fichiers d'infrastructure que nous avions rajouté autour du projet, tout en excluant le dossier /front et /api.
• Base de données : Crypter la base de données a demandé la création de différents fichiers de configuration qui devaient communiquer entre eux. Il a fallu de nombreux échecs avant de savoir quels bonnes lignes utiliser dans ces fichiers. De plus, le lancement de l'application devait alors se faire dans un ordre bien précis : lancer le conteneur Vault, lancer le script init-vault.sh puis lancer le reste de l'application. Cela nous a motivé a créer le fichier de lancement start.sh. Finalement, bien que nous avons fini par réussir à lancer la base de données cryptée, et à sauvegarder sa clé de décryptage dans le Vault, nous n'avons pas réussi à la faire communiquer avec l'API.

Ces deux éléments sont les obstacles qui nous ont pris le plus de temps lors de la réalisation de ce projet. Nous voulions ajouter et configurer d'autres outils mais nous avons manqué de temps.

Autres outils

Etant donné que le projet était hébergé en local il nous était difficile d'implémenter et configurer certains outils qui aurait pu renforcer la logique de DevSecOps mise en place pour ce projet.

1. OWASP Dependency-Check (Software Composition Analysis - SCA)

Cet outil scanne les dépendances pour identifier les vulnérabilités connues (CVE).

• Utilisation : Scan automtique des fichiers de gestion de paquets (pom.xml, package.json, etc.).
• Avantage : Empêche l'utilisation de bibliothèques obsolètes ou compromises.

2. Lynis (Analyse de Sécurité des Dépendances)

Lynis est un outil de sécurité open source conçu pour les systèmes basés sur Unix (Linux, macOS). Contrairement au SCA qui scanne les bibliothèques de code, Lynis effectue un scan de santé global du système d'exploitation.

• Utilisation : Analyse en temps réel du trafic entrant/sortant, blocage des requêtes malveillantes (ex. : injections SQL, XSS, scans de ports). Réalisation d'audits de sécurité et de tests de conformité
• Avantage : Réduit les risques d’exploitation des failles logicielles ou de configuration, tout en garantissant la disponibilité et l’intégrité des services hébergés. Il permet d'identifier les vulnérabilités connues (CVE), de réaliser des tests d'intrusion et de vérifier la configuration sécurisée de l'hôte qui héberge nos conteneurs.