DevOps - Sécuriser la chaine d'approvisionnement logicielle

S’il est un sujet qui me tient à cœur, c’est bien la sécurité. Combien de fois, je vois sacrifier la sécurité au nom de la vélocité ou de la fainéantise. Cette fois-ci, on me donne l’opportunité de travailler sur la sécurisation de la chaine d’approvisionnement logicielle. Dans ce premier billet, je parlerai des risques auxquels on s’expose puis quelques pistes pour s’en prémunir.

Introduction

Contrairement aux idées reçues, les menaces pesant sur la chaîne d’approvisionnement logicielle ne cessent de croître. Des cas concrets sont régulièrement publiés dans les journaux et les chiffres sont inquiétants. Une étude de 2022 remontait une hausse de 600% de ce type d’attaque.

Des exemples d’attaques de la supply chain

La plus célèbre est l’attaque qui a ciblé la société Solarwinds dont les conséquences ont été importantes. Plus de 200 organisations à travers le monde en ont été victimes. Cette attaque ciblait la chaine de livraison du logiciel Orion de SolarWinds largement utilisé à travers le monde, surtout par des organisations gouvernementales. Les attaquants ont introduit dans le logiciel un cheval de troie nommé “SunBurst”. Une fois déployée cette version vérolée, le cheval de troie exploitait diverses failles pour s’introduire partout dans le SI infecté pour y voler des données. Sur les 33 000 sociétés ayant déployé cette version, une trentaine ont déclaré des compromissions et des vols de données. Parmi elles de nombreux ministères américains, Microsoft, Nvidia, VMware, Qualys, SolarWinds, …

Autres exemples de compromissions :

• CodeCov : Des hackers sont parvenus à s’introduire sur son système et à modifier, à plusieurs reprises, un de ses scripts, nommé Bash Uploader permettant d’installer les outils développé par la société. Le malware inséré dans le code leur permettait de récupérer toutes sortes d’informations confidentielles comme des identifiants, des jetons d’authentification ou des clés de chiffrement.
• PHP : Un hacker a réussi à s’introduire sur le serveur de gestion de code Git de la fonction. Il a réussi à soummetre deux commits malveillants dans la version 8.1 du langage en cours de développement. Ils permettaient l’installation une backdoor qui aurait pu être exploité sur les applications utilisant cette version de PHP.
• NPM : Les compromissions des paquets ua-parser-js, coa et rc. Ces paquets compromis permettaient d’exécuter du code malveillant lors de leur utilisation dans les chaines CI/CD.

Le biden Act

C’est suite à l’affaire SolarWinds que le président des États-Unis a appelé à renforcer la sécurité des chaines d’approvisionnement logiciel. Pour cela, la commission à proposer un certain nombre de bonnes pratiques à mettre en oeuvre, mais aussi des obligations. Parmi elles, on retrouve la création et la publication sur un site publique de la SBOM (Software Bill Of Material).

Cette SBOM devant être composé des informations sur :

• La version du langage de programmation utilisé
• Les produits open source utilisés, ainsi que leurs dépendances
• Les dépendances au niveau du système d’exploitation utilisé
• Le produit propriétaire (c’est-à-dire le code écrit pour le produit)
• Les métadonnées telles que le numéro de version, la licence open source, etc.
• Un rapport d’analyse CVE, montrant les vulnérabilités de chacun de ces composants

Et en Europe ?

Le décret américain a son pendant Européen et se nomme CYBERSECURITY ACT. Si on lit dans les orientations générales, on retrouve bien les mêmes objectifs :

• Des règles visant à rééquilibrer la responsabilité de la conformité vis-à-vis des fabricants, qui doivent garantir la conformité aux exigences de sécurité des produits contenant des éléments numériques mis à disposition sur le marché de l’UE, y compris des obligations telles que l’évaluation des risques liés à la cybersécurité, la déclaration de conformité et la coopération avec les autorités compétentes.
• Les exigences essentielles applicables aux processus de traitement des vulnérabilités pour les fabricants afin de garantir la cybersécurité des produits numériques, et les obligations incombant aux opérateurs économiques, tels que les importateurs ou les distributeurs, en ce qui concerne ces processus.
• Des mesures visant à améliorer la transparence en matière de sécurité des produits matériels et logiciels pour les consommateurs et les entreprises utilisatrices, et un cadre de surveillance du marché pour faire respecter ces règles.

Pour le moment rien n’est obligatoire, car elle s’effectuera sur une base volontaire, mais il est possible que les législateurs rendent obligatoire certains sujets. Cela devrait vous rappeler ce qui a été fait pour la RGPD.

Quelles solutions pour y répondre ?

Suite à ces attaques sont donc apparus quelques frameworks permettant d’analyser les types d’attaques possibles et proposent des solutions pour renforcer la sécurité. Pour le moment, je vais me concentrer sur celui initié par Google et répondant au nom de SLSA (Supply chain Levels for Software Artifacts).

Supply chain Levels for Software Artifacts

Ce framework met l’accent sur la nécessité de garantir l’intégrité des artefacts logiciels tout au long de la chaîne d’approvisionnement logicielle.

Son implématation peut se faire par niveau qui sont au nombre de 4 :

• SLSA 1 : exige que le processus de génération soit entièrement scripté/automatisé et génère une provenance. La provenance est une métadonnée sur la façon dont un artefact a été construit, y compris le processus de génération, la source de niveau supérieur et les dépendances. Connaître la provenance permet aux consommateurs de logiciels de prendre des décisions de sécurité basées sur les risques. Bien que la provenance à SLSA 1 ne protège pas contre la falsification, elle offre un niveau de base d’identification de la source du code et peut aider à la gestion des vulnérabilités.
• SLSA 2 : Nécessite l’utilisation du contrôle de version et d’un service de génération hébergé qui génère une provenance authentifiée. Ces exigences supplémentaires donnent au consommateur une plus grande confiance dans l’origine du logiciel. À ce niveau, la provenance empêche la falsification dans la mesure où le service de build est approuvé. SLSA 2 fournit également un chemin de mise à niveau facile vers SLSA 3.
• SLSA 3 : exige en outre que les plates-formes source et de construction répondent à des normes spécifiques pour garantir l’auditabilité de la source et l’intégrité de la provenance, respectivement. Nous envisageons un processus d’accréditation dans le cadre duquel les auditeurs certifient que les plateformes répondent aux exigences, sur lesquelles les consommateurs peuvent ensuite compter. SLSA 3 offre des protections beaucoup plus solides contre la falsification que les niveaux précédents en empêchant des classes spécifiques de menaces, telles que la contamination croisée.
• SLSA 4: est actuellement le niveau le plus élevé, nécessitant un examen de toutes les modifications par deux personnes et un processus de construction hermétique et reproductible. L’examen par deux personnes est une pratique exemplaire de l’industrie pour détecter les erreurs et dissuader les mauvais comportements. Les builds hermétiques garantissent que la liste des dépendances de la provenance est complète. Les builds reproductibles, bien qu’ils ne soient pas strictement obligatoires, offrent de nombreux avantages en termes d’auditabilité et de fiabilité. Dans l’ensemble, SLSA 4 donne au consommateur un degré élevé de confiance que le logiciel n’a pas été falsifié.

Quelles attaques corrige le framework SLSA ?

SLSA, découpe la chaîne d’approvisionnement logicielle en cinq composantes :

• le code source
• les pipelines de build
• les dépendances directes et indirectes
• les artefacts
• le déploiement

Chacune de ces parties peut subir des attaques dont l’image suivante les liste, permet de les comprendre et apporte une solution possible pour en protéger.

• [A] : Soumettre du code incorrect au référentiel source
  • Exemple : Commits hypocrites Linux: Un chercheur a tenté d’introduire intentionnellement des vulnérabilités dans le noyau Linux via des correctifs sur la liste de diffusion.
  • Solution proposée : L’examen par deux personnes a permis de détecter la plupart des vulnérabilités, mais pas toutes.
• [B] : Plate-forme de contrôle de code source compromise
  • Exemple : PHP: L’attaquant a compromis le serveur git auto-hébergé de PHP et injecté deux commits malveillants.
  • Solution proposée : Une plate-forme de code source mieux protégée aurait été une cible beaucoup plus difficile pour les attaquants.
• [C] : Construire avec un processus officiel mais à partir de code ne correspondant pas au contrôle de code source
  • Exemple : Webmin : l’attaquant a modifié l’infrastructure de génération pour utiliser des fichiers sources ne correspondant pas au contrôle de code source.
  • Solution proposée : Un serveur de build conforme à la SLSA aurait permis aux consommateurs de détecter une telle falsification.
• [D] : Plate-forme de build compromise
  • Exemple : L’exemple de SolarWinds
  • Solution proposée : Des niveaux SLSA plus élevés nécessitent des contrôles de sécurité plus stricts pour la plate-forme de build
• [E] : Utiliser une mauvaise dépendance direct ou indirect.
  • Exemple : event-stream : l’attaquant a ajouté une dépendance inoffensive, puis a mis à jour la dépendance pour ajouter un comportement malveillant. La mise à jour ne correspondait pas au code soumis à GitHub.
  • Solution proposée : L’application récursive de SLSA à toutes les dépendances aurait empêché ce vecteur particulier, car la provenance aurait indiqué qu’il n’avait pas été construit à partir d’un constructeur approprié ou que la source ne provenait pas de GitHub.
• [F] : Télécharger un artefact qui n’a pas été créé par le système CI/CD
  • Exemple : CodeCov : l’attaquant a utilisé des informations d’identification divulguées pour télécharger un artefact dans la registry d’artefacts malveillant mis à dispostion des utilisateurs.
  • Solution proposée : La provenance de l’artefact dans la registry d’artefacts aurait montré que l’artefact n’a pas été construit à partir du référentiel source attendu.
• [G] : Référentiel de paquets de compromis
  • Exemple : Attaques sur les miroirs de paquets : Researcher a créé des miroirs pour plusieurs référentiels de paquets populaires, qui auraient pu être utilisés pour servir des paquets malveillants.
  • Solution proposée : Comme ci-dessus (F), la provenance des artefacts malveillants aurait montré qu’ils n’ont pas été construits comme prévu ou à partir du référentiel source attendu.
• [H] : Inciter le consommateur à utiliser une mauvaise source
  • Exemple : Browserify typosquatting : l’attaquant a téléchargé un paquet malveillant portant un nom similaire à celui de l’original.
  • Solution proposée : SLSA ne traite pas directement cette menace, mais la liaison de la provenance au contrôle de code source peut permettre et améliorer d’autres solutions.

Conclusion

Je n’ai fait qu’effleurer le sujet, mais il faut ne pas oublier que les attaquants, des grosses organisations, adaptent sans cesse leurs techniques. Elles se sont ajouté de nouvelles de cibles et visent désormais aussi les chaines de construction de logiciels. Ne pas le prendre en considération, risque d’être préjudiciable et engagera la responsabilité des sociétés où cas où elles seraient vectrices de propagation d’agents infectieux.

Et la vélocité des développeurs dans tout cela ? Elle va en prendre un coup si on ne s’y prépare pas ! Heureusement, les outils commencent à arriver sur le marché et vont permettre d’automatiser le tout.

Ce sujet me passionne et je risque donc de publier pas mal de choses sur le sujet. Par exemple sur les autres frameworks, sur les outils et techniques…,

Liens

• Software Supply Chain Best Practices
• The Secure Software Factory