Sécuriser la chaine d'approvisionnement logicielle
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,coaetrc. 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).
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. Le premier que j'ai testé est la suite sigstore.