This post details how an open source supply chain malware spread through build artifacts. 26 open source projects were backdoored by this malware and were actively serving backdoored code.
En développant des applications informatiques, nous sommes vite confrontés à la question : Puis-je utiliser ce code trouvé sur le réseau, dans mon propre code ?
C’est souvent une facilité bien tentante que nous nous refusons.
Ce n’est pas une question réservée seulement aux petits développeurs. Cela touche tous les grands projets. Pratiquement tous les projets informatiques font appel à des bibliothèques ouvertes et libres. Mais quel est donc le degré de sécurité de ces projets incorporés ?
– ScientificWare n’utilise que des bibliothèques reconnues et utilisées par d’autres grands projets auxquels il est associé.
– Pour Android, nous nous limitons aux API d’origine et à nos propres productions internes.
– De même pour tout autre projet Java y compris le langage lui-même à travers l’ OpenJDK et ses dérivés. Nous menons une veille et contribuons pour dès que nous idenfions un problème à notre niveau.
Cette contrainte que nous nous imposons, limite un peu certaines fonctionnalités mais nous avons une grande responsabilité par rapport aux produits que nous diffusons. Cet incident invite à être encore plus prudent et conforte notre choix de contrôler et d’être partie prenante de tous les outils que nous utilisons.
Autrement dit, avant d’utiliser un code externe, il convient de le lire et s’investir dans sa maintenance pour garder un œil sur son évolution.
Enfin, une réflexion sur l’accès distant à ces bibliothèques sur certains dépôts doit être renforcée pour mieux maitriser les versions incorporées. Nous sommes encore réticents à son utilisation au regard des risques que nous percevons.