Le monde dans lequel les composants informatiques pouvaient être réutilisés est menacé depuis un certain temps déjà. Réutiliser des logiciels développés par des tiers était une pratique jugée utile et efficace, mais les attaques exploitant ce type de « chaîne d’approvisionnement » augmentent. Pour preuve, les attaques basées sur rest-client en 2019, plutov-slack-client en 2020, atomicwrites en 2022, xzutils en 2024, chalk, « Shai-Hulud » 1 et 2 en 2025 et, depuis lors, Trivy (logiciel de sécurité !), litellm, telnyx, axios, Bitwarden et, plus récemment, les services en nuage de RedHat. Qui est en mesure de prendre la suite de toutes ces dépendances compromises ? Qui comprend vraiment les dépendances logicielles et comment s’en prémunir ?
En effet, plusieurs incidents de ce type ont transformé plusieurs pages web du CERN en sites d’hameçonnage (attaque «Polyfill.io »). Dans un autre cas, un référentiel de logiciels du CERN, hébergé sur GitHub, a été piraté et a servi à détourner le pipeline d’exécution public de GitHub à des fins malveillantes. Comment pouvons-nous éviter que des outils automatiques utilisant des dépendances provenant de NPM ou de PyPI ne téléchargent des composants logiciels malveillants et les exécutent au sein de l’infrastructure du CERN ? Comment pouvons-nous au moins avoir un aperçu des composants logiciels véritablement utilisés ?
Nous devons avoir une meilleure visibilité sur nos logiciels et leurs dépendances. Ce dessin, tiré de la bande dessinée en ligne XKCD, illustre bien la dépendance de « toute l’infrastructure numérique moderne » à l’égard de ce petit « projet qu’un inconnu, quelque part dans le Nebraska, fait tourner depuis 2003 sans aucun remerciement. » Une meilleure visibilité améliore la sécurité et contribue également à :

• identifier tout autre composant logiciel (sensible ou open source) dont dépend le CERN, ainsi qu’à évaluer les risques auxquels l’Organisation s’expose en l’utilisant ;
• mieux planifier les cycles de vie des logiciels pour éviter que certains ne deviennent obsolètes sans possibilité de remplacement (tel que le logiciel SCADA* utilisé pour le système de commande contrôle de la cryogénie), ce qui permet de :
• mieux se préparer pour éviter que les activités ne s’interrompent au cas où l’on ne pourrait accéder à un composant logiciel particulier pour cause de maintenance ou de manque de licence ;
• identifier les composants logiciels protégés par une licence et des droits d’auteur. En effet, il arrive parfois que des logiciels téléchargeables gratuitement contiennent des éléments protégés par le droit d’auteur (comme les polices « Arial Bold et Regular », ou « Avenir Next Light, Regular et Demi » pour les sites web et les applications mobiles intégrées dans le Framework Oculus Unity) ; et
• contrôler la non-prolifération de certains logiciels sensibles, conformément aux contrôles et aux restrictions à l’exportation, afin que le CERN puisse faire preuve de la diligence appropriée en utilisant correctement ces logiciels.

Sur le plan de la sécurité, une meilleure visibilité permettrait au Bureau de la sécurité informatique d’alerter plus rapidement et plus efficacement les propriétaires de logiciels vulnérables ou malveillants afin qu’ils puissent les corriger ou revenir à une version antérieure. Les méthodes actuelles reposent encore largement sur l’expérience des membres de l’équipe du Bureau qui savent qui contacter pour quel logiciel (en complément de campagnes d’information à plus grande échelle par e-mail et Mattermost pour repérer ceux qui auraient été oubliés). En fait, une meilleure visibilité permettrait également d’analyser soi-même tout logiciel téléchargé à la recherche de vulnérabilités (ou de faire appel à un service tiers pour le faire). En outre, si les développeurs le souhaitent, tout proxy central permettant d’obtenir une telle visibilité pourrait également établir un mécanisme de mise en cache qui placerait tout élément importé en quarantaine pendant quelques heures (« cooldown period »). Cela laisserait le temps de signaler les éventuels problèmes que pourrait engendrer le composant logiciel que l’on souhaite importer. Cette brève attente peut nous éviter bien des ennuis. Qu’en pensez-vous ?

* Logiciel de supervision et d’acquisition de données utilisé pour gérer l’ensemble des expériences et des accélérateurs du CERN.

________

Pour en savoir plus sur les incidents et les problèmes en matière de sécurité informatique au CERN, lisez nos rapports mensuels (en anglais). Si vous souhaitez avoir plus d’informations, poser des questions ou obtenir de l’aide, visitez notre site ou contactez-nous à l’adresse suivante : Computer.Security@cern.ch.