Divulgation responsable : le CEO et le CTO de CodeCov partagent les enseignements tirés de la brèche

En janvier 2021, CodeCov a été victime d’une attaque de la chaîne d’approvisionnement qui a exposé les variables d’environnement de ses clients. Au cours des mois suivants, la communauté de la sécurité des applications a examiné en détail les circonstances de la brèche et ses implications techniques afin de comprendre ce qui s’était passé et comment contrer des attaques similaires à l’avenir. Mais cette brèche a également mis en lumière un sujet un peu moins spectaculaire : la divulgation responsable.

En octobre 2021, le CEO de CodeCov, Jerrod Engelberg, et son CTO, Eli Hooten, sont intervenus dans le podcast The Secure Developer pour livrer leur témoignage de l’intérieur. Leur conversation avec Guy a montré ce que signifie être au cœur d’un incident et soulevé des questions intéressantes sur la meilleure façon de réagir à des incidents similaires.

Écoutez l’épisode complet dès aujourd’hui

L’incident de sécurité de CodeCov

Avant d’examiner les implications de cet épisode, revenons rapidement sur les faits. CodeCov est un outil de couverture de code qui génère des rapports lisibles par machine lorsque les développeurs exécutent des tests. Ces rapports sont traités par l’uploader de CodeCov, qui extrait les données de couverture pertinentes. Ils lui parviennent via un fournisseur d’intégration continue comme GitHub, GitLab ou Bitbucket, ce qui place CodeCov au cœur de la chaîne d’approvisionnement logicielle.

Au moment de l’incident, CodeCov utilisait un script curl|bash (aussi appelé « curl pipe bash », « curl bash piping », etc.) pour transférer les rapports vers son serveur, hébergé dans un bucket CDN `private write, public read`. L’attaquant a pu extraire un identifiant d’une couche compressée de l’image Docker Enterprise de CodeCov et accéder au bucket CDN, où il a modifié le script bash à des fins malveillantes. Le script altéré a été intégré au pipeline CI de chaque client ayant créé une pull request ou une merge request entre la brèche et la révocation des identifiants. Les attaquants ont ainsi pu infiltrer les environnements clients où s’exécutait la CI, afficher les variables d’environnement et les transmettre à un serveur tiers pour les utiliser ultérieurement.

L’impact de cette attaque a varié d’un client à l’autre. Si le client gérait sa CI dans un dépôt public, ses variables d’environnement ne contenaient probablement rien de sensible. En revanche, si le client utilisait un dépôt privé, où la CI interagit étroitement avec la pile technologique et contient des informations secrètes, la brèche était très préoccupante.

Comme dans toute attaque de la chaîne d’approvisionnement, une seule chose était certaine : des informations avaient été divulguées. Impossible de savoir ce que les attaquants comptaient faire des variables d’environnement volées. L’équipe devait donc agir rapidement et avec détermination.

La réponse de CodeCov

Engelberg a résumé ainsi la philosophie de CodeCov en matière de divulgation : « Si un seul client ne peut pas être informé par nos soins et ne prend pas les mesures qui s’imposent, c’est déjà un client de trop. » Dans la pratique, cette volonté s’est toutefois heurtée à un obstacle. Lorsqu’ils se connectent à CodeCov, les clients peuvent choisir une adresse e-mail ou un fournisseur d’identité social (comme OAuth, GitHub ou Bitbucket), ce qui protège la confidentialité de leurs coordonnées. Un choix pratique qui est ensuite devenu un facteur déterminant dans le processus de divulgation.

Pour les clients qui avaient créé un compte directement auprès de CodeCov ou communiqué leurs coordonnées, la solution était simple : des notifications par e-mail ont été envoyées à toutes les adresses disponibles pour les informer de la brèche et les inciter à agir. Malheureusement, la majorité des utilisateurs de CodeCov ne faisaient pas partie de ce groupe. L’équipe a donc tout mis en œuvre pour joindre chacun des autres clients.

Après avoir signalé l’incident aux autorités fédérales, CodeCov a procédé à des divulgations publiques. Les annonces détaillant la brèche ont été relayées et amplifiées par les médias spécialisés, et CodeCov a multiplié les notifications dans son application. Toutes les mesures raisonnables ont été prises pour informer ses utilisateurs, mais les circonstances qui ont conduit à cette réaction d’envergure méritent réflexion.

Si CodeCov avait exigé que tous ses utilisateurs communiquent des informations personnelles, comme une adresse e-mail, il aurait été simple de les joindre après la brèche. En leur permettant d’utiliser un fournisseur d’identité social, l’entreprise leur a donné plus de contrôle sur la confidentialité de leurs données personnelles, mais cela a aussi compliqué les communications urgentes. Le processus de divulgation de CodeCov aurait-il été différent s’il avait suffi d’envoyer un e-mail groupé pour informer les utilisateurs ? Probablement pas. Comme l’a dit Hooten : « Je pense qu’on sait qu’on fait ce qu’il faut quand la réponse est évidente, même si la suite s’annonce pénible ou difficile. » Les valeurs fondamentales de CodeCov auraient de toute façon poussé son équipe à faire preuve de transparence.

Limiter l’impact sur l’entreprise grâce à la transparence

Aucune entreprise ne sort indemne d’un incident de sécurité, mais CodeCov a pu en limiter les effets négatifs grâce à une communication continue et transparente. Malgré la rapidité de sa réaction, l’entreprise a perdu quelques clients. Engelberg explique : « Certains clients nous ont dit : “Hé, nous ne pouvons pas vous utiliser pour le moment.” Ou des utilisateurs convaincus par notre produit nous ont dit : “Hé, j’adore votre produit, mais le moratoire a été décrété et je ne peux plus l’utiliser.” » Sans la transparence dont l’équipe a fait preuve, les pertes auraient toutefois été bien plus importantes. Il est bien plus facile de corriger des vulnérabilités que de rétablir la confiance.

Comme Snyk, CodeCov est une application conçue pour les développeurs — et les développeurs ont besoin de faits, pas de discours enjolivés. En s’en tenant aux faits et en sollicitant l’aide de la communauté élargie de la sécurité, CodeCov a préservé sa crédibilité et son engagement envers les développeurs, même au cœur de la crise.

Au-delà de la brèche

La brèche de sécurité de CodeCov a révélé des réalités qui dépassent largement le cadre d’un incident isolé. La nature de l’attaque met en évidence des écueils potentiels qui concernent l’ensemble du secteur, notamment un problème de distribution à la base. À mesure que les logiciels open source deviennent toujours plus essentiels au cycle de développement, leurs dépendances s’intègrent elles aussi à la chaîne. Les avantages de l’open source sont indéniables. L’enjeu est de déterminer comment en tirer parti en toute sécurité.

Après la brèche, CodeCov a renforcé sa sécurité en ajoutant notamment des sommes de contrôle SHA et la vérification des signatures. Les utilisateurs étaient encouragés à recourir à ces vérifications pour s’assurer que les scripts téléchargés provenaient bien de CodeCov. Il reste toutefois impossible d’imposer leur utilisation. Comme l’a expliqué Engelberg : « Tant qu’on n’est pas en zéro confiance […] il y a toujours cette poignée de main, n’est-ce pas ? On peut la rendre de plus en plus sophistiquée, mais c’est un sujet auquel je réfléchis beaucoup pour la suite et pour savoir ce qui pourrait venir après. »

Nous pouvons sensibiliser les utilisateurs aux risques potentiels et leur fournir des outils pour auditer le code, mais nous ne pouvons pas les obliger à prendre des mesures supplémentaires. Cet accord tacite entre l’entreprise et le client est profondément ancré dans la culture du développement. En tant que secteur, nous devons déterminer la meilleure stratégie pour atténuer les risques.

Vous souhaitez en savoir plus sur la brèche de CodeCov et ce qu’elle a révélé sur le secteur ? Rendez-vous sur The Secure Developer pour écouter le podcast dans son intégralité. Engelberg et Hooten ont ouvert les portes de CodeCov et partagé leur expérience directe sur la préparation interne en matière de sécurité, leurs conseils aux CEO et CTO, la façon dont l’empathie a infléchi le cours de la crise, et bien plus encore.