Sécurité CI/CD

Pourquoi les pipelines sont une cible

• Ils détiennent les clés. Les identifiants cloud, les tokens de registre et les clés de signature passent tous par la CI.
• Ils exécutent le code des autres. Chaque dépendance, script d'installation et action tierce s'exécute sur le runner.
• Ils atteignent la production. Ce qui sort du pipeline est considéré comme fiable, signé et livré. Un attaquant présent dans le build atteint tous les clients d'un coup.
• Peu de gens les surveillent. Les fichiers de workflow changent rarement et sont moins relus que le code applicatif.

La compromission de tj-actions et le ver npm Shai-Hulud ont tous deux visé les secrets en CI. Consultez qu'est-ce qu'une attaque de la chaîne d'approvisionnement pour voir comment ces attaques se déroulent.

Les principaux risques de sécurité CI/CD

L'OWASP Top 10 CI/CD Security Risks est la référence standard. Regroupés selon ce qui ne va pas :

Domaine	Risques OWASP	À quoi cela ressemble
Qui peut modifier quoi	Contrôle de flux insuffisant, gestion inadéquate des identités et des accès	Du code atteint la production sans revue, ou d'anciens comptes conservent leurs accès
Ce qui s'exécute dans le pipeline	Abus de la chaîne de dépendances, exécution de pipeline empoisonné	Un paquet malveillant ou un workflow modifié s'exécute avec les accès du job
Ce qu'un job peut atteindre	Contrôles d'accès insuffisants au niveau du pipeline, hygiène insuffisante des identifiants	Un seul job peut lire tous les secrets, et les tokens restent valides pendant des années
Comment l'ensemble est configuré	Configuration système non sécurisée, usage non encadré de services tiers	Des runners non patchés, et des intégrations dotées de plus d'accès que nécessaire
Ce que vous pouvez prouver	Validation incorrecte de l'intégrité des artefacts, journalisation et visibilité insuffisantes	Personne ne peut dire ce qui est entré dans une release ni à quoi un job s'est connecté

Pour chaque risque mis en regard des contrôles des runners, consultez le comparatif de la sécurité des runners.

Bonnes pratiques de sécurité CI/CD

1. Traitez les définitions de pipeline comme du code de production. Exigez une revue des fichiers de workflow, et tenez les pull requests non fiables à l'écart des secrets.
2. Limitez ce que chaque job peut faire. Donnez aux tokens le minimum de permissions nécessaire, et préférez des identifiants à courte durée de vie aux secrets stockés.
3. Épinglez les actions tierces sur un hash de commit. Les tags peuvent être déplacés vers un autre code.
4. Isolez les jobs. Exécutez chaque job dans un environnement neuf, afin que rien ne soit transmis au suivant.
5. Contrôlez le trafic sortant. Un build a besoin de sources connues et de destinations connues. Bloquer tout le reste empêche les secrets volés de sortir. Consultez la politique de trafic sortant GitHub Actions.
6. Enregistrez ce qui s'est passé. Conservez une SBOM de chaque build et un journal de son activité réseau, afin de pouvoir répondre aux questions par la suite.

Pour la version étape par étape, consultez la checklist de sécurité du pipeline CI/CD.

Types d'outils de sécurité CI/CD

Type	Ce qu'il fait	Exemples
Sécurité des runners	Isole les jobs et contrôle ce qu'ils peuvent atteindre pendant leur exécution	CRACI, StepSecurity
Gestion de la posture	Repère les réglages risqués des pipelines et des dépôts	Legit Security, Cycode, Apiiro, OX Security
Scan du code et des dépendances	Vérifie le code, les dépendances et les secrets à chaque changement	GitHub Advanced Security, Snyk, Semgrep
SBOM et preuves	Enregistre ce qui est entré dans chaque release	CRACI, Syft, Anchore

Ces outils interviennent à des étapes différentes : la plupart des équipes les combinent donc. Un scanner examine les fichiers avant le build, les outils de posture examinent les réglages, et la sécurité des runners agit pendant l'exécution du job, c'est-à-dire au moment où un paquet malveillant passe à l'action. Consultez le comparatif des outils de sécurité de la chaîne d'approvisionnement logicielle et le comparatif des outils DevSecOps.

La place de CRACI

CRACI sécurise le build pendant son exécution. Il remplace vos runners hébergés par GitHub par des runners plus rapides et moins chers : chaque job s'exécute dans sa propre machine virtuelle isolée, une politique de trafic sortant bloque les connexions dont le build n'a pas besoin, et chaque paquet récupéré par le job entre dans une SBOM. Comme la politique n'autorise que ce dont le build a besoin, elle vous protège même contre une attaque que personne n'a encore vue.

CRACI ne vérifie pas la configuration de vos workflows, ne scanne ni le code source ni les secrets, et ne signe pas la provenance : conservez ou ajoutez donc des outils pour cela. GitHub Actions est le système de CI pris en charge aujourd'hui, et d'autres systèmes de CI sont sur la roadmap.

Sécurité CI/CD : questions fréquentes

Qu'est-ce que la sécurité CI/CD ?

C'est la pratique qui consiste à protéger les pipelines qui construisent, testent et livrent les logiciels, y compris leurs identifiants, le code qu'ils exécutent et les artefacts qu'ils produisent.

Quels sont les plus grands risques de sécurité CI/CD ?

Les dépendances et actions tierces malveillantes, les pipelines empoisonnés, les tokens dotés de trop de permissions et les secrets à longue durée de vie, ainsi que le manque de visibilité sur ce qu'a fait un build. L'OWASP Top 10 CI/CD Security Risks est la liste de référence.

Qu'est-ce que l'exécution de pipeline empoisonné ?

Un attaquant modifie ce qu'un pipeline exécute, par exemple en changeant via une pull request un fichier de workflow ou un script qu'il appelle, afin que son code s'exécute avec les accès du pipeline.

Comment sécuriser un pipeline CI/CD ?

Relisez les changements de pipeline, donnez à chaque job le minimum d'accès nécessaire, épinglez les actions tierces par hash de commit, isolez les jobs, restreignez le trafic sortant et conservez un enregistrement de ce que chaque build a fait.

Quelle est la différence entre la sécurité CI/CD et le DevSecOps ?

Le DevSecOps est la pratique plus large qui consiste à intégrer la sécurité dans la façon de développer les logiciels. La sécurité CI/CD se concentre sur le pipeline lui-même, dont les outils DevSecOps dépendent aussi.

GitHub Actions a-t-il besoin d'une sécurité supplémentaire ?

GitHub fournit des contrôles tels que les permissions des tokens et la détection des secrets, mais vous devez les configurer, et les runners hébergés ne restreignent pas le trafic sortant par défaut. La plupart des équipes ajoutent l'épinglage, des règles de revue et des contrôles au niveau du runner.