Une étude révèle que la part de composants ouverts est en forte hausse au sein des applications propriétaires

Version imprimable

23/05/2018, 16h40
Patrick Ruiz

1 pièce(s) jointe(s)

Une étude révèle que la part de composants ouverts est en forte hausse au sein des applications propriétaires

Une étude révèle que la part de composants ouverts est en forte hausse au sein des applications propriétaires
Et tire la sonnette d’alarme

Chaque année, Synopsis – un centre de recherche sur l’open source – procède à la publication d’un rapport sur l’analyse des risques et la sécurité dans la sphère des logiciels ouverts. Le rapport 2018, publié il y a peu, révèle que la part de composants open source est en forte croissance au sein des applications propriétaires. La firme tire sur la sonnette d’alarme …

En substance, Synopsis a passé 1100 bases de code à usage commercial au crible en 2017 et note que 96 % contiennent des composants ouverts ; le même pourcentage que celui de l’année précédente. La firme ajoute que désormais, plusieurs applications contiennent plus de composants open source que de code propriétaire. Dans les chiffres, le pourcentage de composants open source au sein des bases de code desdites applications a grimpé de 36 % en 2016 à 57 % en 2017.

Synopsis tire sur la sonnette d’alarme

En ajoutant que 78 % des bases de code examinées sont touchées par au moins une vulnérabilité connue et qu’on en dénombre 64 en moyenne par base de code, une augmentation de 134 % par rapport à l’année précédente. D’après la firme, ces chiffres collent avec ceux de la base de données américaine NVD qui, en 2017, a listé 14 700 failles de sécurité contre 6400 en 2016. « Les chiffres NVD font référence à tous les types de vulnérabilités connus, mais plus de 4800 de ces dernières affectaient des composants ouverts », lit-on.

Dans son rapport, la firme a classé plus de la moitié (54 %) des vulnérabilités identifiées comme étant à haut risque, c’est-à-dire, aisément exploitables. 17 % des failles identifiées ont fait l’objet de communication à grande échelle : Heartbleed, Logjam, FREAK, DROWN, POODLE. Logjam est la vulnérabilité la plus répandue avec 11 % de bases de code affectées. La faille dans Apache Struts 2 devenue célèbre avec le hack d’Equifax a elle aussi été retrouvée dans 33 % des bases de code faisant usage de Struts.

Pièce jointe 382740

L’étude a porté sur des données tirées d’une large gamme de secteurs d’activité : cybersécurité, automobile, big data, services financiers, logiciels d’entreprise, santé, fabrication, marché des applications mobiles, Internet des objets (IoT), etc. L’Internet et les infrastructures logicielles engrangent le plus gros pourcentage de failles à haut risque (67 %). Les applications mobiles (60 %) et le gaming (50 %) complètent le podium.

La sécurité, point faible de l’open source ?

Le rapport de Synopsis se veut clair : « l’open source n’est ni plus sécurisé (ni moins) que le code propriétaire. » Toutefois, des chiffres du rapport sont révélateurs de certaines tares du modèle de sécurité de l’open source. « En moyenne, les failles identifiées dans l’audit sont vieilles de 6 ans », note Synopsis. « Il y a donc comme un manque de réactivité de la part de la communauté qui entraîne une accumulation des vulnérabilités au sein des bases de code », ajoute la firme.

Au-delà des risques liés à la sécurité lorsque les porteurs d’offres propriétaires décident d’intégrer des composants open source, il y a la problématique des licences. « Les composants ouverts sont gouvernés par plus de 2500 licences, chacune avec des obligations et des degrés divers de restrictions. Faillir à la mise en conformité avec ces dernières peut mener à des litiges et compromettre la propriété intellectuelle », note une fois de plus Synopsis.

Le point de la firme de recherche est que, dans un contexte où 80 % des cyberattaques ont lieu au niveau de la couche des applications, les porteurs de projet qui décident d’intégrer des composants ouverts gagneraient à avoir une bonne visibilité pour éviter les mauvaises surprises.

Source : Rapport (format PDF)

Et vous ?

:fleche: « La vieillesse des failles » est-elle l’exclusivité de l’open source ? Qu’en est-il du code propriétaire ?

:fleche: Comment mettez-vous la réactivité de la communauté open source en perspective avec ce qui se fait dans l’univers propriétaire ?

Voir aussi :

:fleche: Open Source : que faire lorsque la documentation d'une bibliothèque est absente ? Comment gérez-vous des cas de ce type ?

:fleche: Logiciel libre et open source : les deux concepts sont parfois utilisés de manière interchangeable , mais quelle est la différence ?

:fleche: Microsoft publie en open source le code de File Manager, son gestionnaire de fichiers qui a été disponible en 1990 et en autorise les modifications
23/05/2018, 17h01
Zirak

Citation:

Envoyé par Patrick Ruiz

Synopsis tire sur la sonnette d’alarme ...

En ajoutant que 78 % des bases de code examinées sont touchées par au moins une vulnérabilité connue et qu’on en dénombre 64 en moyenne par base de code, une augmentation de 134 % par rapport à l’année précédente. D’après la firme, ces chiffres collent avec ceux de la base de données américaine NVD qui, en 2017, a listé 14 700 failles de sécurité contre 6400 en 2016. « Les chiffres NVD font référence à tous les types de vulnérabilités connus, mais plus de 4800 de ces dernières affectaient des composants ouverts », lit-on.

Donc ils ont listés 14 700 failles, dont un peu plus de 4800 concernant l'open-source, ce qui laisse donc plus de 2/3 des failles concernant du code propriétaire non ? Et ils tirent l'alarme à propos du code open-source ? 8O

Citation:

Envoyé par Patrick Ruiz

Dans son rapport, la firme a classé plus de la moitié (54 %) des vulnérabilités identifiées comme étant à haut risque, c’est-à-dire, aisément exploitables. 17 % des failles identifiées ont fait l’objet de communication à grande échelle : Heartbleed, Logjam, FREAK, DROWN, POODLE. Logjam est la vulnérabilité la plus répandue avec 11 % de bases de code affectées. La faille dans Apache Struts 2 devenue célèbre avec le hack d’Equifax a elle aussi été retrouvée dans 33 % des bases de code faisant usage de Struts.

Puisqu'il s'agit de code open-source utilisé dans des applis propriétaires, plutôt que d'accuser la communauté open-source d'être trop lente dans les correctifs (cf passage ci-dessous), est-ce qu'il en faudrait pas plutôt se poser la question si l'entreprise propriétaire de l'appli a bien appliqué les correctifs dans le code open-source qu'elle utilise ?

Est-ce qu'ils ont été comparer le code open-source présent dans l'appli propriétaire avec ce même code-open source, là où il est maintenu et diffusé pour voir si il était bien à jour ?

Citation:

Envoyé par Patrick Ruiz

Le rapport de Synopsis se veut clair : « l’open source n’est ni plus sécurisé (ni moins) que le code propriétaire. » Toutefois, des chiffres du rapport sont révélateurs de certaines tares du modèle de sécurité de l’open source. « En moyenne, les failles identifiées dans l’audit sont vieilles de 6 ans », note Synopsis. « Il y a donc comme un manque de réactivité de la part de la communauté qui entraîne une accumulation des vulnérabilités au sein des bases de code », ajoute la firme.

Quand sur 14 700 failles identifiées, il n'y en a que 4800 ou un peu plus qui concernent l'open-source, j'ai quand même l'impression que si, le code open-source a l'air un poil plus sécurisé, c'est purement mathématique...

Enfin bref, l'article original si il a bien été traduit, ne me semble pas franchement objectif. ^^
24/05/2018, 09h55
kolodz

Citation:

Envoyé par Zirak

Donc ils ont listés 14 700 failles, dont un peu plus de 4800 concernant l'open-source, ce qui laisse donc plus de 2/3 des failles concernant du code propriétaire non ? Et ils tirent l'alarme à propos du code open-source ? 8O

La problématique étant que les failles "open-source" se retrouve dans énormément d'application différente. Car l'open-source est de plus en plus utilisé. D'où le fait qu'une faille dans un compense "open-source" soit plus problématique.
Surtout qu'il est beaucoup plus facile de tester les failles connus "open-source" que de chercher une faille spécifique à l'application final.
D'un point de vue sécurité, il n'est pas idiot de le rappeler... Cela évitera peut-être quelques "Non, on ne va pas mettre à jour le librairies parce que ça coûte trop cher."
24/05/2018, 10h07
Anselme45

Quel est le rapport entre "composants ouverts" et "nombre de failles"?

C'est un peu comme si je fais la relation entre le pourcentage d'écossais portant le kilt et le nombre de poils frisés que l'on dénombre sur leur mollets? :mouarf:

Si le code "propriétaire" des applications "propriétaires" était moins sujet aux bugs et aux failles de sécurité, cela se saurait...
24/05/2018, 10h26
Zirak

@kolodz :

Oui enfin là, il n'est pas question de l'open-source en général, mais de l'open-source présent dans des applications propriétaires et on en profite quand même pour tacler la communauté open-source en général, c'est plus cela qui me gêne.

Alors oui, d'un point de vue sécurité, il faut effectivement rappeler que l'open-source contient aussi des failles, je suis d'accord avec toi, pas de souci la-dessus, mais dans l'article on trouve tout de même cela :

Citation:

« En moyenne, les failles identifiées dans l’audit sont vieilles de 6 ans », note Synopsis. « Il y a donc comme un manque de réactivité de la part de la communauté qui entraîne une accumulation des vulnérabilités au sein des bases de code », ajoute la firme.

Non je suis désolé, ces failles ont eu des correctifs depuis un moment, ce n'est pas un problème de réactivité de la communauté, mais des devs des applis propriétaires à les mettre à jour.

Pour moi, c'est un peu comme si ils disaient "ce n'est pas notre faute si il y a des failles dans les applis propriétaires, c'est les composant open-source qu'on n'a même pas développé nous-mêmes qui ne sont pas à jour".

Je trouve que c'est à la fois cracher dans la soupe ET se dédouaner de leur propre incompétence.

Alors je ne sais pas si tout le rapport est comme ça, ou si c'est seulement les extraits choisis par le rédacteur de l'article, mais il y en a un des deux qui n'est pas du tout objectif. :)
24/05/2018, 10h44
Saverok

Ce qui me choque pas mal est de constater à quelle points les entreprises qui utilisent des libraires open-sources afin d'en tirer profit ne contribuent pas à l'amélioration de ces librairies justement !!

C'est super facile critiquer ces librairies car elles contiennent des failles mais la moindre des choses seraient de contribuer à les corriger.

De plus, comme dit par d'autres, les entreprises tardent très souvent à mettre à jour les versions des librairies pour corriger les failles.
Il s'agit donc bien d'un manque de sérieux et de réactivité des entreprises et non des communautés open source.

Je finirai aussi par pointer totalement du doigt la responsabilité des entreprises qui ne contrôlent pas assez leur fournisseur.
Quand on va au restaurant et qu'on est victime d'un empoisonnement alimentaire en raison d'une viande avariée.
On attaque le restaurateur et c'est normal !
C'est à lui de contrôler la qualité et la fraîcheur des aliments qu'il sert à ses clients et donc, par extension, de contrôler et challenger ses fournisseurs sur ces points.

Pourquoi serait-ce différent pour l'info ?
Si une entreprise se fourni en code auprès d'une librairie open source, c'est à elle de contrôler la fiabilité de ce code.
Si le code de la librairie contient des failles, c'est avant tout la responsabilité de l'entreprise qui utilise cette lib qui est à mettre en avant.
24/05/2018, 11h00
kolodz

Il y a certes une mauvais citation du rapport.
Cependant, il serai peut-être plus intéressant de lire la conclusion(de la conclusion) du rapport :

Citation:

But with the growth in open source use, organizations also need to ensure that software composition analysis (SCA) is in their application security toolbelt. With the addition of SCA, organizations can effectively detect vulnerabilities in open source components as they manage whatever license compliance their use of open source may require.
Know your code. By integrating policies, processes, andautomated solutions into the software development life cycle to identify, manage, and secure open source, organizations can maximize the benefits of open source while effectively managing its vulnerability and license risks.

...