La supply chain logicielle, nouvel objet d’attention sécuritaire

On s’en souvient. En 2021, une faille zero day était identifiée dans Log4Shell, une bibliothèque open source très populaire employée dans des milliers d’applications. Pour les organisations, une course était soudain lancée: il fallait patcher au plus vite et, avant cela, déterminer les applications de l’environnement intégrant le composant vulnérable – ce que beaucoup d’entreprises eurent toutes les peines à faire.

L’événement a déclenché une prise de conscience et la sécurisation de la supply chain logicielle fait depuis l’objet d’un regain d’attention. De nombreux outils et pratiques ont ainsi émergé ces deux dernières années, tant pour dresser l’inventaire des dépendances des applications, que pour surveiller et corriger leurs vulnérabilités dès qu’elles apparaissent. La question a aussi pour effet de faire remonter la prise en compte de la sécurité en amont de la software factory, les DevOps se muant en DevSecOps, ainsi que l’évoquent Oscar Prado de Romande Energie et Yann Albou de Sokube.

Connaître les dépendances et patcher rapidement les vulnérabilités, c’est bien. Eviter leur présence, c’est mieux. Dans cet esprit, des réglementations veulent faire porter la responsabilité aux fournisseurs logiciels. Si la démarche est logique, elle peine cependant à s’appliquer aux logiciels et composants libres, mis au point et maintenus par des développeurs peu ou pas rémunérés. De nouvelles formules devront être inventées pour gagner en sécurité tout en préservant ce modèle à succès.

Par analogie avec l’image de couverture de ce numéro, on pourrait dire que la sécurité du trapéziste n’échoit pas seulement à celui qui le réceptionne, mais à l’ensemble des composants et intervenants, et dépend même plus largement, d’une culture de responsabilité au sein des organisations.

Source