Guide orienté gouvernance des catégories de contrôles de sécurité CI/CD pour les auditeurs, responsables conformité et régulateurs
Les pipelines CI/CD sont l’épine dorsale de la livraison logicielle moderne. Pour les auditeurs et les responsables conformité, comprendre les contrôles de sécurité intégrés dans ces pipelines est essentiel pour évaluer si une organisation gère adéquatement les risques liés à la livraison logicielle.
Ce guide explique les principales catégories de contrôles de sécurité CI/CD — non pas comme des recommandations de produits, mais comme des domaines de gouvernance que les auditeurs doivent comprendre, vérifier et évaluer lors des revues de conformité.
Pourquoi les auditeurs doivent comprendre les contrôles de sécurité CI/CD
Les pipelines CI/CD modernes gèrent :
- l’accès aux dépôts de code source
- les processus automatisés de build et de packaging
- l’intégration avec des services et dépendances tiers
- le déploiement vers les systèmes de production
Chacune de ces étapes introduit des risques. Les auditeurs doivent pouvoir vérifier que des contrôles de sécurité appropriés sont en place à chaque étape, que ces contrôles sont appliqués de manière cohérente (pas simplement disponibles), et qu’ils produisent des preuves fiables et conservées.
Dans les environnements réglementés, la question n’est pas quels outils sont installés, mais si les bons contrôles sont actifs, appliqués et auditables.
Catégorie de contrôle 1 : Sécurité du code source et des dépôts
Ce qu’elle contrôle : L’accès au code source, l’autorisation des modifications de code, la prévention des modifications non autorisées et la détection de secrets dans les dépôts.
Preuves produites : Journaux de contrôle d’accès, configurations de protection des branches, enregistrements d’approbation des pull requests et résultats d’analyse de détection de secrets.
Ce que les auditeurs doivent vérifier :
- Les règles de protection des branches sont appliquées (pas simplement documentées)
- Toutes les modifications de code nécessitent une revue par les pairs et une approbation avant fusion
- L’analyse des secrets s’exécute automatiquement sur chaque commit ou pull request
- L’accès aux dépôts suit les principes du moindre privilège
- Les journaux d’audit des modifications de code sont conservés pendant la période requise
Signaux d’alerte :
- Des commits directs sur les branches principales sans revue
- Des règles de protection des branches pouvant être contournées par les administrateurs
- Aucune analyse de secrets en place, ou une analyse exécutée uniquement à la demande
- Des permissions d’accès aux dépôts trop larges
Catégorie de contrôle 2 : Tests de sécurité statiques (SAST)
SAST (Static Application Security Testing) est un contrôle qui analyse le code source pour identifier les vulnérabilités de sécurité avant que les applications ne soient construites ou déployées. Il opère pendant les phases de développement et de build.
Ce qu’il contrôle : Les failles de sécurité au niveau du code, les schémas de codage non sécurisés et la conformité aux politiques du code personnalisé.
Preuves produites : Rapports d’analyse montrant les vulnérabilités identifiées, les classifications de sévérité, les décisions de politique (réussite/échec) et les données de tendance dans le temps.
Ce que les auditeurs doivent vérifier :
- SAST s’exécute automatiquement sur chaque build ou pull request — pas uniquement à la demande
- Des seuils de sévérité définis existent pouvant bloquer les builds ou les déploiements
- Les résultats supprimés ou acceptés ont des justifications documentées et des dates d’expiration
- Les résultats d’analyse sont conservés et liés à des builds et releases spécifiques
- Le périmètre de l’analyse SAST couvre toutes les bases de code de production
Signaux d’alerte :
- SAST est configuré mais pas appliqué — les builds continuent indépendamment des résultats
- Un grand nombre de résultats supprimés sans justification documentée
- Les résultats d’analyse ne sont pas conservés ou ne peuvent pas être tracés à des releases spécifiques
- La couverture SAST n’inclut pas toutes les applications de production
Catégorie de contrôle 3 : Analyse de composition logicielle (SCA)
SCA (Software Composition Analysis) identifie les risques dans les bibliothèques tierces, les composants open source et leurs dépendances transitives. Ce contrôle est central pour la gestion des risques de la chaîne d’approvisionnement.
Ce qu’il contrôle : Les vulnérabilités connues dans les dépendances, la conformité des licences et la visibilité sur la chaîne d’approvisionnement logicielle.
Preuves produites : Inventaires de dépendances, Software Bills of Materials (SBOM), rapports de vulnérabilités pour les composants tiers et enregistrements de conformité des licences.
Ce que les auditeurs doivent vérifier :
- SCA s’exécute automatiquement pendant les builds et produit des inventaires de dépendances actuels
- Les dépendances vulnérables connues déclenchent des réponses définies (blocage, alerte ou acceptation documentée)
- Les SBOM sont générés et conservés pour chaque release
- La conformité des licences est activement surveillée
- Les politiques de dépendances définissent ce qui est acceptable et ce qui nécessite une approbation
Signaux d’alerte :
- Aucun inventaire de dépendances ou SBOM n’existe pour les applications de production
- Les vulnérabilités critiques connues dans les dépendances ne sont pas traitées ou documentées
- L’analyse SCA n’est pas intégrée dans le CI/CD — elle s’exécute manuellement ou pas du tout
- Aucune gouvernance sur les composants tiers pouvant être utilisés
Catégorie de contrôle 4 : Gestion et détection des secrets
Les secrets — tels que les clés API, les identifiants, les jetons et les certificats — sont des cibles de haute valeur dans les environnements CI/CD. Cette catégorie de contrôle englobe à la fois la détection des secrets exposés et la gouvernance de la façon dont les secrets sont stockés, accédés et renouvelés.
Ce qu’elle contrôle : La prévention de l’exposition des identifiants dans le code et les pipelines, l’accès contrôlé aux secrets, et les procédures de rotation et de révocation.
Preuves produites : Résultats d’analyse des secrets, journaux d’accès aux systèmes de stockage de secrets, enregistrements de rotation et enregistrements de réponse aux incidents pour toute exposition détectée.
Ce que les auditeurs doivent vérifier :
- L’analyse des secrets est automatisée et s’exécute à chaque modification de code
- Un système centralisé de gestion des secrets est utilisé — les secrets ne sont jamais codés en dur
- L’accès aux secrets est basé sur les rôles et journalisé
- Les politiques de rotation existent et sont appliquées
- Les expositions de secrets détectées déclenchent une réponse aux incidents documentée
Signaux d’alerte :
- Des secrets trouvés dans le code source, les fichiers de configuration ou les journaux de pipeline
- Pas de gestion centralisée des secrets — les équipes gèrent les identifiants indépendamment
- Pas de politique de rotation ou de preuve de rotation
- L’analyse des secrets n’est pas appliquée ou peut être contournée
Catégorie de contrôle 5 : Intégrité du build et sécurité des artefacts
Les contrôles d’intégrité du build garantissent que ce qui est déployé correspond à ce qui a été testé et approuvé. Cela inclut la signature des artefacts, la vérification d’intégrité, le stockage immuable et le suivi de provenance.
Ce qu’il contrôle : La prévention de la falsification des sorties de build, la traçabilité du code source à l’artefact déployé, et l’assurance que les artefacts n’ont pas été modifiés après les tests.
Preuves produites : Artefacts signés, attestations de provenance, sommes de contrôle d’intégrité et journaux de dépôts d’artefacts immuables.
Ce que les auditeurs doivent vérifier :
- Les artefacts sont signés et les signatures sont vérifiées avant le déploiement
- Le stockage des artefacts est immuable — les artefacts précédemment publiés ne peuvent pas être écrasés
- Des enregistrements de provenance existent reliant chaque artefact à son code source, son build et ses résultats de tests
- Les vérifications d’intégrité sont appliquées au moment du déploiement, pas seulement au moment du build
Signaux d’alerte :
- Les artefacts ne sont pas signés ou les signatures ne sont pas vérifiées
- Pas de provenance ou de traçabilité de l’artefact à la source
- Les dépôts d’artefacts permettent l’écrasement des versions existantes
- Manipulation manuelle des artefacts en dehors du pipeline
Catégorie de contrôle 6 : Tests de sécurité dynamiques (DAST)
DAST (Dynamic Application Security Testing) teste les applications en cours d’exécution en interagissant avec elles de manière externe, simulant des scénarios d’attaque réels. Il valide la posture de sécurité à l’exécution, y compris les flux d’authentification, la gestion des sessions et les faiblesses de configuration.
Ce qu’il contrôle : Les vulnérabilités à l’exécution, les erreurs de configuration de sécurité et les problèmes de contrôle d’accès dans les applications déployées ou en staging.
Preuves produites : Résultats d’analyse documentant les constats à l’exécution, les décisions de filtrage (réussite/échec) et les enregistrements de toute exception accordée.
Ce que les auditeurs doivent vérifier :
- DAST est exécuté avant les releases en production — pas uniquement à la demande
- Des seuils définis existent pouvant bloquer ou retarder les releases en fonction des résultats
- Les exceptions au filtrage DAST sont documentées avec des approbations
- Les résultats DAST sont conservés et traçables à des releases spécifiques
Signaux d’alerte :
- DAST ne s’exécute qu’occasionnellement ou pas du tout pour les applications critiques
- Pas de logique de filtrage — toutes les releases continuent indépendamment des résultats DAST
- Les résultats DAST ne sont pas conservés ou ne peuvent pas être liés à des déploiements spécifiques
- Le périmètre DAST ne couvre pas les applications exposées à l’extérieur
Catégorie de contrôle 7 : Journalisation, surveillance et conservation des preuves
Chaque contrôle dans le pipeline CI/CD doit produire des preuves, et ces preuves doivent être collectées, stockées et rendues accessibles pour l’audit. Cette catégorie couvre l’agrégation centralisée des journaux, la surveillance, les alertes et la conservation des preuves.
Ce qu’elle contrôle : La visibilité sur les activités des pipelines, la détection des incidents et la disponibilité des preuves d’audit.
Preuves produites : Journaux centralisés, tableaux de bord de surveillance, historiques d’alertes et enregistrements conservés de toutes les exécutions de pipelines et leurs résultats.
Ce que les auditeurs doivent vérifier :
- Les journaux de pipelines sont collectés de manière centralisée et ne peuvent pas être falsifiés
- Les périodes de conservation respectent les exigences réglementaires
- La surveillance couvre à la fois les événements de sécurité et la santé des pipelines
- Les preuves de tous les contrôles de sécurité (SAST, SCA, DAST, secrets, intégrité des artefacts) sont agrégées et accessibles
Signaux d’alerte :
- Les journaux sont stockés uniquement localement sur les agents de build et non centralisés
- Les périodes de conservation sont plus courtes que les exigences réglementaires
- Pas d’alertes sur les échecs de pipeline ou les contournements de contrôles de sécurité
- Les preuves des contrôles de sécurité ne peuvent pas être récupérées pour une release donnée
Résumé : Correspondance catégorie de contrôle — vérification d’audit
| Catégorie de contrôle | Objectif du contrôle | Preuves clés | Vérification d’audit |
|---|---|---|---|
| Sécurité du code source | Prévenir les modifications de code non autorisées | Journaux d’accès, approbations PR, configs de protection des branches | Vérifier l’application des workflows de revue et d’approbation |
| SAST | Détecter les vulnérabilités au niveau du code avant le déploiement | Rapports d’analyse, décisions de filtrage, enregistrements de suppression | Confirmer l’exécution automatisée et l’application des seuils |
| SCA | Gérer les risques tiers et de la chaîne d’approvisionnement | Inventaires de dépendances, SBOM, rapports de vulnérabilités | Vérifier l’inventaire actuel, la génération de SBOM et la réponse aux vulnérabilités connues |
| Gestion des secrets | Prévenir l’exposition des identifiants et l’accès non autorisé | Résultats d’analyse, journaux d’accès, enregistrements de rotation | Confirmer l’absence de secrets codés en dur, vérifier la rotation et la gouvernance d’accès |
| Intégrité du build | Garantir que les artefacts sont fiables et traçables | Artefacts signés, attestations de provenance, sommes de contrôle | Vérifier la signature, l’immuabilité et la traçabilité source-artefact |
| DAST | Valider la sécurité à l’exécution des applications déployées | Résultats d’analyse, décisions de filtrage, enregistrements d’exceptions | Confirmer l’exécution pré-release et la gestion documentée des exceptions |
| Journalisation et preuves | Fournir une piste d’audit et une visibilité sur les incidents | Journaux centralisés, enregistrements de surveillance, preuves conservées | Vérifier les périodes de conservation, la centralisation et la résistance à la falsification |
Conclusion
Les contrôles de sécurité CI/CD ne concernent pas les produits qu’une organisation déploie. Il s’agit de savoir si les bonnes catégories de contrôles sont en place, si ces contrôles sont appliqués de manière cohérente dans le pipeline, et s’ils produisent des preuves fiables que les auditeurs peuvent vérifier.
Lors de la revue de la sécurité CI/CD, les auditeurs doivent se concentrer sur l’application, la qualité des preuves, la traçabilité et la gouvernance — et non sur les noms de produits ou les listes de fonctionnalités.
Ressources connexes pour les auditeurs
- Glossaire des termes de sécurité et conformité CI/CD
- Contrôles de sécurité CI/CD fondamentaux
- Comment les auditeurs examinent réellement les pipelines CI/CD
- Conformité continue via CI/CD
