Intégration du Secure SDLC dans un projet logiciel : conception et expérimentation d’un Security Gate automatisé dans l’application SONGRER

Auteur : Équipe de Développement et Sécurité — Projet SONGRER

Mots-clés : Secure SDLC, DevSecOps, Security Gate, CI/CD, Semgrep, Trivy, Gitleaks, ESLint, Static Analysis, Vulnerability Management, SONGRER.

1. Résumé

L'intégration tardive des contrôles de sécurité dans le cycle de vie du logiciel constitue un facteur majeur de vulnérabilités en production et d'augmentation des coûts de correction. Le concept de Secure Software Development Life Cycle (Secure SDLC) préconise le déplacement de la sécurité le plus tôt possible dans le cycle de développement (Shift Left Security) .

Cet article présente la conception, la mise en œuvre et l'évaluation expérimentale d'un mécanisme automatisé de contrôle de sécurité (Security Gate) au sein du pipeline CI/CD du projet SONGRER (système d'information multi-composants comprenant une API backend, un dashboard d'administration web et une application mobile).

Nous décrivons le modèle d'agrégation multi-outils (Gitleaks , Semgrep , ESLint Security , NPM Audit, Trivy ) via un script de normalisation (normalize-findings.sh), suivi du moteur de décision exécuté par gate.sh. Les résultats expérimentaux démontrent qu'un filtrage basé sur des seuils stricts (tolérance zéro sur le niveau CRITICAL et restriction des vulnérabilités HIGH) stoppe efficacement la progression du build en retournant un code de sortie non nul (exit 1), protégeant ainsi la chaîne de déploiement. L'article discute des apports de cette démarche ainsi que de ses limites actuelles et des perspectives d'évolution vers un score de risque dynamique.

2. Introduction

Dans les approches traditionnelles de développement logiciel, les vérifications de sécurité interviennent généralement en fin de cycle, sous la forme d'audits ponctuels ou de tests de pénétration réalisés juste avant la mise en production. Cette approche "en silo" présente deux inconvénients majeurs : d'une part, la détection tardive d'une erreur d'architecture ou d'une vulnérabilité critique implique des coûts de refactorisation exponentiels [1] ; d'autre part, la vitesse imposée par les méthodologies agiles entraîne la mise en ligne involontaire de composants défaillants [8].

Pour répondre à ce défi, le paradigme du Secure SDLC propose d'injecter des garde-fous automatisés à chaque étape du développement. Toutefois, l'automatisation d'outils d'analyse (SAST, SCA, secrets scan) génère un volume important de données hétérogènes qu'il convient de centraliser et d'évaluer afin de prendre une décision binaire : autoriser ou bloquer le déploiement.

L'objectif de cet article est de répondre à la problématique suivante :

Comment concevoir et intégrer un mécanisme automatisé de contrôle de sécurité (Security Gate) dans la chaîne CI/CD d'une application multi-services pour stopper le déploiement dès la détection d'un risque inacceptable ?

Afin de répondre à cette question, nous décrivons l'expérimentation menée sur l'application SONGRER, en détaillant le cadre théorique, l'architecture d'implémentation et les résultats des scénarios de test.

3. Cadre théorique : le Secure SDLC

Le SDLC classique définit les étapes logiques de création d'un logiciel : analyse des besoins, conception, développement, tests et déploiement. Le Secure SDLC enrichit ce cycle en y intégrant des activités de sécurité spécifiques à chaque phase (modélisation des menaces, revues de code sécurisées, analyse statique, audit de dépendances)[10].

                  Figure 1 — Comparaison entre un SDLC traditionnel et un Secure SDLC (Shift Left Security).

Le principe de Shift Left (« Décalage vers la gauche ») vise à déplacer les contrôles au plus près de l'écriture du code par les développeurs [2] . Plus une vulnérabilité est détectée tôt dans le pipeline, plus sa résolution est rapide et peu coûteuse [1] .

4. Les principaux enseignements

L'étude du Secure SDLC appuyée sur le modèle de maturité OWASP SAMM [10] et la norme ISO/IEC 27034 met en évidence six phases interconnectées :

1. Analyse des exigences : Identification des contraintes réglementaires (GDPR, OWASP Top 10 [11]) et des besoins de confidentialité.

2. Conception sécurisée : Analyse de la surface d'attaque et modélisation des menaces (STRIDE) [12].

3. Implémentation : Application des normes de codage sécurisé et analyse statique locale.

4. Validation & Tests : Exécution automatisée des outils SAST, SCA, DAST et analyse de conteneurs.

5. Déploiement : Hardening de l'infrastructure et contrôle d'intégrité.

6. Maintenance & Réponse aux incidents : Veille sur les vulnérabilités (CVE) et gestion des correctifs.

Figure 2 — Représentation circulaire des phases du Secure SDLC.

Un Security Gate constitue un checkpoint qualité/sécurité automatisé au sein d'un pipeline d'intégration continue. Il analyse les rapports émis par les différents scanners et applique une règle logique de décision :

• Gate Bloquant (Fail-Fast) : Si un seuil toléré est dépassé (ex. présence d'une vulnérabilité CRITICAL), le script renvoie un code d'erreur Linux (exit 1), ce qui stoppe immédiatement l'exécution du pipeline.

• Gate Informatif (Warning) : Pour les failles de faible gravité (LOW ou MEDIUM), le Gate enregistre l'information dans les rapports d'artéfacts sans interrompre le déploiement, permettant un traitement en dette technique.

Cette formule définit la règle de décision de la barrière de sécurité (Security Gate) intégrée au pipeline CI/CD. Elle analyse les vulnérabilités détectées afin de déterminer automatiquement si le déploiement peut se poursuivre.

• F représente l’ensemble des vulnérabilités (findings) détectées.

• severity(f) indique le niveau de gravité de chaque vulnérabilité.

• Le cardinal |{...}| permet de compter le nombre de vulnérabilités correspondant à un niveau de gravité donné.

La règle de décision est simple :

• BLOCKED (exit 1) si au moins 1 vulnérabilité CRITICAL est détectée ou si le nombre de vulnérabilités HIGH dépasse 5.

• OK (exit 0) si aucune vulnérabilité CRITICAL n'est présente et que le nombre de vulnérabilités HIGH reste inférieur ou égal à 5.

Ainsi, la formule transforme automatiquement les résultats des analyses de sécurité en une décision de contrôle du déploiement, empêchant la mise en production lorsque les seuils de sécurité définis sont dépassés.

5. Méthodologie expérimentale

L'expérimentation a été conduite sur l'écosystème de l'application SONGRER, une plateforme monorepo articulée autour de trois modules principaux :

• songrer-api : API backend Node.js / Express avec ORM Prisma et base de données PostgreSQL.

• songrer-dashboard : Interface web d'administration développée en React.

• songrer-mobile : Application mobile client développée sous React Native.

Figure 3 — Architecture technique simplifiée de la plateforme SONGRER.

Le pipeline CI/CD repose sur GitLab CI/CD et intègre l'ensemble de la chaîne d'outils de sécurité.

6. Expérimentation : conception du Security Gate

La politique de sécurité appliquée au projet SONGRER impose des contraintes strictes avant toute fusion sur la branche principale :

1. Aucune vulnérabilité de sévérité CRITICAL ne doit être tolérée.

2. Un maximum de 5 vulnérabilités de sévérité HIGH est toléré sous réserve de correction dans le sprint suivant.

Cette formule définit la règle de décision de la barrière de sécurité (Security Gate) intégrée au pipeline CI/CD. Elle analyse les vulnérabilités détectées afin de déterminer automatiquement si le déploiement peut se poursuivre.

• F représente l’ensemble des vulnérabilités (findings) détectées.

• severity(f) indique le niveau de gravité de chaque vulnérabilité.

• Le cardinal |{...}| permet de compter le nombre de vulnérabilités correspondant à un niveau de gravité donné.

La règle de décision est simple :

• BLOCKED (exit 1) si au moins 1 vulnérabilité CRITICAL est détectée ou si le nombre de vulnérabilités HIGH dépasse 5.

• OK (exit 0) si aucune vulnérabilité CRITICAL n'est présente et que le nombre de vulnérabilités HIGH reste inférieur ou égal à 5.

Ainsi, la formule transforme automatiquement les résultats des analyses de sécurité en une décision de contrôle du déploiement, empêchant la mise en production lorsque les seuils de sécurité définis sont dépassés.

7. Étape 1 — Structure et Normalisation (findings.json)

Chaque scanner de sécurité (Gitleaks, Semgrep, Trivy, ESLint, NPM Audit) produit des sorties dans des formats JSON distincts. Pour permettre une évaluation unifiée, nous avons conçu le script normalize-findings.sh. Ce script convertit les données de chaque outil en un schéma JSON standardisé :

Figure 4 — Extrait du fichier unifié findings.json contenant un finding de sévérité CRITICAL.

8. Étape 2 — Logique décisionnelle du Security Gate

Le flux d'exécution du Security Gate suit une séquence stricte, garantissant qu'aucun rapport ne soit ignoré :

Figure 5 — Logique décisionnelle du Security Gate.

9. Étape 3 — Implémentation du script gate.sh

Le script shell gate.sh exploite l'outil jq pour procéder à l'analyse contextuelle du fichier JSON normalisé :

Figure 6 — Code source du script de décision gate.sh.

10. Étape 4 — Test en présence d'une vulnérabilité critique

Figure 7 — Exécution du Security Gate provoquant un arrêt avec le code de sortie 1.

L'exécution confirme que le script renvoie la valeur de sortie $? = 1, ce qui informe le moteur CI/CD de l'échec de la tâche.

11. Étape 5 — Test en l'absence de vulnérabilité critique

Après correction de la faille critique, le fichier est réévalué avec uniquement des alertes de niveau inférieur ou égal à HIGH (dans la limite autorisée) :

Figure 8 — Validation du Security Gate avec un code de retour 0.

12. Étape 6 — Intégration dans le pipeline GitLab CI/CD de SONGRER

Le Security Gate est configuré dans le fichier .gitlab-ci.yml de SONGRER à la dernière étape (security-gate), qui orchestre le téléchargement des artéfacts des étapes précédentes (needs) et exécute les scripts de validation :

Figure 9 — Extrait de la configuration du job security-gate dans le fichier .gitlab-ci.yml.

 13. Étape 7 — Exécution et vérification sur GitLab CI/CD

Lorsqu'un développeur pousse du code contenant un secret en clair ou une dépendance vulnérable critique (ex. image Docker songrer-api contenant une faille critique détectée par Trivy), le job security-gate échoue :

Figure 10 — Interruption automatique du job GitLab CI/CD par le Security Gate.

Après remédiation (mise à jour des packages npm, nettoyage des clés), le pipeline valide l'étape globale :

Figure 11 — Validation du job security-gate sur GitLab CI/CD.

14. Résultats expérimentaux

Les résultats obtenus lors des différents scénarios de test sur les modules de SONGRER sont synthétisés ci-dessous :

Tableau 1 — Matrice de résultats des scénarios de validation du Security Gate.

15. Discussion et Perspectives

L'expérimentation démontre l'efficacité d'un Security Gate automatisé pour prévenir l'introduction de risques majeurs dans le code de SONGRER. En combinant la détection de secrets, le SAST et le contrôle de conteneurs, la surface d'attaque est réduite avant toute exposition.

• Dette technique des faux positifs : La définition stricte basée sur des règles statiques peut entraîner des blocages injustifiés en cas de détection incorrecte par les scanners.

• Absence d'un score de risque contextuel : La sévérité est évaluée dans l'absolu et non en fonction de l'exposabilité réelle du composant touché.

1. Implémentation d'un Risk Score Dynamique : Remplacer le comptage binaire par un calcul pondéré tenant compte de la valeur métier du composant.

2. Gestion des exceptions via signatures cryptographiques : Permettre la création d'exemptions validées par l'équipe SecOps pour neutraliser temporairement les faux positifs.

16. Résumé de la bibliographie

• [1] Boehm (1981) : https://en.wikipedia.org/wiki/Software_Engineering_Economics

• [2] McGraw (2006) : https://www.oreilly.com/library/view/software-security-building/0321356701/

• [3] Gitleaks : https://github.com/gitleaks/gitleaks

• [4] Semgrep : https://semgrep.dev/

• [5] ESLint Security Plugin : https://github.com/eslint-community/eslint-plugin-security

• [6] npm-audit : https://docs.npmjs.com/cli/v10/commands/npm-audit

• [7] Trivy : https://github.com/aquasecurity/trivy

• [8] Fowler (2006) : https://martinfowler.com/articles/continuousIntegration.html

• [9] ISO/IEC 27034-1:2011 : https://www.iso.org/standard/44378.html

• [10] OWASP SAMM v2.0 : https://owaspsamm.org/

• [11] OWASP Top 10 : https://owasp.org/www-project-top-ten/

• [12] Shostack (2014) : https://www.wiley.com/en-us/Threat+Modeling%3A+Designing+for+Security-p-9781118809990

• [13] GitLab CI/CD : https://docs.gitlab.com/ee/ci/

• [14] CVSS v3.1 : https://www.first.org/cvss/v3.1/specification-document

• [15] jq : https://jqlang.github.io/jq/