Incident de sécurité de la chaîne d’approvisionnement chez CircleCI : faites tourner vos secrets
7 janvier 2023
0 minutes de lectureLe 4 janvier, CircleCI, un outil de configuration de pipelines CI/CD automatisés, a signalé un incident de sécurité concernant son produit dans un avis.
Contexte de l’incident CircleCI
Le 27 décembre, l’ingénieur en sécurité Daniel Hückmann a reçu un e-mail l’avertissant d’une possible intrusion dans son compte CircleCI, grâce à un AWS CanaryToken qu’il avait mis en place. Le leurre, sous la forme d’une clé AWS, a probablement été activé par l’attaquant. Ces leurres, également appelés honeytokens, peuvent être installés dans les systèmes pour enquêter sur les intrusions et les détecter. Lorsqu’un attaquant les active, ils vous alertent de possibles failles de sécurité.
Le 4 janvier 2022, CircleCI a conseillé à ses clients de faire tourner leurs secrets à la suite d’un incident de sécurité :

Par souci de transparence, Snyk est à la fois partenaire et client de CircleCI.
Recommandations de CircleCI aux utilisateurs
CircleCI a recommandé à tous les utilisateurs de faire immédiatement tourner tous les secrets stockés sur sa plateforme, qu’ils se trouvent dans les variables d’environnement des projets ou dans des contextes. L’entreprise conseille également d’examiner les journaux internes afin de repérer tout accès non autorisé entre le 21 décembre 2020 et le 4 janvier 2023, ou après la rotation des secrets. CircleCI a invalidé les jetons API personnels et de projet, et fait tourner tous les jetons OAuth de GitHub et Bitbucket.
Si vous travaillez dans le développement logiciel ou dans des environnements d’infrastructure, vous devez savoir que faire tourner les secrets peut être difficile et perturber les workflows CI/CD. Voici ce que vous pouvez faire :
Dressez l’inventaire des variables d’environnement utilisées dans tous vos projets et pipelines, y compris celles stockées au niveau du contexte et du projet.
Ne supprimez pas vos secrets de CircleCI : révoquez-les plutôt afin d’empêcher d’éventuels acteurs malveillants d’y accéder.
Veillez à faire tourner les variables d’environnement et les clés SSH.
Les conséquences de la dispersion des secrets sur la chaîne d’approvisionnement logicielle
Le fait de stocker des secrets, comme des mots de passe et des clés API, à plusieurs endroits est appelé « dispersion des secrets » et peut compliquer leur gestion et leur protection. Ce phénomène peut se produire au sein d’une organisation, mais aussi dans la chaîne d’approvisionnement logicielle. Lorsque les secrets sont dispersés dans différents emplacements, il devient difficile de les suivre et de les mettre à jour, ce qui augmente le risque d’accès non autorisé. L’utilisation de privilèges à longue durée de vie, également appelés secrets statiques, qui ne sont pas régulièrement renouvelés, pose un autre problème.
Les plateformes de gestion des secrets peuvent les stocker et les chiffrer efficacement, mais les secrets statiques restent vulnérables. Ils peuvent fuiter s’ils sont inclus en texte brut dans le code source d’une application, consignés dans ses journaux ou stockés dans des fichiers de configuration. Plus un secret est utilisé, plus le risque qu’il soit compromis est élevé. De plus, les secrets statiques peuvent accorder des privilèges persistants sur plusieurs systèmes et ainsi permettre aux pirates de conserver leur accès à votre infrastructure.
L’utilisation d’identifiants statiques partagés et largement répandus peut entraîner plusieurs problèmes : absence de propriétaire clairement identifié, identifiants obsolètes qui n’ont pas été supprimés après la mise hors service de services, absence de processus de rotation régulier, absence de date d’expiration ou de durée de vie limitée, et utilisation inutile d’identifiants statiques alors que des mécanismes de contrôle d’accès plus sûrs, comme des jetons dynamiques à courte durée de vie, sont disponibles.
Lors d’une attaque de la chaîne d’approvisionnement, un pirate s’infiltre dans la chaîne d’approvisionnement d’une entreprise pour accéder à ses systèmes ou à ses données. Cette situation peut être particulièrement dangereuse, car elle permet au pirate de contourner les mesures de sécurité et d’accéder à des informations sensibles. L’attaquant tentera souvent de compromettre le code source ou les processus de build, de lancer des activités malveillantes ou de faciliter d’autres compromissions en aval de la chaîne d’approvisionnement.
Il est important que les organisations prennent conscience des risques liés à la dispersion des secrets et mettent en place des mesures pour prévenir les attaques de la chaîne d’approvisionnement. Les produits logiciels sont souvent composés de divers composants provenant de différents fournisseurs et stockés dans différents dépôts. Si des pirates parviennent à y accéder, ils peuvent y intégrer des logiciels malveillants et faire signer le sous-composant, qui sera alors considéré comme fiable tout au long de la chaîne d’approvisionnement.
Pour résoudre ces problèmes, les organisations peuvent utiliser une solution de gestion des secrets dotée d’un coffre-fort chiffré afin de protéger les identifiants et les clés. Cette solution doit également proposer aux développeurs des workflows simplifiés pour accéder aux secrets dont ils ont besoin, selon des politiques approuvées par l’équipe de sécurité. Pour renforcer la protection des clés et des identifiants, la solution doit permettre de faire facilement tourner les secrets.
Les secrets dynamiques sont des identifiants générés à la demande qui accordent un accès temporaire à une ressource pendant une durée limitée et avec un ensemble restreint d’autorisations. Ils ne sont pas stockés, ce qui les rend moins vulnérables aux attaques. Même si un secret dynamique est compromis, il devient inutilisable avant qu’un cybercriminel puisse s’en servir. Les secrets dynamiques sont souvent associés au principe des privilèges permanents nuls (ZSP) : les clients disposent d’un accès privilégié à une ressource, mais uniquement avec les droits minimaux nécessaires à une tâche donnée et pour la durée minimale requise. Cette approche contribue à réduire le risque d’accès non autorisé et garantit que les privilèges ne sont accordés qu’en cas de besoin.
Comment faire tourner les secrets
Faire tourner un secret consiste à remplacer un secret existant (comme un mot de passe, une clé API ou une clé SSH) par un nouveau afin de réduire le risque qu’il soit compromis. Cette opération peut être effectuée manuellement ou automatiquement, selon le système utilisé.
Il existe plusieurs stratégies pour faire tourner les secrets :
À intervalles réguliers : vous pouvez définir un calendrier de rotation régulière des secrets. Cela permet de réduire le risque qu’un secret soit compromis, car un attaquant ne dispose que d’une fenêtre de temps limitée pour tenter de l’exploiter.
À la demande : vous pouvez également faire tourner les secrets dès que vous soupçonnez qu’un secret a été compromis, ou si vous souhaitez réduire proactivement le risque de compromission.
Automatisation : vous pouvez utiliser des outils et des scripts pour automatiser la rotation des secrets. Vous vous assurez ainsi que les secrets sont renouvelés de manière cohérente et rapide.
Lorsque vous faites tourner des secrets, il est important de veiller à ce que le nouveau secret soit suffisamment protégé, correctement mis en œuvre et configuré. Il est également nécessaire d’informer les parties concernées, comme les administrateurs système et les utilisateurs, de ce changement.
Repenser la stratégie de gestion des secrets
Même si nous avons pu croire par le passé que nos secrets étaient sécurisés, des compromissions de plateformes ont poussé les organisations à réévaluer leurs stratégies de stockage des secrets et à déterminer la méthode la plus sûre. Il est important de garder à l’esprit qu’une fois utilisés et enregistrés dans le code, les secrets n’en sont plus. Quelle est donc la meilleure façon de les gérer ? Faut-il ne pas les utiliser du tout, ou ne les utiliser qu’une fois avant de les révoquer ?
Cet article sera mis à jour si de nouvelles informations sont disponibles.
Apprécié par les développeurs. Les équipes de sécurité lui font confiance.
Les outils Snyk, conçus pour les développeurs, offrent une sécurité intégrée et automatisée qui répond à vos exigences de gouvernance et de conformité.
