Glossaire sécurité et DevSecOps pour auditeurs
Ce glossaire explique les principaux termes techniques en langage clair, à l’intention des auditeurs, des responsables conformité et des gestionnaires de risques. Pour chaque terme, nous expliquons ce que c’est, pourquoi les auditeurs s’en soucient et quelles preuves rechercher.
CI/CD (Continuous Integration / Continuous Delivery)
Ce que c’est : Un système automatisé qui construit, teste et déploie le logiciel à chaque changement effectué par les développeurs. Voyez-le comme une chaîne de montage numérique pour le logiciel — le code entre d’un côté, un logiciel testé et packagé ressort de l’autre.
Pourquoi les auditeurs s’en soucient : Les pipelines CI/CD constituent la couche d’application des contrôles de la livraison logicielle. Si les contrôles de sécurité ne sont pas intégrés à ce pipeline, ils ne sont probablement pas appliqués du tout. Au titre de DORA et de NIS2, les systèmes CI/CD sont considérés comme des systèmes TIC réglementés.
Preuves à rechercher : Journaux d’exécution du pipeline horodatés, enregistrements d’achèvement des étapes obligatoires, workflows d’approbation avant le déploiement en production.
Pipeline
Ce que c’est : Une séquence d’étapes automatisées (construction, test, analyse, déploiement) que le code doit franchir avant d’atteindre la production. Chaque étape peut imposer un point de contrôle de sécurité.
Pourquoi les auditeurs s’en soucient : L’architecture du pipeline détermine si les contrôles de sécurité sont obligatoires ou optionnels. Un pipeline bien conçu empêche tout code non approuvé d’atteindre la production.
Preuves à rechercher : Fichiers de configuration du pipeline montrant les étapes obligatoires, journaux de réussite/échec des points de contrôle, enregistrements des déploiements bloqués.
SAST (Static Application Security Testing)
Ce que c’est : Analyse automatisée du code source pour détecter les vulnérabilités de sécurité avant l’exécution du logiciel. Elle lit le code comme le ferait un relecteur, à la recherche de schémas de vulnérabilités connus.
Pourquoi les auditeurs s’en soucient : SAST fournit la preuve que les tests de sécurité se font tôt dans le développement. Il démontre que l’organisation identifie proactivement les vulnérabilités plutôt que de les découvrir en production.
Preuves à rechercher : Journaux de scan avec horodatages, application de politique montrant les builds bloqués sur les constats critiques, rapports de tendance montrant les taux de remédiation dans le temps, processus de suppression/exception documentés.
DAST (Dynamic Application Security Testing)
Ce que c’est : Test automatisé d’une application en cours d’exécution en simulant de vraies attaques. Contrairement au SAST (qui lit le code), le DAST teste l’application comme le ferait un attaquant — de l’extérieur.
Pourquoi les auditeurs s’en soucient : Le DAST valide que les applications déployées sont résilientes face aux modèles d’attaque connus. Il complète le SAST en testant le comportement réel, pas seulement le code.
Preuves à rechercher : Rapports de scan DAST avec vulnérabilités identifiées et niveaux de gravité, calendriers de remédiation, planifications de scans récurrents, intégration avec les journaux du pipeline CI/CD.
SCA (Software Composition Analysis)
Ce que c’est : Analyse automatisée des bibliothèques tierces et dépendances utilisées dans le logiciel. La plupart des applications modernes sont composées de 70 à 90 % de code tiers — le SCA vérifie si ce code présente des vulnérabilités connues ou des risques de licence.
Pourquoi les auditeurs s’en soucient : Le risque des composants tiers est une préoccupation majeure selon l’article 28 de DORA et les exigences de chaîne d’approvisionnement de NIS2. Le SCA fournit une visibilité sur la chaîne d’approvisionnement logicielle.
Preuves à rechercher : Inventaires de dépendances, rapports de vulnérabilités pour les composants tiers, vérifications de conformité de licence, blocage automatisé des composants avec des vulnérabilités critiques.
SBOM (Software Bill of Materials)
Ce que c’est : Un inventaire complet et lisible par machine de chaque composant (bibliothèques, frameworks, dépendances) inclus dans une application logicielle. Pensez-y comme une étiquette nutritionnelle pour le logiciel.
Pourquoi les auditeurs s’en soucient : Les SBOM sont de plus en plus exigés par la réglementation. Ils permettent la traçabilité des composants de la chaîne d’approvisionnement et l’évaluation rapide de l’impact lorsque de nouvelles vulnérabilités sont divulguées.
Preuves à rechercher : Fichiers SBOM générés (format SPDX ou CycloneDX), génération automatisée de SBOM dans les pipelines CI/CD, enregistrements de rétention et de versioning des SBOM.
IAST (Interactive Application Security Testing)
Ce que c’est : Une approche de test hybride qui surveille les applications de l’intérieur pendant les tests. Un agent est intégré dans l’application et observe les chemins d’exécution réels du code pour identifier les vulnérabilités avec une grande précision.
Pourquoi les auditeurs s’en soucient : L’IAST fournit des résultats très précis avec moins de faux positifs que le SAST ou le DAST seuls, ce qui rend les constats plus exploitables et auditables.
Preuves à rechercher : Enregistrements de déploiement de l’agent IAST, rapports d’exécution des tests, constats de vulnérabilités corrélés à des chemins de code précis.
RASP (Runtime Application Self-Protection)
Ce que c’est : Un agent de sécurité d’exécution intégré à l’application qui détecte et bloque les attaques en temps réel. Contrairement à un pare-feu (qui protège le périmètre), le RASP protège depuis l’intérieur de l’application.
Pourquoi les auditeurs s’en soucient : Le RASP démontre une protection à l’exécution — un contrôle détectif et correctif qui fonctionne en continu, et pas seulement pendant les phases de test.
Preuves à rechercher : Configuration de déploiement du RASP, journaux des attaques bloquées, enregistrements d’intégration aux alertes/incidents, rapports de couverture.
Container / Image / Registry
Ce que c’est : Un conteneur est un package léger et isolé qui regroupe une application avec tout ce dont elle a besoin pour s’exécuter. Une image est le modèle utilisé pour créer des conteneurs. Un registre est le dépôt où les images sont stockées et distribuées.
Pourquoi les auditeurs s’en soucient : Les conteneurs sont l’unité de déploiement standard dans les environnements modernes. Des images non signées ou non analysées représentent un risque pour la chaîne d’approvisionnement. Les contrôles d’accès au registre déterminent qui peut déployer quoi.
Preuves à rechercher : Rapports d’analyse des images, enregistrements de signature/vérification des images, politiques de contrôle d’accès au registre, politiques de mise à jour des images de base.
IaC (Infrastructure as Code)
Ce que c’est : Gérer l’infrastructure (serveurs, réseaux, bases de données) au moyen de fichiers de code plutôt que par une configuration manuelle. Les changements d’infrastructure passent par le même pipeline que le code applicatif.
Pourquoi les auditeurs s’en soucient : L’IaC rend les changements d’infrastructure traçables, revus et auditables — les mêmes contrôles de gouvernance qui s’appliquent au code peuvent s’appliquer à l’infrastructure.
Preuves à rechercher : Modèles IaC sous contrôle de version, enregistrements d’approbation des changements, rapports de détection de dérive, analyse de sécurité des modèles IaC.
Gestion des secrets
Ce que c’est : La pratique consistant à stocker, distribuer et renouveler de façon sécurisée les identifiants sensibles (clés d’API, mots de passe, certificats, jetons) utilisés par les applications et les pipelines.
Pourquoi les auditeurs s’en soucient : Les secrets exposés comptent parmi les défaillances de sécurité les plus fréquentes et les plus graves. Une gestion des secrets rigoureuse démontre la maturité du contrôle d’accès et réduit le risque de compromission des identifiants.
Preuves à rechercher : Déploiement d’un coffre-fort/gestionnaire de secrets centralisé, politiques de rotation automatisées, absence de secrets codés en dur dans le code (vérifiée par analyse), journaux d’audit des accès.
Artefact
Ce que c’est : Tout élément produit par le pipeline CI/CD — code compilé, images de conteneurs, packages, documentation. Les artefacts sont ce qui est déployé en production.
Pourquoi les auditeurs s’en soucient : L’intégrité des artefacts garantit que ce qui a été testé est exactement ce qui est déployé. Des artefacts altérés ou non signés représentent un risque critique pour la chaîne d’approvisionnement.
Preuves à rechercher : Enregistrements de signature des artefacts, métadonnées de provenance, sommes de contrôle/empreintes, stockage immuable des artefacts, traçabilité du déploiement jusqu’à des exécutions précises du pipeline.
Policy-as-Code
Ce que c’est : Codage des politiques de sécurité et de conformité sous forme de règles lisibles par machine, appliquées automatiquement par le pipeline CI/CD. Au lieu d’un document de politique au format PDF, la politique devient du code exécutable.
Pourquoi les auditeurs s’en soucient : La politique en tant que code transforme les politiques, de documents d’intention en contrôles effectivement appliqués. Elle apporte la preuve que les politiques ne sont pas seulement rédigées, mais réellement appliquées.
Preuves à rechercher : Fichiers de définition des politiques sous contrôle de version, journaux d’application montrant les résultats d’évaluation des politiques, enregistrements des déploiements bloqués pour violation de politique.
Shift-Left
Ce que c’est : Déplacer les tests et les contrôles de sécurité plus tôt dans le cycle de développement logiciel — de l’après-déploiement (à droite) vers les phases de conception et de codage (à gauche). L’objectif est de détecter les problèmes lorsqu’ils sont moins coûteux et plus faciles à corriger.
Pourquoi les auditeurs s’en soucient : Le shift-left témoigne d’une posture de sécurité proactive et préventive plutôt que réactive. Les réglementations attendent de plus en plus que la sécurité soit intégrée tout au long du SDLC, et non ajoutée à la fin.
Preuves à rechercher : Exigences de sécurité dans les documents de conception, SAST intégré dans les workflows des développeurs, enregistrements de modélisation des menaces, journaux de formation des développeurs à la sécurité.
DevSecOps
Ce que c’est : Un modèle opérationnel qui intègre la sécurité à chaque phase du développement et de la livraison logicielle. Il définit les rôles, les responsabilités et les contrôles automatisés pour garantir une sécurité continue — et non une phase ou une équipe distincte.
Pourquoi les auditeurs s’en soucient : DevSecOps est le cadre de gouvernance qui rend la sécurité CI/CD durable. Il détermine qui est responsable de quoi, comment les exceptions sont traitées et comment les contrôles sont appliqués.
Preuves à rechercher : Rôles et responsabilités définis (RACI), configurations des points de contrôle de sécurité, workflows d’approbation des exceptions/exclusions, indicateurs de sécurité et cadence de reporting.
Séparation des tâches (SoD)
Ce que c’est : Garantir qu’aucune personne ne puisse à la fois développer le code et approuver son déploiement en production. Des rôles différents prennent en charge les différentes étapes du processus de livraison.
Pourquoi les auditeurs s’en soucient : La séparation des tâches est un contrôle fondamental exigé par pratiquement tous les cadres de conformité. Elle prévient la fraude, réduit le risque de menace interne et garantit une revue indépendante.
Preuves à rechercher : Configurations RBAC, journaux des workflows d’approbation montrant des approbateurs différents des auteurs du code, règles de protection de branche, matrices d’autorisations de déploiement.
RBAC (Role-Based Access Control)
Ce que c’est : Un modèle de contrôle d’accès où les autorisations sont attribuées à des rôles (par ex. développeur, relecteur, déployeur) plutôt qu’à des utilisateurs individuels. Les utilisateurs héritent des autorisations via l’attribution de leur rôle.
Pourquoi les auditeurs s’en soucient : Le RBAC est le fondement de la séparation des tâches et du moindre privilège. Il fournit un modèle d’accès structuré et auditable.
Preuves à rechercher : Définitions de rôles et matrices d’autorisations, enregistrements d’attribution utilisateur-rôle, revues d’accès périodiques, surveillance des rôles privilégiés.
Ce glossaire est maintenu comme une référence vivante. Les termes sont définis du point de vue de l’auditeur — axés sur la vérification des contrôles, non sur les détails de mise en œuvre. Pour des orientations de mise en œuvre technique, visitez secure-pipelines.com.
