Conformité et Normes

Critères de Sécurité pour le Choix de Logiciels Libres en Environnement Sensible

by  • 

À partir du document publié par l’ANSSI, j’ai rédigé une synthèse structurée pour vous aider à évaluer, en toute connaissance de cause, le choix d’un outil, d’une bibliothèque ou d’un logiciel open source. Ce type de décision peut avoir un impact majeur sur la sécurité de votre organisation.

Un logiciel libre mal choisi peut avoir des conséquences importantes sur la sécurité du système d’information.

C’est pourquoi l’Agence nationale de la sécurité des systèmes d’information (ANSSI) propose, dans sa fiche « Les Essentiels – Sélection d’un logiciel libre » (v1.0, 05/25), une liste de critères pour guider les professionnels dans une sélection éclairée et sécurisée.

L’objectif n’est pas d’obtenir un score parfait sur tous les points, mais de prendre conscience des principaux enjeux de cybersécurité liés à l’adoption d’un composant libre, afin de réduire au maximum les risques.

Maintien en conditions de sécurité et politique de divulgation des failles

Avant tout, il convient d’évaluer le maintien en conditions de sécurité (MCS) du projet considéré, c’est-à-dire sa capacité à rester sûr dans la durée face aux vulnérabilités. Concrètement, il s’agit de vérifier si le projet dispose d’une politique de divulgation claire des failles de sécurité. Par exemple :

  • Point de contact sécurité – L’existence d’un point de contact dédié (adresse email sécurité ou procédure établie) pour signaler des vulnérabilités. Un projet open source sérieux fournit généralement un moyen de contacter les mainteneurs sur les aspects de sécurité et décrit comment les failles sont gérées.
  • Procédure publique de gestion des vulnérabilités – La présence d’une procédure formalisée (éventuellement publiée) pour traiter les rapports de failles. Cela indique que les mainteneurs ont anticipé le traitement responsable des vulnérabilités découvertes.
  • Réactivité aux correctifs de sécurité – Le nombre de correctifs de sécurité publiés et le délai de correction des vulnérabilités critiques. Il est normal qu’un projet rencontre des vulnérabilités tout au long de son cycle de vie. En revanche, il est crucial que l’équipe soit capable de réagir rapidement en proposant des patchs dès qu’une faille critique est signalée. Une lenteur excessive ou un grand nombre de failles non corrigées doit alerter sur le niveau de sécurité du projet.

À noter : L’ANSSI recommande la lecture du guide de l’Open Source Security Foundation (OSSF) sur la mise en place d’un processus de divulgation coordonnée des vulnérabilités dans les projets open source (guide disponible en anglais). Ce guide fournit des bonnes pratiques pour instaurer un processus de divulgation efficace et protéger au mieux les utilisateurs d’un logiciel libre.

Historique du projet et notoriété dans l’écosystème

Il est utile d’analyser l’historique du projet open source et sa notoriété au sein de la communauté. Un projet ayant peu d’activité récente peut, selon les cas, refléter une grande maturité (logiciel stable et éprouvé) ou au contraire un essoufflement faute de ressources. Pour évaluer cet historique et cet impact, on peut prendre en compte :

  • Date de création et rythme des contributions – Un projet ancien avec des mises à jour régulières montre une certaine pérennité. À l’inverse, un dépôt GitHub créé il y a longtemps mais quasiment figé depuis des années pourrait indiquer un manque de vitalité.
  • Nombre et expérience des contributeurs principaux – Un projet maintenu par de nombreux contributeurs actifs, ou par quelques experts reconnus, inspire davantage confiance. La stabilité de l’équipe de développement et son expérience comptent : un noyau de mainteneurs compétents réduit le risque d’erreurs critiques ou d’abandon du projet.
  • Reconnaissance par l’écosystème – La manière dont le projet est perçu par les utilisateurs et les pairs. Par exemple, le niveau d’adoption (est-il largement utilisé ?), les articles de presse spécialisée, ou son éventuelle présence au catalogue SILL (le référentiel des logiciels libres préconisés dans l’administration française). Un logiciel largement plébiscité et inclus dans des recommandations officielles bénéficie d’une crédibilité accrue.

Inventaire et gestion des dépendances logicielles

Un critère souvent négligé est l’inventaire des dépendances du logiciel libre en question. Tout projet s’appuie sur des bibliothèques tierces ou des frameworks, qu’il convient d’identifier et de surveiller activement. Il est recommandé de :

  • Lister les dépendances (SBOM) – Vérifier que le projet fournit une liste à jour de ses dépendances, par exemple sous la forme d’un SBOM (Software Bill of Materials) utilisant un format standard comme SPDX ou CycloneDX. Un SBOM facilite le suivi et la transparence sur les composants tiers inclus.
  • Vérifier la mise à jour et l’absence de failles connues – S’assurer que ces dépendances sont régulièrement mises à jour dans le projet et exemptes de vulnérabilités connues. Une ancienne bibliothèque non mise à jour peut contenir des failles exploitées par des attaquants. Idéalement, le projet intègre les nouvelles versions de dépendances dès que nécessaire, surtout pour appliquer les correctifs de sécurité critiques.
  • Utiliser des outils de gestion avec veille de vulnérabilités – Privilégier des gestionnaires de paquets ou services qui intègrent des informations de sécurité (bases de vulnérabilités, alertes CVE). Ces outils peuvent alerter automatiquement les mainteneurs (et les utilisateurs) en cas de faille découverte dans une dépendance, réduisant le temps de réaction.

Maintien en conditions opérationnelles et support du projet

Au-delà de la sécurité, le maintien en conditions opérationnelles (MCO) du logiciel doit être évalué. Il s’agit de savoir si le projet est activement maintenu et capable de suivre les évolutions techniques. Quelques indicateurs pour jauger le MCO d’un logiciel libre :

  • Mainteneurs identifiés – La déclaration de mainteneur(s) officiel(s) ou d’une équipe clairement responsable est un bon signe. Un projet sans mainteneur désigné risque de voir ses problèmes traîner faute de responsable clairement identifié.
  • Fréquence des commits et des versions – Des commits récents (par exemple au cours des 12 derniers mois) et des versions publiées régulièrement indiquent que le projet vit et continue d’évoluer. Cela inclut également la correction des bugs fonctionnels : une backlog de bugs non résolus depuis longtemps peut signaler un manque de ressources ou d’intérêt des développeurs.
  • Adaptation à l’évolution de l’écosystème – Vérifier que le projet suit les évolutions de son environnement technique. Par exemple, si une bibliothèque sous-jacente ou une plate-forme OS change, les mainteneurs doivent adapter ou porter le logiciel en conséquence. Un bon indicateur est la prise en charge des nouvelles versions de systèmes d’exploitation, de bases de données, etc. Un projet réactif aux changements externes a plus de chances de rester opérationnel sur le long terme.

En complément, il est pertinent d’identifier si le projet a fait l’objet d’analyses de sécurité externes. Par exemple, certains logiciels libres critiques obtiennent un visa de sécurité délivré par l’ANSSI, ou bénéficient de rapports d’évaluation par la communauté open source. De telles évaluations indépendantes apportent un éclairage précieux sur le niveau de sécurité du logiciel. Un visa de sécurité indique notamment qu’une solution a passé avec succès des tests approfondis selon un référentiel reconnu, ce qui est rassurant pour un déploiement en milieu sensible.

Qualité du socle technique et configuration sécurisée

La qualité du socle technique d’un logiciel libre constitue un autre critère essentiel. Elle regroupe la robustesse de l’architecture et les bonnes pratiques de conception logicielle déjà en place. Pour évaluer ce socle, on s’intéressera à :

  • Documentation utilisateur et administrateur – La présence de documentations claires, à jour et bien structurées pour les utilisateurs et les administrateurs. Un projet bien documenté témoigne d’un certain sérieux de la part des développeurs, et facilite surtout une utilisation correcte et sûre du logiciel par autrui.
  • Configuration par défaut sécurisée – Le logiciel propose-t-il une configuration par défaut raisonnablement sécurisée ? Et fournit-il des recommandations de déploiement pour un usage en sécurité optimale ? Par exemple, un service qui, dès l’installation, est correctement verrouillé (comptes par défaut désactivés, communications chiffrées activées, etc.) évite aux administrateurs de commettre des erreurs de configuration. Des guides de déploiement sécurisé ou des hardening guides associés au projet sont un plus notable.
  • Standards ouverts et éprouvés – Le recours à des standards et protocoles ouverts reconnus est gage d’interopérabilité et de sécurité. Un projet qui utilise des formats, protocoles ou algorithmes connus et éprouvés par la communauté (plutôt que des solutions maison obscures) réduit les risques de vulnérabilités cachées. Par exemple, préférer TLS pour la communication chiffrée ou des algorithmes cryptographiques publiquement analysés plutôt que des protocoles propriétaires.

Indicateurs de pérennité et besoin de soutien

Même un bon logiciel peut s’essouffler sans soutien. Il convient donc de vérifier si le projet ou ses mainteneurs ont manifesté un besoin de soutien pour continuer à faire vivre le projet. Ce soutien peut être financier, humain (nouveaux développeurs), matériel, etc. Des appels à contribution, des campagnes de dons ou des messages des mainteneurs signalant un manque de ressources sont autant de signaux sur la santé du projet. S’ils cherchent activement du soutien, c’est peut-être le signe que le projet peine à se maintenir avec ses ressources actuelles. Pour un utilisateur (entreprise ou organisation), cela ne signifie pas qu’il faut écarter le logiciel, mais qu’il peut être judicieux d’envisager de contribuer en retour (financement, participation communautaire) afin d’assurer sa continuité. Un projet dont la pérennité financière et humaine est garantie aura moins de risques d’abandon ou de retard de maintenance.

Pratiques de développement sécurisées et qualité du code

Un logiciel libre de qualité se reconnaît aussi à ses pratiques de développement. Il est important d’identifier si les développeurs suivent des règles de développement sécurisé et des processus qui renforcent la fiabilité du code. Quelques éléments à examiner :

  • Conformité aux guides de codage sécurisé – Le projet applique-t-il des recommandations reconnues en matière de développement sécurisé ? Par exemple, l’ANSSI publie des règles de programmation sécurisée pour le C et pour Rust, qui constituent des référentiels de bonnes pratiques. De même, l’OWASP Developer Guide ou le guide de la NSA sur la gestion sécurisée de la mémoire (tous deux en anglais) sont des ressources précieuses. Un projet conscient de ces guides et s’en inspirant pour son code montre une volonté d’éléver son niveau de sécurité.
  • Revue de code et analyse automatisée – La présence d’un processus de peer review (relecture de code par des pairs) pour valider les contributions est un gage de qualité. De plus, l’utilisation d’outils d’analyse de code automatique (statique ou dynamique) aide à détecter des bugs ou failles potentielles à chaque modification. Un projet qui intègre ces pratiques dans son flux de développement prévient mieux les régressions et les vulnérabilités.
  • Tests unitaires et intégration continue – Un bon taux de couverture de tests unitaires, couplé à une intégration continue (CI) qui exécute ces tests à chaque commit, permet d’attraper rapidement les bugs introduits. La CI peut également inclure des tests de sécurité ou l’exécution d’analyses de vulnérabilités sur le code. Ces mécanismes automatisés renforcent la fiabilité du logiciel à chaque évolution.
  • Reproductibilité des builds – Idéalement, le projet permet de reproduire à l’identique les binaires distribués à partir du code source (concept de reproducible builds). Cela signifie qu’indépendamment de qui compile le code, on obtient le même résultat binaire, garantissant qu’aucune altération malveillante n’a été ajoutée lors du processus de compilation ou de distribution. C’est un aspect technique pointu, mais de plus en plus considéré dans la chaîne de confiance des logiciels libres.
  • Langages utilisés et sécurité intrinsèque – Enfin, la nature des langages de programmation employés joue un rôle. Par exemple, un logiciel écrit en Rust bénéficiera de la sécurité mémoire offerte par le langage (prévenant un grand nombre de vulnérabilités de type débordement, use-after-free, etc.), là où un équivalent en C devra redoubler de prudence et d’audits pour éviter ces pièges. De même, l’utilisation de langages à typage fort, de frameworks sécurisés, contribue à un socle logiciel plus robuste.

Audits de sécurité réguliers et surveillance du code

Même avec de bonnes pratiques de développement, un projet open source n’est jamais à l’abri d’une contribution malveillante ou d’une dérive dans son code. Il est donc recommandé de faire auditer régulièrement le code et les contributions du projet, en combinant des analyses manuelles et des outils de scan de sécurité. Des audits périodiques, éventuellement réalisés par des tiers ou par la communauté, permettent de détecter toute insertion de code illégitime ou vulnérabilité passée inaperçue. Ce travail proactif de surveillance renforce la confiance dans le logiciel, en particulier pour des déploiements dans des environnements sensibles (administrations, infrastructures critiques, etc.).

Le cas XZ-utils Un exemple frappant de contribution malveillante est l’attaque subie par XZ Utils (une bibliothèque de compression largement utilisée) en 2024. Un contributeur malveillant a réussi à y insérer discrètement du code malicieux – une porte dérobée – au sein d’un test unitaire. Cette backdoor, une fois le logiciel déployé, aurait permis à un attaquant de prendre le contrôle à distance des systèmes sur lesquels la bibliothèque était installée. L’attaque n’a été découverte qu’après coup, lorsqu’un développeur a remarqué un comportement anormal sur un service utilisant XZ Utils. Cet incident, d’une ampleur sans précédent dans l’écosystème Linux selon de nombreux experts, illustre concrètement le risque de chaîne d’approvisionnement logiciel : même un composant open source éprouvé peut être compromis et mettre en danger l’ensemble des applications qui en dépendent. Seule une vigilance accrue, via des audits et une communauté active, permet de déjouer ce type de menace.

Enfin, si le logiciel libre ciblé est critique pour votre organisation, il peut être judicieux de souscrire un contrat de support auprès de l’éditeur (s’il en existe un) ou d’une entité proposant du support pour ce projet. De plus en plus de logiciels libres populaires sont adossés à des offres de support commercial ou communautaire.

Un tel contrat (qu’il couvre le support fonctionnel ou la sécurité) présente un double avantage : il apporte au projet une stabilité financière et une pérennité accrue en finançant ses évolutions, et il offre à l’utilisateur une garantie de réactivité en cas de problème.

Cette assurance de support est rassurante pour déployer l’outil dans la durée, tout en contribuant à la santé de l’écosystème open source.

J’espère que cet article vous permettra de prendre la bonne décision

Enjoy !

Sources et Références