Le manque de traçabilité de composants Open Source, source de vulnérabilité

Une étude de l’éditeur White Source rappelle aux éditeurs commerciaux l’intérêt de tracer l’usage des composants Open Source dans leurs applications et de veiller à leurs mises à jour en continu. A défaut, des risques de vulnérabilité sont à prévoir.

En dépit d’une sécurité considérée comme renforcée par les mécanismes du développement communautaire et par la transparence du code, les composants Open Source sont à l'origine de certaines vulnérabilités de logiciels commerciaux, révèle la dernière étude de l’éditeur White Source, qui développe des outils de suivi de licences Open Source et de conformité.

Après avoir passé au crible quelque 2 944 applicatifs embarquant des bibliothèques ouvertes, l’éditeur a décelé 23% de composants vulnérables, dont 93% identifiés comme critiques ou moyennement critiques. Un phénomène d’ampleur, car si l’on en croit Gartner, 85% des logiciels dits commerciaux embarqueraient aujourd’hui des composants Open Source. Au-delà du code en lui-même qui n’est pas à proprement parler à l'origine du problème, c’est bien l’usage des composants Open Source qui est pointé du doigt dans cette étude.

En ce sens, elle reprend clairement les conclusions d’une autre étude, réalisée cette fois-ci par Sonatype - et dont LeMagIT s’est fait précédemment l’écho. Ce rapport pointait notamment du doigt le manque de contrôle des entreprises sur l’usage des composants utilisés dans leurs développements, le manque d’inventaire des composants insérés dans les applications ou encore le manque d’intérêt des développeurs pour les questions de sécurité. Autant d’arguments qui invitaient à conclure que la ré-utilisation de composants était bien une des vulnérabilités majeures dans les processus de développement.

Dans une étude prédécente, White Source avait une première fois attiré l’attention sur ce point. L’éditeur avait mis l’accent sur l’utilisation des dépendances indirectes dans le développement applicatif. En se reposant sur des composants Open Source, les développeurs oublient les dépendances qui y sont associées. Le problème ? Ces dépendances, intégrées par négligence, sont parfois encadrées par une autre licence Open Source, pouvant ainsi déstabiliser la conformité du logiciel développé.

Une mise à jour trop rare

Pour White House, le souci tient au manque de suivi dans les processus. Ainsi, sur les 2 944 projets applicatifs analysés et vulnérables, seulement 1,3% comportait des composants Open Source mis à jour dans leurs dernières versions. « Souvent, personne n’est dédié à contrôler en permanence les composants Open Source pour identifier les mises à jour. Sans notre étude, 98,7% des bibliothèques Open Source comportant des vulnérabilités n’ont pas été mises à jour. Cela représente des risques considérables en matière de sécurité et pour l’activité de l’entreprise, tant du côté de l’éditeur que du consommateur […] », résume Rami Sass, le CEO White Source. Ainsi, si le mécanisme communautaire de développement permet d’accélérer la correction des vulnérabilités, les utilisateurs des composants tardent à les appliquer, voire ignorent les montées de versions. Pour White Source, la complexité des processus de traçabilité des composants en est évidemment la cause.

« Assurément, les éditeurs de logiciels commerciaux doivent être éduqués sur l’Open Source. Et pas seulement sous l’angle des communautés, mais sous l’angle de l’impact produit car cela a un conséquence directe sur leurs produits et leurs services. Si un éditeur utilise un module Open Source vulnérable, son produit est aussi vulnérable. Généralement, les éditeurs testent la sécurité de leur propre code, mais laissent passer celle des composants Open Source, pourtant distribués avec leurs produits », précise un responsable de White Source dans un email à la rédaction.

Et d’après White Source, les vulnérabilités les plus courantes, identifiées chez ses clients, portent sur des projets clé de l’Open Source, comme dans le framework Spring, dans Apache POI (qui permet de manipuler avec Java des documents Office), ou encore Apache Xerces2 (qui permet notamment de parser des documents XML).

Pour approfondir sur Gestion des vulnérabilités et des correctifs (patchs)

Close