Menaces

L’OWASP publie un classement des risques pesant sur un pipeline CI/CD (comme AWS codepipeline, GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Travis CI…) parmi lesquels :

• Failles de sécurité dans le code des développeurs (exemple de référentielpour intégrer la sécurité dans le développement) et le code externe.
• Compromission du pipelinepermettant à un attaquant d’insérer ou de modifier le code. 
• Faiblesse des mesures de contrôle d’accès au pipeline.
• Défaut de configurations systèmes, réseaux ou applicatifs.
• Utilisation d’applications ou d’APIexternes présentant des failles. 
• Exposition de secrets (clés, mots de passe) par exemple dans les gabaritsIaC - infrastructure as code. 

Voici des exemples de scenarios opérationnels d’attaques. 

• Compromission des secrets d’authentification d’un développeur (clé SSH, mots de passe, token…) pour accéder à un emplacement de stockage du code, un service du pipeline ou à la configuration d’un service système. 
• Compromission d’une librairie tierce, d’une image de containeur.
• Compromission d’un pipelinegéré par un prestataire.

On peut utiliser la méthode EBIOS Risk Manager pour proposer des scénarios opérationnels de risques adaptés à son environnement en s’appuyant sur le référentiel ATTT&CK. Pour les mesures de traitement du risque, on peut s’appuyer sur le référentiel de contre-mesures du MITRE. 

Mesures de traitement

Voici quelques exemples de mesures de sécurité pour traiter les risques de sécurité du pipeline.

• Mise en œuvre d’une approche Zero-Trust
• Imposer deux comptes différents pour les actions à risque (soumission de code par exemple).
• Utilisation de mécanismes de signature électronique du code.
• Respect du principe du moindre privilège pour les accès et les actions. 
• Segmentation du réseau et filtrage des flux (par exemple dans le cas du Cloud entre les VPC – Virtual Private Cloudet le pipeline). 
• Restriction d’utilisation des librairies externes.
• Analyse automatique du code soumis pour détecter des failles potentielles (SAST - Static application security testingdans la phase buildet DAST - Dynamic analysis security testing dans la phase test). Ces outils sont loin d’être efficace pour détecter toutes les failles. Les analyses doivent aussi prévoir des phases manuelles. 
• Mise en place d’outils EDR – Endpoint Detection andResponse sur les serveurs. 
• Mise à jour des correctifs de sécurité sur l’ensemble de l’environnement.
• Assurer une bonne traçabilité des actions permettant les analyses a posteriorimais aussi la possibilité de configurer des règles d’alerte pour le SOC.
• Utilisation de services sécurité pour mettre sous contrôle la gestion des secrets (par exemple AWS Secret Manager).