Dans le paysage moderne du développement logiciel, le pipeline d'intégration et de déploiement continus (CI/CD) est la colonne vertébrale de la vitesse et de la qualité de livraison. Cependant, à mesure que les organisations accélèrent leurs cycles de déploiement, la surface d'attaque s'élargit. Les pipelines CI/CD sont devenus des cibles de haute valeur pour les acteurs malveillants cherchant à compromettre la chaîne d'approvisionnement logicielle. En injectant du code malveillant dans des artefacts de construction de confiance ou en volant des secrets, les attaquants peuvent contourner les contrôles de sécurité et distribuer des logiciels compromis à grande échelle.
Sécuriser le pipeline n'est plus une option ; c'est un composant critique de la sécurité des applications. Cet article explore des stratégies pratiques pour durcir votre infrastructure DevOps, en se concentrant sur l'identité, l'intégrité des artefacts et l'isolation des environnements.
Le paysage des menaces : pourquoi les pipelines sont des cibles
Les attaques par chaîne d'approvisionnement diffèrent des violations traditionnelles car elles exploitent la confiance que les développeurs accordent aux outils automatisés. Les vecteurs courants incluent :
- Confusion des dépendances : Les attaquants publient des paquets malveillants portant le même nom que des paquets internes pour exploiter les gestionnaires de paquets.
- Fuite de secrets : Clés API ou jetons codés en dur dans les scripts de construction qui sont ensuite commités dans le contrôle de version.
- Agents de construction compromis : Les attaquants accèdent aux runners partagés pour manipuler les résultats de la construction.
- Actions tierces malveillantes : Compromission des actions open-source GitHub Actions ou des scripts GitLab CI qui sont intégrés à votre pipeline.
Stratégie 1 : Imposer une vérification stricte des dépendances
L'un des moyens les plus efficaces de prévenir l'injection par chaîne d'approvisionnement est de s'assurer que chaque dépendance utilisée dans votre construction est vérifiée. Les gestionnaires de paquets modernes prennent en charge les fichiers de verrouillage (lockfiles) et les sommes de contrôle d'intégrité, mais vous devez en imposer l'utilisation.
Par exemple, lors de l'utilisation de npm ou yarn, commitez toujours le fichier package-lock.json. Cela garantit que l'environnement de construction utilise exactement les mêmes versions et hachages que ceux testés localement. De plus, activez la vérification des signatures de paquets lorsque cela est possible.
# Exemple : Imposer une résolution stricte des paquets dans package.json
{
"name": "secure-app",
"version": "1.0.0",
"dependencies": {
"express": "^4.18.2"
},
"overrides": {
"minimist": ">=1.2.6"
}
}La section overrides force le résolveur à utiliser une version corrigée d'une dépendance vulnérable, indépendamment de ce qu'un paquet tiers demande. Cela atténue le risque d'attaques par dépendance indirecte.
Stratégie 2 : Sécuriser la gestion des secrets
Le codage en dur des secrets dans les fichiers de configuration CI/CD est une vulnérabilité critique. Au lieu de cela, utilisez les fonctionnalités intégrées de gestion des secrets fournies par votre plateforme CI, telles que GitHub Secrets, les variables CI GitLab ou des coffres-forts externes comme HashiCorp Vault.
Assurez-vous que les secrets ne sont jamais journalisés. Dans de nombreux systèmes CI, les variables sont automatiquement masquées dans les journaux, mais vous devez également assainir votre code.
De plus, mettez en œuvre un accès à privilège minimum pour les comptes de service. Un script de construction ne doit avoir que les autorisations nécessaires pour pousser vers des registres d'artefacts spécifiques, et non un accès administratif complet au référentiel.
Stratégie 3 : Épingler les dépendances de votre workflow
Si vous utilisez des workflows réutilisables ou des actions tierces dans votre pipeline CI/CD (par exemple, dans GitHub Actions), épinez-les toujours à un hachage de commit (SHA) spécifique plutôt qu'à une balise mutable comme v1. Les balises peuvent être mises à jour ou écrasées par des attaquants qui compromettent un référentiel.
# Insécurisé : Utilisation de balises mutables
- uses: actions/checkout@v3
# Sécurisé : Épinglé à un hachage de commit spécifique
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11Cette pratique garantit que votre pipeline se comporte de manière cohérente et est immunisé contre les attaques de prise de contrôle de référentiel qui pourraient modifier le contenu d'une version balisée.
Stratégie 4 : Isoler les environnements de construction
Les agents de construction éphémères qui créent un environnement propre pour chaque tâche réduisent le risque de pollution de l'état et de contamination inter-tâches. Évitez d'utiliser des serveurs de construction partagés et à longue durée de vie où une tâche compromise pourrait affecter les constructions suivantes.
De plus, mettez en œuvre l'autorisation binaire ou des politiques similaires qui empêchent le déploiement d'artefacts non signés ou non vérifiés en production. Cela crée une dernière étape de validation qui vérifie l'intégrité du logiciel avant qu'il n'atteigne les utilisateurs.
Conclusion
Sécuriser les pipelines CI/CD nécessite un changement de paradigme, passant d'une sécurité basée sur la périmètre à une mentalité de confiance zéro. En vérifiant les dépendances, en gérant rigoureusement les secrets, en épinglant les workflows et en isolant les environnements, les organisations peuvent réduire considérablement leur surface d'attaque. À mesure que les attaques par chaîne d'approvisionnement deviennent plus sophistiquées, la sécurité proactive des pipelines est la seule défense qui garantit l'intégrité du logiciel, de l'engagement du code au déploiement en production.