La sécurité du pipeline CI/CD est devenue un enjeu critique pour les organisations modernes. Une compromission peut donner accès aux secrets de production et permettre des déploiements malveillants d’artefacts.
Après SolarWinds, la perception du risque a changé et la pratique du DevSecOps s’est généralisée dans les équipes d’ingénierie. Les points essentiels suivent, synthétisés pour une mise en œuvre rapide.
A retenir :
- Security gates automatisés à chaque étape du pipeline
- Gestion des secrets centralisée et rotation automatique pour limiter la fenêtre
- Signature d’artefacts avec Sigstore pour intégrité et traçabilité
- Isolation des runners et permissions au moindre privilège
Sécuriser le pipeline CI/CD avec des security gates DevSecOps
Après la synthèse, il convient de détailler les points de contrôle automatisés qui arrêtent les risques tôt. Les security gates appliquent des règles sur le code, les dépendances et les artefacts avant toute progression.
Placer des gates à plusieurs niveaux réduit la surface d’attaque et facilite le fail fast pour corriger en amont des vulnérabilités. Le chapitre suivant couvrira la gestion des secrets et la signature pour compléter ces gates.
Fonctionnellement, un gate doit vérifier les secrets, le SAST et le SCA, puis bloquer en cas de risque critique. L’objectif est d’empêcher toute diffusion d’artefacts compromis vers les registres ou la production.
Selon CISA, une compromission du pipeline peut mener à une propagation massive et difficile à détecter. Selon Microsoft, la chaîne de build est devenue une cible prioritaire pour les acteurs avancés.
À retenir pour l’action : définir des règles claires, automatiser les contrôles et prévoir des seuils adaptés à la vélocité des équipes. Ces mesures préparent le terrain pour la signature et l’isolation des artefacts.
Architecture et rôle des gates dans un pipeline sécurisé
Ce point explique comment les gates se positionnent dans le cycle CI/CD pour maximiser l’efficacité. Ils doivent être distribués en Pre-commit, PR, Build et Deploy afin de capter les problèmes à l’origine.
Un gate mal configuré peut être contourné, d’où l’importance d’une défense en profondeur et d’un enchaînement cohérent des contrôles. Chaque gate corrige ou bloque avant la suivante.
Voici un tableau qui reprend les rôles de chaque gate et les actions associées pour un pipeline standard.
Gate
Position
Ce qu’il vérifie
Action si échec
Pre-commit
Avant le commit
Secrets, formatage
Bloque le commit
PR Gate
À l’ouverture de PR
SAST, SCA, tests
Bloque le merge
Build Gate
Après compilation
Scan d’image, signature
Bloque la publication
Deploy Gate
Avant déploiement
Approbation, checks finaux
Bloque le déploiement
Selon Reuters, l’attaque SolarWinds a montré la capacité d’une compromission de build à toucher des milliers d’organisations. Les gates doivent donc être conçus pour empêcher ce scénario.
Stratégie de seuils :
- Blocage automatique pour CVE critical et secrets détectés
- Alerte visible en PR pour high cvss sans exploit connu
- Quarantaine des artefacts avec signature manquante
« J’ai vu un gate PR sauver notre branche main en stoppant une dépendance vulnérable »
Pierre N.
Gestion des secrets et signature d’artefacts pour CI/CD sécurisé
Après les gates, la protection des secrets et la signature des artefacts deviennent indispensables pour garantir la confiance. Sans ces mécanismes, un gate efficace reste insuffisant face à une fuite de credentials.
La règle absolue : jamais de secret dans le code, seulement des références à un gestionnaire dédié, avec rotation régulière et journalisation des accès. Le paragraphe suivant aborde les outils et les fréquences de rotation recommandées.
Privilège minimal, isolation des environnements et tokens éphémères réduisent le risque lié à une fuite involontaire. L’usage d’OIDC pour fournir des tokens temporaires évite les secrets statiques dans les workflows.
Selon Microsoft, la mise en place de rotation automatique et d’audit réduit fortement la fenêtre d’exploitation des secrets exposés. Ces pratiques s’intègrent naturellement au DevSecOps.
Principes non négociables de gestion des secrets
Ce paragraphe expose les règles de base pour limiter le risque lié aux secrets dans le pipeline. Elles doivent être appliquées par défaut et validées par les gates automatisés.
Les cinq principes incluent externaliser les secrets, moindre privilège, séparation des environnements, rotation automatique et audit systématique. Chacun réduit un vecteur d’attaque fréquent et concret.
Bonnes pratiques clés :
- Jamais de secret hardcodé dans le repo Git
- Tokens éphémères via OIDC plutôt que secrets statiques
- Segmentation dev/staging/production avec secrets distincts
- Rotation automatique et logs d’accès centralisés
« Une rotation quotidienne des tokens a réduit nos incidents de fuite à presque zéro »
Claire N.
Signature d’artefacts avec Sigstore et attestations SLSA
Ce point explique pourquoi signer les images et produire des attestations augmente la confiance de bout en bout. Une signature prouve l’intégrité et la provenance d’un artefact avant déploiement.
Sigstore permet de signer sans gérer de clé privée, en s’appuyant sur OIDC et des certificats éphémères, ce qui abaisse la barrière opérationnelle. Rekor fournit un journal public et vérifiable des signatures.
Composant
Rôle
Analogie
Cosign
Signer et vérifier les artefacts
Le stylo qui signe
Fulcio
Émission de certificats éphémères
Le notaire qui certifie l’identité
Rekor
Log de transparence des signatures
Le registre public des sceaux
Attestations
Métadonnées du build (commit, dépendances)
La fiche d’identité de l’artefact
Selon CISA, la traçabilité des signatures et des attestations facilite la détection des atteintes à la supply chain. Vérifier signatures et attestations reste une étape non négociable avant déploiement.
« La signature keyless a simplifié notre pipeline de release et renforcé la confiance »
Émilie N.
Isolation des runners, SLSA et limitation du blast radius pour le déploiement continu
Après la signature, il faut réduire l’impact d’une compromise possible en isolant l’exécution du pipeline. L’isolation limite le blast radius et empêche tout pivot vers les environnements sensibles.
Les runners éphémères, réseaux cloisonnés et permissions minimales forment une barrière complémentaire aux gates et à la gestion des secrets. Le paragraphe suivant traite des niveaux SLSA et des attestations reconstructibles.
Visez SLSA 2 puis SLSA 3 pour les workloads critiques, en conservant la traçabilité et la reproductibilité des builds. Ceci améliore la résilience de bout en bout au sein du CI/CD.
Mesures pratiques d’isolation et runners éphémères
Ce segment détaille comment cloisonner compute et réseau pour limiter l’impact d’un job compromis. Les runners doivent être éphémères, dans des VPC dédiés et sans accès par défaut au réseau interne.
Checklist de maturité :
- Runners éphémères ou hébergés par la plateforme CI
- Permissions minimales pour chaque job
- Séparation stricte des environnements dev/staging/prod
- Audit des accès et logs centralisés
Un runner persistant devient un point d’ancrage pour l’attaquant, comme l’illustre une attaque historique où un job malveillant a persisté. Préférer des environnements jetables pour chaque exécution.
SLSA, attestations et preuves de provenance pour le déploiement sécurisé
Ce passage explique l’importance des niveaux SLSA pour mesurer la maturité de votre supply chain logicielle. Les attestations signées relient le commit, le build et le runner de manière vérifiable.
En pratique, une progression par paliers vers SLSA 3 fournit une garantie forte sans imposer des changements impossibles pour les équipes. L’objectif final est de rendre la falsification techniquement coûteuse.
Un dernier conseil opérationnel : automatiquez audits, SBOM et vérifications des signatures avant chaque déploiement continu pour maintenir la confiance de production. Ce point appelle une gouvernance intégrée.
« Mettre en place SLSA 2 nous a permis de détecter des builds non conformes avant production »
Marc N.
Source : Microsoft, « Microsoft Digital Defense Report 2021 », Microsoft Security, 2021 ; CISA, « AA20-352A: SUNBURST backdoor technical details », CISA, 2020 ; Reuters, « SolarWinds hack affected 18,000 customers », Reuters, 2021.