Presque tous les logiciels modernes reposent sur des composants open source : systèmes d'exploitation, navigateurs, serveurs web, bibliothèques, frameworks, outils de sécurité. Cette réalité est une force, mais elle crée une dépendance que les attaquants savent exploiter. Les risques de l'open source ne tiennent pas au fait que le code est public, mais à la façon dont on l'intègre, le maintient et le surveille. Cet article fait le point, sans caricature : ce que l'open source apporte en sécurité, les principaux risques illustrés par des incidents réels, et les mesures concrètes pour les maîtriser.
Open source et sécurité : deux idées reçues
- « Le code est public, donc il est relu, donc il est sûr » : faux. Que le code soit lisible ne garantit pas qu'il soit réellement relu. Beaucoup de composants critiques sont maintenus par très peu de personnes, souvent bénévoles.
- « Le code est public, donc il est moins sûr » : faux également. La transparence permet des audits indépendants, une détection collective des failles et des correctifs rapides. Un code fermé n'est pas plus sûr par nature, il est simplement moins observable.
À retenir : l'open source n'est ni plus ni moins sûr que le logiciel propriétaire par principe. Ce qui compte, c'est la qualité de la maintenance, de la gouvernance et de la gestion des dépendances.
Les principaux risques de l'open source
1. Les vulnérabilités dans des composants très répandus
Une faille dans une bibliothèque omniprésente touche des milliers de produits en même temps. L'exemple le plus marquant est Log4Shell (CVE-2021-44228), une vulnérabilité d'exécution de code à distance dans la bibliothèque de journalisation Apache Log4j, divulguée en décembre 2021 et notée 10 sur 10 en gravité. Elle a touché des applications et services très divers, souvent sans que les organisations sachent qu'elles utilisaient cette bibliothèque (voir les consignes de la CISA). La difficulté n'était pas seulement de corriger, mais de savoir où le composant se trouvait.
2. La compromission de la chaîne d'approvisionnement
Un attaquant peut viser non pas votre système, mais un composant que vous utilisez. L'affaire xz Utils (CVE-2024-3094), découverte en mars 2024, en est l'illustration : une porte dérobée a été introduite dans une bibliothèque de compression présente dans de nombreuses distributions Linux, par un contributeur qui avait gagné la confiance du projet et obtenu des droits de mainteneur sur une longue période. La faille a été détectée par hasard, à cause d'un ralentissement des connexions SSH (voir l'analyse de l'OpenSSF). Le risque ici est humain et organisationnel : un projet critique reposant sur un mainteneur épuisé et isolé est une cible d'ingénierie sociale.
3. Les paquets malveillants
Les registres publics de paquets (npm, PyPI et autres) permettent à n'importe qui de publier. Les attaquants en profitent avec plusieurs techniques :
- Typosquatting : publier un paquet au nom quasi identique à un paquet populaire ;
- Confusion de dépendances : publier publiquement un paquet portant le nom d'un paquet interne d'une entreprise, pour qu'il soit installé à la place ;
- Compromission d'un compte de mainteneur pour publier une version piégée d'un paquet légitime ;
- Code malveillant dans des scripts d'installation, exécutés dès l'installation.
4. Les dépendances transitives
Vous ne choisissez qu'une petite partie de ce que vous exécutez : chaque bibliothèque en appelle d'autres, qui en appellent d'autres. Une application peut compter des centaines de dépendances indirectes, dont personne dans l'équipe n'a examiné le code.
5. Les projets abandonnés ou mal maintenus
Un composant sans mainteneur actif ne reçoit plus de correctifs. Une faille découverte reste ouverte. Or beaucoup d'organisations continuent d'utiliser ces composants faute de suivi.
6. Les configurations par défaut et l'absence de support
Un logiciel open source peut être livré avec des réglages permissifs, et il n'y a pas toujours de contrat de support avec un délai d'intervention garanti. C'est à l'utilisateur d'assurer la mise à jour, le durcissement (voir nos CIS Benchmarks) et la surveillance.
| Risque | Exemple | Cause principale |
|---|---|---|
| Faille dans un composant courant | Log4Shell | Diffusion massive, inventaire absent |
| Compromission de la chaîne | xz Utils | Confiance accordée à un contributeur, mainteneur isolé |
| Paquet piégé | Typosquatting, confusion de dépendances | Registres ouverts, vérification insuffisante |
| Dépendances cachées | Bibliothèques indirectes | Manque de visibilité |
| Projet abandonné | Composant sans correctif | Absence de suivi |
Ce que l'open source apporte en sécurité
Il serait trompeur de ne citer que les risques. L'open source offre des avantages réels :
- Transparence : le code peut être audité par des tiers, ce qui permet de vérifier ce qui s'exécute.
- Réactivité communautaire : de nombreux projets corrigent vite, et plusieurs personnes peuvent contribuer aux correctifs.
- Absence de dépendance à un fournisseur unique : on peut forker, migrer ou maintenir soi-même en dernier recours.
- Standards ouverts : nombreux protocoles et outils de sécurité, dont les outils d'analyse, sont open source.
Comment maîtriser les risques
Connaître ce que l'on utilise
- Tenir un inventaire des composants, avec leurs versions, sous forme de SBOM (Software Bill of Materials, nomenclature logicielle). Quand la prochaine faille de type Log4Shell arrivera, la réponse à la question « sommes-nous concernés ? » doit prendre quelques minutes, pas plusieurs semaines.
- Analyser automatiquement les dépendances avec des outils de composition logicielle (SCA), par exemple Dependency-Check, présenté dans notre article sur l'OWASP.
- Suivre les vulnérabilités publiées, en s'aidant de la base de vulnérabilités CVE et de la lecture du score CVSS pour prioriser.
Choisir et intégrer avec discernement
- Évaluer un projet avant de l'adopter : activité de maintenance, nombre de mainteneurs, historique de correctifs, pratiques de sécurité. L'outil OpenSSF Scorecard attribue une note automatique à ces pratiques pour de nombreux projets.
- Limiter le nombre de dépendances : chaque bibliothèque supplémentaire élargit la surface d'attaque.
- Épingler les versions avec des fichiers de verrouillage, et vérifier les changements avant chaque mise à jour.
- Utiliser un registre interne ou un proxy qui filtre et met en cache les paquets autorisés, pour éviter les installations directes depuis Internet.
- Se méfier des noms proches et vérifier l'éditeur, la popularité et l'historique d'un paquet avant de l'installer.
Maintenir et réagir
- Mettre à jour régulièrement plutôt qu'en urgence : un retard cumulé rend chaque mise à jour plus risquée.
- Prévoir un plan de réponse aux failles de composants : qui identifie, qui teste, qui déploie, dans quel délai.
- Contribuer ou financer les projets critiques que l'on utilise : soutenir les mainteneurs réduit le risque d'épuisement et d'abandon.
Le volet réglementaire : le Cyber Resilience Act
Le Cyber Resilience Act (règlement (UE) 2024/2847) impose aux fabricants de produits comportant des éléments numériques des exigences de cybersécurité, dont la gestion des vulnérabilités et la traçabilité des composants, open source compris (voir la page de la Commission européenne). Selon le calendrier publié, les obligations de notification des vulnérabilités s'appliquent à partir du 11 septembre 2026 et l'essentiel des autres obligations, dont la nomenclature logicielle dans la documentation technique, à partir du 11 décembre 2027. Des dispositions particulières existent pour les projets open source non commerciaux. Si vous éditez ou intégrez des logiciels, vérifiez précisément votre situation.
En résumé
L'open source est le socle du numérique, et ses risques sont surtout ceux de la dépendance non maîtrisée : composants inconnus, projets fragiles, paquets piégés, mises à jour tardives. Log4Shell a montré le coût de ne pas savoir ce qu'on utilise ; xz Utils a montré que la confiance envers les mainteneurs peut être ciblée. La réponse tient en quelques pratiques : inventorier, analyser, choisir avec soin, mettre à jour, préparer la réaction et soutenir les projets dont on dépend.