L’open source est le plus grand risque de sécurité au monde – Et nous l’ignorons tous

2 min de lecture

96 pour cent de tous les logiciels commerciaux contiennent des composants open source. La plupart sont entretenus par des développeurs individuels et non rémunérés. Log4j n’était que le début – la prochaine catastrophe sommeille dans une bibliothèque entretenue par un mainteneur du Nebraska pendant son temps libre. Pourquoi le modèle open source est en crise de sécurité.

L’essentiel

96 pour cent des bases de code commerciales contiennent des bibliothèques open source – en moyenne plus de 500 dépendances par projet
La vulnérabilité Log4Shell (2021) affectait plus de 35 000 paquets Java et a causé des dommages estimés à 10 milliards de dollars
Plus de 25 pour cent de tous les projets open source sont entretenus par un seul mainteneur – sans rémunération, sans audit de sécurité
Les attaques de la chaîne d’approvisionnement via des paquets open source compromis ont augmenté de 740 pour cent en 2024 par rapport à l’année précédente

L’alerte xz-Utils

En mars 2024, un développeur de Microsoft a découvert par hasard une porte dérobée dans xz Utils – une bibliothèque de compression présente dans pratiquement chaque distribution Linux. La porte dérobée était sophistiquée : un attaquant s’était infiltré pendant deux ans dans le projet en tant que contributeur bienveillant, avait gagné la confiance du mainteneur surchargé de travail et avait finalement intégré une porte dérobée SSH.

L’attaque n’a été découverte que par hasard – parce qu’un développeur a remarqué que les connexions SSH étaient 500 millisecondes plus lentes que prévu. S’il n’avait pas été curieux, la porte dérobée aurait compromis des millions de serveurs dans le monde. Ce n’est pas un modèle de sécurité. C’est de la chance.

La vérité désagréable sur « Given Enough Eyeballs »

Le mantra de l’open source est : « Given enough eyeballs, all bugs are shallow. » La loi de Linus. L’idée que le code ouvert est automatiquement sûr parce que tout le monde peut le vérifier. La réalité : personne ne le vérifie.

OpenSSL – la bibliothèque de cryptographie qui sécurise la moitié d’Internet – a été entretenue pendant des années par deux personnes, avec un budget annuel de moins de 10 000 dollars. Heartbleed, l’une des pires vulnérabilités de l’histoire d’Internet, sommeillait dans le code depuis deux ans. Pas parce que le code était secret, mais parce que personne ne regardait.

Log4j – la bibliothèque de journalisation Java qui a mis Internet en état d’urgence en 2021 – était entretenue par trois bénévoles. Ils n’avaient pas intentionnellement intégré la vulnérabilité. Ils n’avaient tout simplement pas les ressources pour vérifier chaque chemin de code pour la sécurité.

Chaîne d’approvisionnement : Le vecteur d’attaque parfait

Les attaquants ont compris que le moyen le plus efficace d’entrer dans des milliers d’entreprises ne passe pas par leurs pare-feu, mais par leurs dépendances. Un paquet npm compromis avec 10 millions de téléchargements hebdomadaires infecte automatiquement des milliers de pipelines de construction.

Les attaques deviennent plus sophistiquées : typosquatting (paquets avec des noms similaires à des bibliothèques populaires), confusion des dépendances (noms de paquets internes remplacés par des noms externes), prise de contrôle des mainteneurs (comme dans xz Utils). Et la défense ? Fragmentée, sous-financée et réactive.

Ce qui doit être fait

Financement de l’infrastructure critique : Les bibliothèques open source utilisées dans plus de 10 000 projets sont de facto une infrastructure critique. Elles doivent être traitées et financées comme telles – par des programmes gouvernementaux, des consortiums industriels ou des cotisations obligatoires des entreprises qui en dépendent.

Software Bill of Materials (SBOM) : Chaque entreprise doit savoir quelles composantes open source sont intégrées dans ses produits. Les SBOM doivent devenir obligatoires – l’UE travaille dessus, mais la mise en œuvre prend trop de temps.

Audits de sécurité automatisés : Chaque mise à jour d’une bibliothèque critique doit passer par une vérification de sécurité automatisée avant d’être intégrée dans les systèmes de production. Des outils comme Dependabot, Snyk ou Socket.dev aident – mais ils doivent devenir la norme, pas une option.

Conclusion : L’open source a besoin d’un nouveau modèle de sécurité

L’open source n’est pas le problème – c’est la solution à d’innombrables défis technologiques. Mais le modèle de sécurité repose sur une illusion : que la bénévolat et la transparence suffisent. Ce n’est pas le cas. Le monde construit son infrastructure numérique sur du travail non rémunéré – et s’étonne lorsqu’elle s’effondre.

Faits clés

Attaque xz-Utils : La porte dérobée n’a été découverte que par hasard – l’attaquant avait investi deux ans et aurait réussi sans un développeur attentif.

Manque de financement : La Linux Foundation estime que l’infrastructure open source mondiale a besoin d’au moins 2 milliards de dollars d’investissement annuel – en réalité, moins de 200 millions de dollars sont investis.

Questions fréquentes

La logiciel propriétaire est-il plus sûr que l’open source ?

Pas de manière générale. La logiciel propriétaire a les mêmes vulnérabilités, elles sont simplement traitées de manière moins transparente. La différence : la logiciel propriétaire a des développeurs et des équipes de sécurité rémunérés. L’open source a besoin de la même chose – sans perdre la transparence.

Que doivent faire les entreprises immédiatement ?

Premièrement : créer un SBOM pour tous les produits. Deuxièmement : intégrer l’analyse automatisée des dépendances dans la pipeline CI/CD. Troisièmement : soutenir financièrement les projets open source critiques dont elles dépendent.

Le Cyber Resilience Act (CRA) résoudra-t-il le problème ?

Le CRA de l’UE exige la sécurité par conception pour les produits logiciels – y compris les composants open source. C’est une étape importante, mais la mise en œuvre doit garantir que les mainteneurs non rémunérés ne sont pas criminalisés, mais soutenus.

À propos de l'auteur: Tobias Massow

Plus d'articles de Tobias Massow

Aussi disponible en

Español English Deutsch