Le paradoxe du modèle Open Source : comprendre les risques, l'impartialité et l'acceptation

Le modèle Open Source a toujours été paradoxal. En effet, les logiciels Open Source sont développés par des passionnés et distribués gratuitement, alors qu'ils sont monétisés et financés par de grandes entreprises. Un outsider qui a longtemps été considéré comme « un fléau », mais qui reste encore aujourd'hui le plus grand moteur d'innovation et de progrès technologique. Il y aura toujours des paradoxes dans l'Open Source, surtout en ce qui concerne la compréhension des vulnérabilités de sécurité.

Il y a 25 ans, le programme CVE (Common Vulnerabilities and Exposures) a été mis en place pour standardiser le nommage et le suivi des failles logicielles. À l'époque où l'identification des vulnérabilités était souvent sujette à interprétation et où les logiciels courants, tels que Sendmail, présentaient de nombreux problèmes, les CVE ont amélioré la clarté et l'organisation. Même si des projets tels que Security Focus et Bugtraq existaient déjà, le programme CVE de MITRE a fourni un système international devenu indispensable. La première année, en 1999, 894 vulnérabilités ont été répertoriées, soulignant clairement l'importance d'une identification cohérente, même avec un volume relativement faible. Ce contexte historique joue un rôle essentiel pour comprendre les défis auxquels nous sommes confrontés avec les CVE aujourd'hui.

Le paysage des vulnérabilités logicielles a considérablement évolué depuis cette époque. Au cours des six premières années du programme, le nombre de CVE attribuées a bondi de plus de 450 %, du fait de son adoption à grande échelle. Cette croissance s'est poursuivie de manière exponentielle, pour atteindre près de 15000 CVE en 2017, soit une augmentation de 125 % en seulement deux ans. En 2023, ce volume avait encore augmenté de 50 %, pour atteindre plus de 29 000 entrées. Cette croissance fulgurante s'explique par la complexité croissante des logiciels, l'augmentation de leur disponibilité et l'adoption du système CVE par de plus en plus de fournisseurs.

Les vulnérabilités sont toujours plus nombreuses. En 2024, le nombre de CVE enregistrées a augmenté de 39 % pour dépasser les 40 000, notamment parce que le noyau Linux a acquis le statut de CNA (CVE Numbering Agency). Cette courbe de croissance pourrait encore grimper considérablement si d'autres secteurs du logiciel, tels que le développement d'applications et de jeux mobiles, commençaient à établir un suivi officiel des CVE. Face à cette situation, une réévaluation complète de notre stratégie de gestion des vulnérabilités s'impose.

L'application de correctifs n'est plus viable

Nous affirmons depuis longtemps que l'application généralisée de correctifs a fait son temps. Ce n'est plus une solution viable capable de répondre aux problèmes des environnements complexes actuels. Elle ne s'appuie en effet sur aucune véritable évaluation des risques. Certaines vulnérabilités ne nécessitent pas de correction immédiate ni d'utilisation intensive de ressources. L'exploitabilité et les conséquences potentielles représentent en revanche des facteurs clés. En traitant toutes les failles identifiées de la même façon, qu'elles soient graves ou bénignes, le niveau réel de la menace ainsi que les risques associés à sa neutralisation ne sont jamais pris en compte.

L'indicateur de mesure le plus pertinent pour hiérarchiser les mesures est l'exploitation réelle. L'analyse des données, qui s'appuie sur des sources telles que le catalogue KEV (Known Exploited Vulnerabilities) de la CISA (Cybersecurity and Infrastructure Security Agency), montre systématiquement que les taux d'exploitation restent remarquablement faibles, à des niveaux très inférieurs à 0,5 % par an. Ainsi, environ 1 vulnérabilité sur 200 est activement exploitée. Dans ce contexte, il est préférable d'adopter des approches plus pragmatiques et basées sur les risques.

Il faut traiter en priorité les vulnérabilités les plus susceptibles d'être exploitées et de causer d'importants dommages. Ce sont généralement celles qui permettent un accès à distance non authentifié avec une augmentation des privilèges. Les vulnérabilités de ce type sont considérées comme Critiques ou Importantes. La correction ciblée des vulnérabilités à haut risque et fort impact permet d'optimiser la réduction des risques en fonction des ressources disponibles. Cette stratégie implique d'accepter un faible niveau de risque résiduel pour les vulnérabilités peu susceptibles d'être exploitées ou dont l'impact en cas d'exploitation resterait limité. Ces vulnérabilités sont considérées comme Faibles ou Modérées. 

Une gestion efficace des risques n'impose pas d'éliminer toutes les vulnérabilités. Il s'agit de traiter en priorité celles qui représentent une menace réelle et probable ; pour les autres, il faut reconnaître et accepter les risques tant qu'ils restent gérables.

Quel est le rapport avec le modèle Open Source ?

Les inquiétudes concernant les vulnérabilités non corrigées concernent souvent les solutions Open Source, principalement en raison de leur transparence. Leur code et CVE sont publics, et donc bien visibles. Du côté des solutions propriétaires, les éditeurs choisissent fréquemment de ne pas divulguer certaines vulnérabilités jugées peu importantes, entretenant ainsi un certain manque de transparence. Ainsi, une faille mineure qui entraînerait la création d'une CVE publique dans un environnement Open Source peut, dans le cas d'un logiciel propriétaire, ne pas être signalée, ne pas faire l'objet d'un correctif ou être corrigée sans aucune notification.

Cette différence de visibilité crée un fonctionnement à deux vitesses. Les politiques qui exigent « aucune vulnérabilité connue » pénalisent en réalité la transparence propre à l'Open Source, sans pour autant refléter un risque réel plus élevé. Votre entreprise accepte déjà implicitement le risque de failles mineures non divulguées dans les logiciels propriétaires que vous utilisez au quotidien. Une véritable gestion des risques impose de reconnaître ce fait. Il est essentiel d'évaluer les risques de manière explicite et cohérente, en se concentrant sur la probabilité d'exploitation et les conséquences pour tous les logiciels, plutôt que de sanctionner la visibilité inhérente aux technologies Open Source.

Pour assurer une véritable impartialité dans le domaine de la gestion des vulnérabilités, il faut accepter la singularité du modèle Open Source : il est volontairement extrêmement transparent (pour de bonnes raisons), ce qui le rend en apparence plus vulnérable. Les solutions Open Source impliquent d'accepter explicitement les risques que nous acceptons déjà implicitement dans les logiciels propriétaires.

Certaines données permettent d'ailleurs de valider ce postulat. En effet, la comparaison entre les solutions Red Hat et les données de notre rapport sur les risques 2024 à celles d'un grand éditeur de logiciels propriétaires bien connu fournit des informations très intéressantes qui confirment l'hypothèse susmentionnée. À moins que les solutions propriétaires ne contiennent que des bogues ayant un fort impact (c'est-à-dire facilement exploitables), la répartition des problèmes de niveau Critique/Important et Modéré/Faible devrait être similaire à celle des logiciels Open Source. Autrement dit, il devrait y avoir plus de failles de sécurité mineures que majeures. Les chiffres révèlent pourtant un nombre presque insignifiant de problèmes bénins. Par ailleurs, cet éditeur utilise la même échelle d'évaluation de la gravité sur quatre points que Red Hat.

Les indicateurs dans les rapports de vulnérabilités ne reflètent pas forcément la réalité. Le nombre de CVE bénignes signalées de manière transparente par les projets Open Source (92 % des vulnérabilités de Red Hat étant de niveau Modéré et Faible en 2024) est plus élevé que celui signalé par cet éditeur propriétaire (5,5 % de niveau Modéré et Faible en 2024). La comparaison de ces données ne permet pas d'évaluer les risques de manière relative ; elle révèle principalement un choix de stratégie de communication différent.

Au lieu de s'intéresser au nombre de problèmes ou à la gravité des vulnérabilités, il est préférable d'étudier le facteur essentiel, à savoir l'exploitation réelle. En 2024, seul 0,26 % des vulnérabilités Open Source (11 sur plus de 4 200) affectant les logiciels Red Hat a été exploité sur toutes les plateformes en situation réelle. La hiérarchisation des priorités basée uniquement sur le comptage des vulnérabilités sollicite beaucoup les ressources pour des problèmes qui représentent en pratique une menace minime.

Les éditeurs propriétaires et Open Source donnent tous la priorité à la résolution des problèmes les plus importants. En revanche, ils n'appliquent généralement pas le même niveau de transparence concernant les vulnérabilités jugées mineures et non corrigées. Les entreprises acceptent déjà implicitement ce risque résiduel avec les logiciels propriétaires, alors il est temps d'appliquer explicitement la même approche pragmatique et basée sur les risques réels à tous les logiciels, y compris les solutions Open Source. Tous les éditeurs partagent la même philosophie : résoudre les problèmes importants et ne pas s'attarder sur les failles mineures.

En tant que leaders de la sécurité, nous vous conseillons de ne pas vous limiter à compter les vulnérabilités. Optez pour une stratégie centrée sur les données d'exploitabilité et l'impact commercial potentiel. Mettez en œuvre des processus qui accordent toujours la priorité aux quelques failles susceptibles d'être exploitées, et développez une culture qui comprend et accepte pleinement les risques résiduels gérables. Concentrez vos ressources sur la réduction des menaces qui représentent un véritable danger pour l'entreprise.

Si vous souhaitez approfondir ce sujet, j'en ai parlé lors de la conférence SOSS/Fusion d'OpenSSF l'année dernière en me basant sur des données de 2023, et cette année lors de la conférence VulnCon 2025 en actualisant ma présentation avec les données de 2024.