IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    Février 2017
    Messages
    1 815
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Février 2017
    Messages : 1 815
    Points : 50 937
    Points
    50 937
    Par défaut 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.

    Nom : OSSRA_2018.png
Affichages : 2819
Taille : 150,8 Ko

    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 ?

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

    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 :

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

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

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Inactif  
    Homme Profil pro
    Analyste-Programmeur / Intégrateur ERP
    Inscrit en
    Mai 2013
    Messages
    2 511
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste-Programmeur / Intégrateur ERP
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mai 2013
    Messages : 2 511
    Points : 10 335
    Points
    10 335
    Par défaut
    Citation Envoyé par Patrick Ruiz Voir le message
    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 ?


    Citation Envoyé par Patrick Ruiz Voir le message
    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 Voir le message
    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. ^^

  3. #3
    Modérateur
    Avatar de kolodz
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2008
    Messages
    2 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Avril 2008
    Messages : 2 211
    Points : 8 316
    Points
    8 316
    Billets dans le blog
    52
    Par défaut
    Citation Envoyé par Zirak Voir le message
    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 ?
    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."
    Si une réponse vous a été utile pensez à
    Si vous avez eu la réponse à votre question, marquez votre discussion
    Pensez aux FAQs et aux tutoriels et cours.

  4. #4
    Membre extrêmement actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2017
    Messages
    1 758
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Octobre 2017
    Messages : 1 758
    Points : 5 667
    Points
    5 667
    Par défaut
    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?

    Si le code "propriétaire" des applications "propriétaires" était moins sujet aux bugs et aux failles de sécurité, cela se saurait...

  5. #5
    Inactif  
    Homme Profil pro
    Analyste-Programmeur / Intégrateur ERP
    Inscrit en
    Mai 2013
    Messages
    2 511
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste-Programmeur / Intégrateur ERP
    Secteur : Bâtiment

    Informations forums :
    Inscription : Mai 2013
    Messages : 2 511
    Points : 10 335
    Points
    10 335
    Par défaut
    @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 :

    « 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.

  6. #6
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2007
    Messages
    2 161
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Août 2007
    Messages : 2 161
    Points : 7 952
    Points
    7 952
    Par défaut
    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.

  7. #7
    Modérateur
    Avatar de kolodz
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2008
    Messages
    2 211
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Avril 2008
    Messages : 2 211
    Points : 8 316
    Points
    8 316
    Billets dans le blog
    52
    Par défaut
    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 :
    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.
    ...
    Si une réponse vous a été utile pensez à
    Si vous avez eu la réponse à votre question, marquez votre discussion
    Pensez aux FAQs et aux tutoriels et cours.

Discussions similaires

  1. Réponses: 73
    Dernier message: 23/10/2023, 16h28
  2. Réponses: 16
    Dernier message: 12/09/2022, 20h46
  3. Réponses: 54
    Dernier message: 07/01/2018, 22h27
  4. Réponses: 32
    Dernier message: 15/05/2013, 17h50
  5. Réponses: 0
    Dernier message: 30/07/2009, 11h42

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo