+ Répondre à la discussion Actualité déjà publiée
Page 1 sur 2 12 DernièreDernière
Affichage des résultats 1 à 20 sur 21
  1. #1
    Responsable Actualités

    Avatar de Hinault Romaric
    Homme Profil pro
    Consultant
    Inscrit en
    janvier 2007
    Messages
    4 018
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2007
    Messages : 4 018
    Points : 60 045
    Points
    60 045

    Par défaut Plus d’un tiers des bibliothèques open source ont des vulnérabilités connues

    Plus d’un tiers des bibliothèques open source ont des vulnérabilités connues
    80% du code des applications repose sur celles-ci, selon un rapport de Sonatype

    De nombreuses entreprises utilisent des composants et des bibliothèques open source contenant des vulnérabilités pour la conception de leurs applications, selon un rapport mené conjointement par l’éditeur de logiciels Sonatype et la firme de sécurité Aspect Security.

    L’entreprise Sonatype fournit un gestionnaire de version centralisé, hébergé pour plus de 300 000 bibliothèques qui sont téléchargées pour des applications ou des solutions open source. Près de 4 milliards de requêtes sont effectuées par an sur ces composants.

    Le rapport basé sur 31 bibliothèques populaires téléchargées au cours des 12 derniers mois a révélé que plus d’un tiers des 1 261 versions de ces composants avaient des vulnérabilités connues.

    Ces vulnérabilités sont couramment ignorées par les développeurs, surtout qu’il manque un système d’alerte sur les failles et les patchs. « 80% du code dans les applications de nos jours provient des bibliothèques. Le risque de vulnérabilité dans ces composants est largement ignoré et sous-estimé » explique Jeff Williams, directeur de recherche pour Aspect Security.

    Les bibliothèques vulnérables les plus téléchargées sont entre autres Google Web Toolkit, Apache Xerces, Spring MVC et Struts 1.x.

    Les types de vulnérabilités découvertes dans les bibliothèques open source sont très variables, allant des failles pouvant permettre l’exécution du code arbitraire, aux failles pouvant compromettre les données et permettre à un pirate distant d’accéder à celles-ci.

    Ce rapport est à prendre néanmoins avec modération, car une étude publiée par Coverity le mois dernier révélait que le code source des applications open source était d’une qualité égale, voire meilleure que celle des applications propriétaires.


    Source : Le rapport téléchargeable après inscription


    Et vous ?

    Qu'en pensez-vous ?
    Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
    Mon blog Mes articles
    En posant correctement votre problème, on trouve la moitié de la solution

  2. #2
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 733
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 733
    Points : 6 941
    Points
    6 941

    Par défaut

    Apache Xerces nommé ci-dessus est un parser sax XML, il est bien possible que 80% des utilisations qui en sont faites ne présente aucune vulnérabilité.

    Bref à mon sens, un gros chiffre comme ça ne veut pas dire grand chose sans situation concrète, est-ce que ces vulnérabilités sont tranquillement exploitables sans autres sur le net ou celles-ci dépendent-t-elles d'un concours de circonstances super fumeux qui a presque aucune chance de se produire?

    Peu de précision, et on dirait une manière éventuellement de vendre du service à voir le formulaire sur la source...

  3. #3
    Membre éclairé

    Homme Profil pro
    Chargé de projets JEE - BI
    Inscrit en
    septembre 2002
    Messages
    41
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Chargé de projets JEE - BI
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : septembre 2002
    Messages : 41
    Points : 326
    Points
    326

    Par défaut

    On peut rajouter un exemple actuel, celui de µClibc, librairie C, utilisée dans les freebox, live box, etc. et qui ne sait pas remettre à l'heure d'été nos box...

  4. #4
    Membre chevronné
    Avatar de ProgVal
    Homme Profil pro
    Étudiant
    Inscrit en
    mai 2006
    Messages
    636
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 21
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mai 2006
    Messages : 636
    Points : 685
    Points
    685

    Par défaut

    Citation Envoyé par Hinault Romaric Voir le message
    L’entreprise Sonatype fournit un gestionnaire de version centralisé, hébergé pour plus de 300 000 bibliothèques qui sont téléchargées pour des applications ou des solutions open source. Près de 4 milliards de requêtes sont effectuées par an sur ces composants.

    Le rapport basé sur 31 bibliothèques populaires téléchargées au cours des 12 derniers mois a révélé que plus d’un tiers des 1 261 versions de ces composants ont des vulnérabilités connues.
    À noter qu'il s'agit de 31 bibliothèques hébergées par Sonatype ; service dont je n'ai personnellement jamais entendu parler. En même temps, ils ne proposent que de l'hébergement pour Apache Maven, qui est un gestionnaire de version pour Java ; et je ne fréquente pas ce milieu, hormis pour Android.
    Ajoutons, pour la petite histoire, qu'ils utilisent GitHub.

    Citation Envoyé par Hinault Romaric Voir le message
    Ces vulnérabilités sont couramment ignorées par les développeurs, surtout qu’il manque un système d’alerte sur les failles et les patchs.
    Et les bugtrackers, ça sert à quoi ?
    Toujours pour la petite histoire : Sonatype propose un service de gestion des failles de sécurité. Pas génial comme publicité...

    Citation Envoyé par Hinault Romaric Voir le message
    Ce rapport est à prendre néanmoins avec modération, car une étude publiée par Coverity le mois dernier révélait que le code source des applications open source était d’une qualité égale, voire meilleure que celle des applications propriétaires.
    Étude qui avait également l'air assez vague.

    Citation Envoyé par Hinault Romaric Voir le message
    Qu'en pensez-vous ?
    En plus de se restreindre à un langage en particulier, et de nous présenter plein de jolis chiffres.
    De plus, l'étude est ici plus ou moins présentée comme opposant bibliothèques open sources et non open sources, alors que ce n'est à l'origine pas le cas (je n'ai pas lu le rapport ; je n'ai pas envie de m'inscrire).
    En plus, j'ai du mal à comprendre le concept de « vulnérabilité connue », mais dont ceux-ci ne sont pas « alertés ».






    Citation Envoyé par mtranchant Voir le message
    On peut rajouter un exemple actuel, celui de µClibc, librairie C, utilisée dans les freebox, live box, etc. et qui ne sait pas remettre à l'heure d'été nos box...
    Sisi, elle sait remettre à l'heure. C'est seulement que Free et Orange ont eu la flemme d'intégrer le patch qui a été soumis l'an dernier.

  5. #5
    Membre expérimenté
    Homme Profil pro
    Étudiant
    Inscrit en
    octobre 2011
    Messages
    165
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : octobre 2011
    Messages : 165
    Points : 509
    Points
    509

    Par défaut

    Si Coverty et Sonatype ont toutes les deux raisons, ça veut dire qu'un tiers ou plus de toutes les bibliothèques (open source ou pas) ont une vulrabilité connue (peut non dévoilé)…

    De toutes façon je crois qu'elles ont toutes les deux tords… sur leur manière de faire des stats.
    On manque clairement de statisticiens dans notre société !

  6. #6
    Expert Confirmé Sénior
    Avatar de tchize_
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    avril 2007
    Messages
    21 890
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Service public

    Informations forums :
    Inscription : avril 2007
    Messages : 21 890
    Points : 41 481
    Points
    41 481

    Par défaut

    Il faut voir aussi dans quelles mesures ces failles sont exploitables. Tu n'effectue pas le même niveau de test entre une application visible de millions de personnes et, comme c'est selon moi la majorité des développements, une application destinée à servir sur un serveur interne d'entreprise sur lequel il faut se logguer avant de pouvoir faire quoi que ce soit.
    Tchize (Чиз) faq java, cours java, javadoc. Pensez à et

  7. #7
    Invité de passage
    Inscrit en
    janvier 2008
    Messages
    3
    Détails du profil
    Informations forums :
    Inscription : janvier 2008
    Messages : 3
    Points : 4
    Points
    4

    Par défaut

    @ProgVal
    >31 bibliothèques hébergées par Sonatype ; service dont je n'ai personnellement jamais entendu parler
    Sonatype est la compagnie qui gere aujourd'hui Maven Central, le plus grand repo de binaires (java et scala aussi maintenant) au monde; accessible par Maven/Ivy/Gradle

    >Ajoutons, pour la petite histoire, qu'ils utilisent GitHub.
    ok et alors ?

    > Toujours pour la petite histoire : Sonatype propose un service de gestion des failles de sécurité. Pas génial comme publicité...
    Ben si justement ; ils ont les stats de maven central, et ils analysent les librairies (ils les soumettent à des bases de vulnérabilités connues) qui y sont hébergées : ils sont capables de te dire si ton client/employeur (via l ip de l'entreprise) utilise des librairies avec des vulnérabilités critiques et propose plein d'outils (service payant, faut bien vivre) pour notifier les DSI que leurs développeurs intègrent potentiellement des lib désuètes ou ayant des vulnérabilités connues


    Maintenant que des libs open sources présentent des vulnérabilités, c'est assez normal, vu le nombre qu'il existe; cependant, de ma (courte) expérience, le code propriétaire est souvent bien plus vulnérable/ peu performant / mal désigné/ peu testé que le code open source car après tout, personne vient mettre son nez dedans pour l'améliorer et le critiquer...

  8. #8
    Expert Confirmé Sénior
    Avatar de tchize_
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    avril 2007
    Messages
    21 890
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Service public

    Informations forums :
    Inscription : avril 2007
    Messages : 21 890
    Points : 41 481
    Points
    41 481

    Par défaut

    Citation Envoyé par anthony43 Voir le message
    ils sont capables de te dire si ton client/employeur (via l ip de l'entreprise) utilise des librairies avec des vulnérabilités critiques et propose plein d'outils (service payant, faut bien vivre) pour notifier les DSI que leurs développeurs intègrent potentiellement des lib désuètes ou ayant des vulnérabilités connues
    Mouais, bof, si comme la pluspart des boites, t'as un nexus interne, ils vont pas voir beaucoup de requêtes. Plus, pour la plupart des librairies répandue, tu verra chez moi des requetes qui vont de la version 1.0 à 5.0 avec tous les intermédiaires possibles. Pourquoi? Bien qu'on utilise la dernière version (quand c'est le cas) les dépendances de compilation utilisent bien souvent des version antérieures.

    Donc le rapport serait bourré à 99% de faux positifs
    Tchize (Чиз) faq java, cours java, javadoc. Pensez à et

  9. #9
    Expert Confirmé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    décembre 2008
    Messages
    805
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : décembre 2008
    Messages : 805
    Points : 2 650
    Points
    2 650

    Par défaut

    Petite correction:
    Sur l'encart publicitaire (on peut pas appeler ça autrement, si encore il y avait un ou deux noms de cités, avec ou sans failles q), c'est écrit 26%, c'est plus proche de 1/4 que d'1/3.

    Pour le reste: bof.
    "Etude" limitée à un langage seul (qui plus est pour lequel je n'ai aucun amour).
    Présentation de l'étude qui ressemble à un encart publicitaire.
    Etude par un repo dont je n'ai jamais entendu parler (sûrement parce que moi je java...).

    Et puis bon, en java, on redonne volontairement un certain nombre de contrôles au langage, tels que la gestion de la mémoire (dans une certaine mesure).
    Etrangement, j'ai envie de dire que si on peut injecter du code dans une appli, c'est p'tet la faute au langage, dans ce cas. Puisque le programmeur n'est pas censé s'occuper de ce genre de choses.
    En C, C++, ASM et autres, la faute reviendrai au développeur, mais la...

    En outre, ils ne citent même pas un nom de faille/vulnérabilité. Comment peut-on avoir ne serait-ce qu'une idée vague de ce qu'ils ont trouvé... perso, ça me donne pas envie de m'inscrire pour recevoir leur machin.

  10. #10
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 733
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 733
    Points : 6 941
    Points
    6 941

    Par défaut

    Citation Envoyé par Freem Voir le message
    Et puis bon, en java, on redonne volontairement un certain nombre de contrôles au langage, tels que la gestion de la mémoire (dans une certaine mesure).
    Etrangement, j'ai envie de dire que si on peut injecter du code dans une appli, c'est p'tet la faute au langage, dans ce cas. Puisque le programmeur n'est pas censé s'occuper de ce genre de choses.
    En C, C++, ASM et autres, la faute reviendrai au développeur, mais la...
    Vu la nature de java, injecter du code depuis l'extérieur en passant par une librairie ça me paraît un peu chaud. Je pense qu'on parle surtout, puisque des frameworks web sont impliqués, d'injection SQL ou XSS.

    Ca élargit encore le débat sur les "failles" mentionnées sur lesquelles nous n'avons aucun détail quant à la part de responsabilité du développeur dans son exploitation. On peut en plus se demander où la barre a été placée entre *faille* et *risque potentiel*.

  11. #11
    Expert Confirmé Sénior
    Avatar de tchize_
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    avril 2007
    Messages
    21 890
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Service public

    Informations forums :
    Inscription : avril 2007
    Messages : 21 890
    Points : 41 481
    Points
    41 481

    Par défaut

    Citation Envoyé par _skip Voir le message
    Vu la nature de java, injecter du code depuis l'extérieur en passant par une librairie ça me paraît un peu chaud.
    Tout dépend des librairies impliquées.

    Des librairies comme JSF, struts, etc utilisent fortement de l'introspection. Résultat, que se passe-t-il si j'arrive à rediriger JSF ou Struts vers Runtime.exec() par introspection?

    Des librairies comme aspectj interagissent avec le classloader, elles sont un facteur de risque à prendre en compte.

    Des librairies hibernate ou DAO risquent l'injection sql évidement

    et des librairies de sécurité généralistes courent le risque d'avoir un trou laissant quelqu'un se faire passer pour un admin.

    Les failles mentionnées dans le document font froid dans le dos (exécution arbitraire d'applications natives sur une machine faisant tourner du struts 2)
    Tchize (Чиз) faq java, cours java, javadoc. Pensez à et

  12. #12
    Membre Expert
    Avatar de SurferIX
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mars 2008
    Messages
    473
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : mars 2008
    Messages : 473
    Points : 1 012
    Points
    1 012

    Par défaut

    Citation Envoyé par Hinault Romaric Voir le message
    Plus d’un tiers des bibliothèques open source ont des vulnérabilités connues
    80% du code des applications repose sur celles-ci, selon un rapport de Sonatype
    Je vois deux problèmes :
    - "selon un rapport de Sonatype"
    - bibliothèques open source.

    Il faut être réaliste et honnêtement, quel pourcentage de bibliothèques non open source ont des vulnérabilités inconnues (ce qui, techniquement parlant, est pire) ?

    Il suffit de voir Microsoft, et toutes les mises à jours, avec ses bulletins de sécurité et les failles considérées comme critiques. Ce sont des failles dite "zéro day", c'est à dire qu'elles sont immédiatement exploitables. Microsoft ne divulgue les problèmes qu'après avoir fait les mises à jour, mais si un pirate les trouve avant Microsoft ?

    Et surtout, pour en revenir au pourcentage, même si on critique l'open source, il faut rester lucide : je pense qu'il y a le même pourcentage, voire pire, dans le monde "closed source".
    "Ceci dit" est un non sens. Cf Wikipedia. C'est soit "cela dit", soit rien.
    Il ne faut pas oublier que la politesse et le respect sont mutuels.

    Dernières prestations de HQF Development:

  13. #13
    Expert Confirmé
    Avatar de MiaowZedong
    Grand Timonier des Chats
    Inscrit en
    décembre 2011
    Messages
    681
    Détails du profil
    Informations professionnelles :
    Activité : Grand Timonier des Chats

    Informations forums :
    Inscription : décembre 2011
    Messages : 681
    Points : 2 633
    Points
    2 633

    Par défaut

    Il me semble que cela porte avant tout sur l'utilisation de versions obsolètes des frameworks, comportant des failles connues (corrigées dans les versions plus récentes).

    Là c'est un mal connu: il faut toujours utiliser les dernières versions dans l'open source (dans le propriétaire c'est plus compliqué, la montée en version sert à faire payer à nouveau le client). Il est extrèmement courant que les malwares se répandent en exploitant des failles déjà corrigées, en profitant de la stupidité d'organisations qui n'ont pas fait leurs mises à jour. Il est vraiment plus que temps de faire comprendre en entreprise qu'un patch critique est critique, point.

  14. #14
    Expert Confirmé Sénior
    Avatar de tchize_
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    avril 2007
    Messages
    21 890
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Service public

    Informations forums :
    Inscription : avril 2007
    Messages : 21 890
    Points : 41 481
    Points
    41 481

    Par défaut

    l'idéal selon moi serait que des outils comme maven puissent te faire un "potential vulnerability assessement" sur base des versions présentes dans ton .war au final. Parce que si, pour chaque application développée en interne sur des projets de 3 à 4 mois, je dois me coltiner de suivre les update de 80 librairies et, toutes les semaines, faire une mise à jour pour utiliser la dernière version de X ou Y, a bout de 4 projet, mon équipe est à l'arrêt.



    Et faire une mise à jour de sécurité, ce n'est souvent possible en temps raisonnable que si on reste dans la même révision mineure. Passer à la majeure suivante, c'est parfois beaucoup de boulot. API incompatibles, nouveaux fichiers de configurations, repasser toutes les batteries de test quality control.
    Enfin, quand on a un mix de closed source et d'open source, que le closed source n'est plus maintenu (ou coute trop d'énergie à migrer) et n'est pas compatible avec la nouvelle version de xerces ou de xml-api, on est vite dans un cul de sac.

    Tout ça ça coute énormément d'argent. Alors oui, souvent, on reste avec les ancienne librairies et on assume les risques. Tout est une question de moyen et du rapport entre les moyens et les risques.
    Tchize (Чиз) faq java, cours java, javadoc. Pensez à et

  15. #15
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 733
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 733
    Points : 6 941
    Points
    6 941

    Par défaut

    Citation Envoyé par tchize_ Voir le message
    Tout dépend des librairies impliquées.

    Des librairies comme JSF, struts, etc utilisent fortement de l'introspection. Résultat, que se passe-t-il si j'arrive à rediriger JSF ou Struts vers Runtime.exec() par introspection?

    Des librairies comme aspectj interagissent avec le classloader, elles sont un facteur de risque à prendre en compte.
    Mais tu introspectes des bean de ton propre domaine normalement, comment une personne externe pourrait forcer ton application à introspecter Runtime plutôt que MonBeanDTO? Je dis pas que c'est impossible mais ça me paraît clairement chaud de détourner extérieurement ce mécanisme.

    Des librairies hibernate ou DAO risquent l'injection sql évidement
    Pas plus, sinon moins que du JDBC standard... Sachant que la plupart des ORM utilisent des peparedStatement.

    Là aussi le problème c'est qu'il manque les use case pour qu'on puisse juger.

  16. #16
    Expert Confirmé Sénior
    Avatar de tchize_
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    avril 2007
    Messages
    21 890
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Service public

    Informations forums :
    Inscription : avril 2007
    Messages : 21 890
    Points : 41 481
    Points
    41 481

    Par défaut

    Citation Envoyé par _skip Voir le message
    Mais tu introspectes des bean de ton propre domaine normalement, comment une personne externe pourrait forcer ton application à introspecter Runtime plutôt que MonBeanDTO? Je dis pas que c'est impossible mais ça me paraît clairement chaud de détourner extérieurement ce mécanisme.
    Cette vulnérabilité a frappé struts 2 et a été qualifié de "facile à mettre en oeuvre", quelle que soit l'application concernée d'ailleurs. Spring a une vulnérabilité similaire où tu peux lui faire interpréter un EL quelconque à partir d'une requête http.

    Pas plus, sinon moins que du JDBC standard... Sachant que la plupart des ORM utilisent des peparedStatement.

    Là aussi le problème c'est qu'il manque les use case pour qu'on puisse juger.
    Bien sûr, mais le fait est que si tu utilise hibernate et que suite à une erreur de codage ça pourrait arriver mais tu n'en sais rien, ça nécessite que tu check régulièrement. Et, cf mon poste précédente, en général, tu n'en a pas les moyens
    Tchize (Чиз) faq java, cours java, javadoc. Pensez à et

  17. #17
    Invité de passage
    Inscrit en
    janvier 2008
    Messages
    3
    Détails du profil
    Informations forums :
    Inscription : janvier 2008
    Messages : 3
    Points : 4
    Points
    4

    Par défaut

    Citation Envoyé par tchize_ Voir le message
    Mouais, bof, si comme la pluspart des boites, t'as un nexus interne, ils vont pas voir beaucoup de requêtes
    pas besoin de faire 100 fois la même requête, une seule fois (via ton repo manager interne) et ils le savent que t'utilisent log4j 1.0

    Citation Envoyé par tchize_ Voir le message
    l'idéal selon moi serait que des outils comme maven puissent te faire un "potential vulnerability assessement" sur base des versions présentes dans ton .war au final. Parce que si, pour chaque application développée en interne sur des projets de 3 à 4 mois, je dois me coltiner de suivre les update de 80 librairies et, toutes les semaines, faire une mise à jour pour utiliser la dernière version de X ou Y, a bout de 4 projet, mon équipe est à l'arrêt.
    çà tombe bien, çà existe, et çà s'appelle sonatype insight, mais faut passer à la caisse d'abord.

    Cette étude, elle sert juste à prouver que la majorité des utilisateurs (pas tous) de bibliothèques java font justement pas attention aux failles de sécurité et que eux autres (Sonatype) fournissent un service qui pourrait rendre service à ces personnes là.

    pour info BlackDuck software propose un service à peu près similaire...

  18. #18
    Expert Confirmé Sénior
    Avatar de tchize_
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    avril 2007
    Messages
    21 890
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Service public

    Informations forums :
    Inscription : avril 2007
    Messages : 21 890
    Points : 41 481
    Points
    41 481

    Par défaut

    oui, mais j'aurais plutot espéré un truc intégré à maven. Genre tu met ta librairie dans maven, le jour ou t'as des security issue, tu notifie aussi dans maven tes security issue et du coup un plugin maven pourrait les lister. Après tout, si tu fais l'effort de mettre tes jar dans un repo maven public,ça devrait pas te couter plus de faire aussi l'effort d'y mettre tes notifications de sécurités

    De la même manière que t'as un .pom avec des <licence> dedans, tu pourrais avoir un .issue avec des <security-issue> dedans

    Le problème avec sonatype insight c'est que non seulement il faut passer à la caisse (soit), mais leur politique de prix est tout sauf transparente :/
    Tchize (Чиз) faq java, cours java, javadoc. Pensez à et

  19. #19
    Invité de passage
    Inscrit en
    janvier 2008
    Messages
    3
    Détails du profil
    Informations forums :
    Inscription : janvier 2008
    Messages : 3
    Points : 4
    Points
    4

    Par défaut

    Citation Envoyé par tchize_ Voir le message
    oui, mais j'aurais plutot espéré un truc intégré à maven. Genre tu met ta librairie dans maven, le jour ou t'as des security issue, tu notifie aussi dans maven tes security issue et du coup un plugin maven pourrait les lister. Après tout, si tu fais l'effort de mettre tes jar dans un repo maven public,ça devrait pas te couter plus de faire aussi l'effort d'y mettre tes notifications de sécurités
    c'est 1 bonne idée; 1 truc collaboratif en sorte; il faudrait qu'il y aie aussi une sorte de niveau de confiance ou des super utilisateurs pour valider; comme wikipedia...
    faudrait 1 plugin dans maven et dans nexus aussi d'ailleurs...

    que le tarif de insight soit pas transparent, c'est souvent le cas dans les services dans le monde logiciel (mis à part les licences logicielles)

  20. #20

    Homme Profil pro
    Développeur Java
    Inscrit en
    juin 2011
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2011
    Messages : 2
    Points : -1
    Points
    -1

    Par défaut tous sur le Cloud !!!

    Ce sera surement mieux sur le cloud avec microsoft ....

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •