Avez-vous entendu parler de Dependabot ? Sinon, demandez à n’importe quel développeur autour de vous, et il sera probablement ravi de la façon dont cela a révolutionné la tâche fastidieuse de vérification et de mise à jour des dépendances obsolètes dans les projets logiciels.
Dependabot s’occupe non seulement des vérifications à votre place, mais propose également des suggestions de modifications qui peuvent être approuvées en un seul clic. Bien que Dependabot soit limité aux projets hébergés sur GitHub, il a établi une nouvelle norme permettant aux fournisseurs continus d’offrir des fonctionnalités similaires. Cette automatisation des tâches « administratives » est devenue une norme, permettant aux développeurs d’intégrer et de déployer leur travail plus rapidement que jamais. Les workflows d’intégration et de déploiement continus sont devenus la pierre angulaire de l’ingénierie logicielle, propulsant le mouvement DevOps à l’avant-garde du secteur.
Mais un avis récent par la société de sécurité Checkmarx met en lumière un incident préoccupant. Des acteurs malveillants ont récemment tenté d’exploiter la confiance associée à Dependabot en se faisant passer pour l’outil. En imitant les suggestions faites par Dependabot (sous forme de pull request), ces acteurs ont tenté de tromper les développeurs pour qu’ils acceptent les changements sans y réfléchir à deux fois.
Bien que Dependabot illustre les progrès réalisés dans l’automatisation des tâches de maintenance logicielle, cet incident souligne également les complexités et les vulnérabilités plus larges inhérentes aux pipelines CI/CD. Ces pipelines servent de conduits essentiels, reliant le monde externe des outils et plates-formes de développement de logiciels aux processus internes de création et de déploiement de logiciels. Comprendre ce lien est essentiel pour relever les défis de sécurité auxquels nous sommes confrontés.
Pipelines CI/CD : connecter le monde extérieur au monde interne
Les workflows d’intégration continue (CI) et de déploiement (CD) ont révolutionné le processus de développement logiciel, offrant aux développeurs la possibilité de fusionner en toute transparence leur travail et de le déployer dans l’environnement de production. Ces flux de travail garantissent que le code est soumis à des analyses de sécurité automatisées, à des tests rigoureux et au respect des normes de codage, ce qui se traduit par un processus de développement plus efficace et plus fiable. Ils sont devenus un catalyseur d’innovation, permettant aux équipes de se concentrer sur la construction et l’amélioration de leurs produits avec l’assurance de qualité et de sécurité.
Pour illustrer le concept, imaginez construire un puzzle. CI agit comme un vérificateur vigilant, vérifiant que chaque nouvelle pièce du puzzle s’ajuste correctement avant d’avancer. D’un autre côté, CD va encore plus loin en plaçant automatiquement chaque pièce vérifiée dans le puzzle final, éliminant ainsi le besoin d’attendre que l’ensemble du puzzle soit terminé. Ce processus accéléré permet une livraison plus rapide des fonctionnalités et, en fin de compte, accélère le calendrier global de développement du produit.
Cependant, ces flux de travail CI/CD connectent également le monde extérieur à l’environnement de développement interne, créant ainsi des risques potentiels. Par exemple, considérons un scénario dans lequel un développeur intègre une bibliothèque tierce dans son projet via un pipeline CI/CD. Si le développeur ne vérifie pas minutieusement la bibliothèque ou si le pipeline ne dispose pas de contrôles de sécurité appropriés, un code malveillant pourrait être incorporé sans le savoir dans le projet, compromettant ainsi son intégrité. Ces dernières années, on a assisté à une multiplication d’attaques telles que typosquatting et confusion des dépendancesqui visent à exploiter le recours aux logiciels open source à des fins financières.
L’essor des flux de travail d’intégration automatisés a modifié la situation économique des attaquants en réduisant les coûts et en augmentant les gains potentiels d’une attaque. Les attaquants peuvent cibler des référentiels de packages centraux populaires comme PyPi, qui héberge des milliers de packages et effectue des millions de téléchargements quotidiennement. L’ampleur des opérations rend économiquement viable pour les attaquants de tenter leur chance, même avec de faibles chances de succès.
Un autre exemple est l’utilisation d’API externes dans les pipelines CI/CD. Les développeurs doivent souvent fournir des informations d’identification valides pour ces API afin de permettre un déploiement automatisé ou une intégration avec des services externes. Toutefois, si ces informations d’identification ne sont pas gérées de manière sécurisée ou si elles sont exposées par inadvertance dans des journaux ou des artefacts, ils peuvent être exploités par des attaquants pour obtenir un accès non autorisé à des ressources sensibles ou manipuler le comportement du pipeline.
Les violations CI/CD proviennent souvent soit d’une compromission initiale de secrets, soit de développeurs devenus la cible d’attaques spécifiques. Cependant, plutôt que de blâmer les développeurs pour ces violations, il est crucial de reconnaître que le problème réside dans le manque de sécurité inhérent à ces pipelines. Cela met en évidence un problème plus vaste : les pipelines CI/CD sont loin d’être sécurisés par défaut.
Le problème : les pipelines CI/CD sont loin d’être sécurisés par défaut
Bien que l’idée de mettre en œuvre des flux de travail sécurisés dès la conception soit de plus en plus populaire, les plateformes CI/CD ont encore un long chemin à parcourir. Des plates-formes telles que GitHub Actions, GitLab CI/CD et CircleCI, qui ont été initialement conçues dans un souci de flexibilité, donnent souvent la priorité à la facilité d’utilisation plutôt qu’à des mesures de sécurité robustes. En conséquence, il existe un manque de garanties par défaut pour empêcher que des problèmes potentiels ne surviennent.
Un exemple frappant de cela est la facilité avec laquelle un développeur expose des informations sensibles telles que des secrets. Les développeurs injectent généralement des secrets au moment de l’exécution et s’appuient pour cela sur la capacité de stocker des secrets dans le fournisseur CI lui-même. Bien que cette pratique ne soit pas un problème en soi, elle soulève au moins deux problèmes de sécurité : premièrement, le fournisseur de CI hébergeant les secrets devient un coffre-fort d’informations sensibles et une cible attrayante pour les attaquants. Pas plus tard qu’au début de 2023, CircleCI a subi une violation de ses systèmes qui a forcé les utilisateurs à alterner « tous » leurs secrets suite à une violation des systèmes de l’entreprise.
Deuxièmement, les secrets peuvent souvent être divulgués et passer inaperçus via les pipelines CI/CD eux-mêmes. Par exemple, si un secret est concaténé avec une autre chaîne (par exemple, une URL) puis enregistré, le mécanisme de suppression du CI ne fonctionnera pas. Il en va de même avec les secrets codés. La conséquence est que les journaux CI exposent souvent des secrets en clair. De même, c’est pas rare du tout pour trouver des secrets codés en dur dans des artefacts logiciels, résultat d’un flux de travail d’intégration continue mal configuré.
Les fournisseurs CI/CD ont déjà pris des mesures pour améliorer la sécurité, comme les contrôles de sécurité GitHub Dependabot. Mais la plupart du temps, les valeurs permissives par défaut et les modèles d’autorisation complexes restent la règle. Pour protéger les pipelines CI/CD et empêcher la compromission du code, les développeurs doivent prendre des mesures supplémentaires pour renforcer leurs pipelines contre les attaques. Un aspect crucial est d’assurer la protection des informations d’identification des développeurs. Une autre solution consiste à adopter une approche proactive de la sécurité avec des déclencheurs d’alerte.
Sauvegarder le CI/CD et la chaîne d’approvisionnement logicielle
Pour sécuriser efficacement les pipelines CI/CD, il est crucial de les considérer comme des environnements hautement prioritaires, potentiellement connectés en externe. La clé est un mélange de bonnes pratiques :
- Restreindre l’accès et minimiser les privilèges: Accordez l’accès en fonction de la nécessité et non de la commodité. Un accès étendu à tous les membres de l’équipe DevOps augmente le risque qu’un compte compromis fournisse aux attaquants un accès étendu au système. Limitez l’accès aux contrôles, configurations ou données sensibles critiques.
- Appliquer l’authentification multifacteur (MFA): Surtout, utilisez toujours l’authentification multifacteur (MFA) pour vous connecter à la plateforme CI/CD. MFA ajoute une couche de sécurité essentielle, rendant beaucoup plus difficile l’accès des utilisateurs non autorisés, même s’ils ont des informations d’identification compromises.
- Utiliser OpenID Connect (OIDC): utilisez OIDC pour connecter en toute sécurité les charges de travail à des systèmes externes, par exemple pour le déploiement. Ce protocole fournit un cadre robuste pour l’authentification et la vérification d’identité entre domaines, ce qui est essentiel dans un environnement distribué et interconnecté.
- Utiliser des dépendances logicielles pré-révisées: Il est important de fournir aux développeurs des dépendances logicielles sûres et pré-révisées. Cette pratique protège l’intégrité de la chaîne d’approvisionnement et évite aux développeurs d’avoir à vérifier le code de chaque package. Cela garantit l’intégrité de la chaîne d’approvisionnement, soulageant les développeurs de la charge de vérifier individuellement le code de chaque package.
- Secrets d’exécution sécurisés: Le stockage en toute sécurité des secrets tels que les clés API et les informations d’identification dans la plate-forme CI/CD nécessite des mesures de sécurité strictes, telles que l’authentification MFA renforcée et les contrôles d’accès basés sur les rôles (RBAC). Toutefois, ces mesures ne sont pas infaillibles. Les secrets sont divulgués par natureet des niveaux de sécurité supplémentaires, comme une hygiène rigoureuse des informations d’identification et une surveillance vigilante des menaces internes et externes, sont nécessaires pour une protection complète.
- Mettre en œuvre des systèmes de défense avancés: Intégrez des systèmes d’alerte dans votre cadre de sécurité. Bien que les pots de miel soient efficaces mais difficiles à mettre à l’échelle, jetons de miel offrir une alternative évolutive et facile à mettre en œuvre. Ces jetons, nécessitant une configuration minimale, peuvent améliorer considérablement la sécurité des entreprises de toutes tailles sur diverses plates-formes telles que les systèmes SCM, les pipelines CI/CD et les registres d’artefacts logiciels.
- Tirer parti des solutions à l’échelle de l’entreprise: Des solutions comme Plateforme GitGuardian offrent un panneau de contrôle unique pour surveiller les incidents tels que les fuites de secrets, les erreurs de configuration de l’infrastructure en tant que code et les déclencheurs de jetons de miel, permettant aux organisations de détecter, corriger et prévenir les incidents CI/CD à grande échelle. Cela atténue considérablement l’impact des violations potentielles de données.
En combinant ces stratégies, les organisations peuvent protéger complètement leurs pipelines CI/CD et leur chaîne d’approvisionnement en logiciels, en s’adaptant à l’évolution des menaces et en maintenant des protocoles de sécurité robustes. Commencez dès aujourd’hui à sécuriser vos pipelines avec le Plateforme GitGuardian.