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

Logiciels Libres & Open Source Discussion :

Google propose l'établissement de nouvelles règles pour améliorer la sécurité des logiciels open source


Sujet :

Logiciels Libres & Open Source

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    8 384
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 8 384
    Points : 196 431
    Points
    196 431
    Par défaut Google propose l'établissement de nouvelles règles pour améliorer la sécurité des logiciels open source
    Google propose l'établissement de nouvelles règles pour améliorer la sécurité des logiciels open source
    et donne des pistes de réflexion dans ce sens

    La sécurité des logiciels open source a, à juste titre, attiré l’attention de l’industrie, mais les solutions nécessitent un consensus sur les défis et la coopération dans l’exécution. Le problème est complexe et il y a de nombreuses facettes à couvrir: la chaîne d'approvisionnement, la gestion des dépendances, l'identité et la construction de pipelines. Les solutions viennent plus rapidement lorsque le problème est bien défini; Google propose un framework («Know, Prevent, Fix») expliquant comment le secteur peut réfléchir aux vulnérabilités dans les domaines open source et concrets à traiter en premier, notamment:
    • Consensus sur les métadonnées et les normes d'identité: nous avons besoin d'un consensus sur les principes fondamentaux pour aborder ces problèmes complexes en tant qu'industrie. Les accords sur les détails des métadonnées et les identités permettront l'automatisation, réduiront l'effort requis pour mettre à jour le logiciel et minimiseront l'impact des vulnérabilités.
    • Transparence et révision accrues pour les logiciels critiques: pour les logiciels critiques pour la sécurité, nous devons nous entendre sur des processus de développement qui garantissent un examen suffisant, évitent les changements unilatéraux et conduisent de manière transparente à des versions officielles bien définies et vérifiables.

    Et Google d’expliquer ses motivations :

    « En raison d'événements récents, le monde du logiciel a acquis une compréhension plus approfondie du risque réel d'attaques de la chaîne d'approvisionnement. Les logiciels open source devraient être moins risqués sur le plan de la sécurité, car tout le code et les dépendances sont ouverts et disponibles pour inspection et vérification. Et bien que cela soit généralement vrai, cela suppose que les gens font réellement ce travail d’inspection. Avec autant de dépendances, il est impossible de toutes les surveiller et de nombreux packages open source ne sont pas bien entretenus.

    « Il est courant pour un programme de dépendre, directement ou indirectement, de milliers de packages et de bibliothèques. Par exemple, Kubernetes dépend désormais d'environ 1000 packages. L'open source utilise probablement plus les dépendances que les logiciels propriétaires et provenant d'un plus large éventail de fournisseurs; le nombre d'entités distinctes auxquelles il faut faire confiance peut être très élevé. Cela rend extrêmement difficile de comprendre comment l'open source est utilisé dans les produits et quelles vulnérabilités pourraient être pertinentes. Il n'y a pas non plus de garantie que ce qui est construit correspond au code source.

    « Prendre du recul est nécessaire. En effet, bien que les attaques de la chaîne d'approvisionnement soient un risque, la grande majorité des vulnérabilités sont des erreurs banales et involontaires (honnêtes commises par des développeurs bien intentionnés). De plus, les acteurs malveillants sont plus susceptibles d’exploiter les vulnérabilités connues que de trouver les leurs : c’est simplement plus facile. En tant que tel, nous devons nous concentrer sur la réalisation de changements fondamentaux pour remédier à la majorité des vulnérabilités, car cela permettra à l'ensemble du secteur de progresser dans la résolution des cas complexes, y compris les attaques de la chaîne d'approvisionnement.

    « Peu d'entreprises peuvent vérifier tous les packages qu'elles utilisent, sans parler de toutes les mises à jour de ces packages. Dans le paysage actuel, le suivi de ces packages nécessite une quantité non négligeable d'infrastructure et un effort manuel important. Chez Google, nous disposons de ces ressources et faisons des efforts extraordinaires pour gérer les packages Open Source que nous utilisons, notamment en conservant un dépôt privé de tous les packages Open Source que nous utilisons en interne, et il est toujours difficile de suivre toutes les mises à jour. Le flux de mises à jour est décourageant. Une partie essentielle de toute solution sera davantage d'automatisation, et ce sera un thème clé pour notre travail de sécurité open source en 2021 et au-delà.

    « Parce qu'il s'agit d'un problème complexe qui nécessite la coopération de l'industrie, notre objectif ici est de centrer la conversation autour d'objectifs concrets. Google a cofondé l'OpenSSF pour être le point focal de cette collaboration, mais pour progresser, nous avons besoin de la participation de l'ensemble du secteur et d'un accord sur la nature des problèmes et la manière de les résoudre. Pour lancer la discussion, nous présentons une façon de définir ce problème et un ensemble d'objectifs concrets qui, nous l'espérons, accéléreront les solutions à l'échelle de l'industrie ».

    Nom : google.png
Affichages : 14316
Taille : 51,9 Ko

    Le framework proposé par Google

    L'entreprise suggère de partitionner cette difficulté comme trois domaines problématiques largement indépendants, chacun avec des objectifs concrets :
    • Connaître (know) les vulnérabilités de votre logiciel
    • Empêcher (prevent) l'ajout de nouvelles vulnérabilités, et
    • Corriger (fix) ou supprimer les vulnérabilités.

    Connaître les vulnérabilités de votre logiciel

    Connaître les vulnérabilités de votre logiciel est plus difficile que prévu pour de nombreuses raisons. Bien qu'il existe des mécanismes pour signaler les vulnérabilités, il est difficile de savoir si elles affectent réellement les versions spécifiques des logiciels que vous utilisez :
    • Objectif: des données de vulnérabilité précises Premièrement, il est essentiel de capturer des métadonnées de vulnérabilité précises à partir de toutes les sources de données disponibles. Par exemple, savoir quelle version a introduit une vulnérabilité permet de déterminer si un logiciel est affecté, et savoir quand il a été corrigé se traduit par des correctifs précis et opportuns (et une fenêtre réduite pour l'exploitation potentielle). Idéalement, ce flux de travail de tri devrait être automatisé.

      Deuxièmement, la plupart des vulnérabilités se trouvent dans vos dépendances, plutôt que dans le code que vous écrivez ou contrôlez directement. Ainsi, même lorsque votre code ne change pas, le paysage des vulnérabilités qui affectent votre logiciel peut être en constante évolution : certaines sont corrigées et d'autres sont ajoutées.
    • Objectif: schéma standard pour les bases de données de vulnérabilité Les normes d'infrastructure et de l'industrie sont nécessaires pour suivre et maintenir les vulnérabilités open source, comprendre leurs conséquences et gérer leurs atténuations. Un schéma de vulnérabilité standard permettrait aux outils communs de fonctionner sur plusieurs bases de données de vulnérabilité et de simplifier la tâche de suivi, en particulier lorsque les vulnérabilités touchent plusieurs langages ou sous-systèmes.

    Empêcher l'ajout de nouvelles vulnérabilités

    Il serait idéal pour empêcher la création de vulnérabilités, et bien que les outils de test et d'analyse puissent aider, la prévention sera toujours un problème difficile. Ici, Google propose de se concentrer sur deux aspects spécifiques:
    • Comprendre les risques lors du choix d'une nouvelle dépendance
    • Amélioration des processus de développement pour les logiciels critiques

    Corriger ou supprimer des vulnérabilités

    Google reconnaît que le problème général de la correction des vulnérabilités dépasse son champ d'application, mais l'éditeur estime que les acteurs peuvent faire beaucoup plus pour s'occuper du problème spécifique de la gestion des vulnérabilités dans les dépendances logicielles.

    « Aujourd'hui, il y a peu d'aide sur ce front, mais à mesure que nous améliorons la précision, il devient intéressant d'investir dans de nouveaux processus et outillages.

    « Une option bien sûr est de corriger la vulnérabilité directement. Si vous pouvez le faire d'une manière rétrocompatible, le correctif est disponible pour tout le monde. Mais le défi est qu'il est peu probable que vous ayez une expertise sur le problème ni la capacité directe d'apporter des changements. La correction d'une vulnérabilité suppose également que les responsables de la maintenance du logiciel sont conscients du problème et disposent des connaissances et des ressources nécessaires pour la divulgation de la vulnérabilité.

    « Inversement, si vous supprimez simplement la dépendance qui contient la vulnérabilité, elle est corrigée pour vous et ceux qui importent ou utilisent votre logiciel, mais pour personne d'autre. C'est un changement qui est sous votre contrôle direct.

    « Ces scénarios représentent les deux extrémités de la chaîne de dépendances entre votre logiciel et la vulnérabilité, mais en pratique, il peut y avoir de nombreux packages intermédiaires. L'espoir général est que quelqu'un le long de cette chaîne de dépendances résoudra le problème. Malheureusement, réparer un lien ne suffit pas : chaque maillon de la chaîne de dépendance entre vous et la vulnérabilité doit être mis à jour avant que votre logiciel ne soit corrigé. Chaque lien doit inclure la version fixe de l'élément en dessous pour purger la vulnérabilité. Ainsi, les mises à jour doivent être effectuées de bas en haut, à moins que vous ne puissiez éliminer complètement la dépendance, ce qui est rarement possible - mais c'est la meilleure solution quand c'est le cas ».

    Source : Google

    Et vous ?

    Que pensez-vous des propositions de Google ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre chevronné Avatar de denisys
    Profil pro
    Développeur informatique
    Inscrit en
    Mai 2002
    Messages
    1 122
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Mai 2002
    Messages : 1 122
    Points : 1 924
    Points
    1 924
    Par défaut
    Le framework proposé par Google ...
    C’est gratuit ???
    Pour combien de temps ???
    Ils ont repris quel code source : Open Source, pour réaliser leur framework ???
    A qui ???
    Ne pas savoir n’est pas une faute si l’on cherche à combler ses lacunes.

    "Il n'y a pas d'obstacles infranchissables , il y a des volontés plus ou moins énergiques voilà tous" Jules Vernes

  3. #3
    Membre actif Avatar de fmartini
    Homme Profil pro
    Ingénieur en Cybersécurité
    Inscrit en
    Mai 2013
    Messages
    59
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur en Cybersécurité
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mai 2013
    Messages : 59
    Points : 296
    Points
    296
    Par défaut
    L'entreprise suggère de partitionner cette difficulté comme trois domaines problématiques largement indépendants, chacun avec des objectifs concrets :

    Connaître (know) les vulnérabilités de votre logiciel
    Empêcher (prevent) l'ajout de nouvelles vulnérabilités, et
    Corriger (fix) ou supprimer les vulnérabilités.
    Que pensez-vous des propositions de Google ?
    Sincèrement, là, ils ont rien inventé pour le coup. C'est juste un acte marketing pour faire ENCORE, parlé d’eux. Pour 'améliorer' leurs images dans la communauté Open Source.

  4. #4
    Membre éprouvé
    Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2009
    Messages
    552
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Mars 2009
    Messages : 552
    Points : 1 060
    Points
    1 060
    Par défaut
    Citation Envoyé par Stéphane le calme Voir le message
    [B][SIZE=4]
    Deuxièmement, la plupart des vulnérabilités se trouvent dans vos dépendances, plutôt que dans le code que vous écrivez ou contrôlez directement.
    Quand on ne procède pas à un audit sur son propre code, qu'est-ce qu'on en sait?

    Le fait est que la plupart des vulnérabilités connues se trouvent dans ses dépendances. Celles dans son propre code et autour de celui-ci sont souvent inconnues (surtout si on ne procède jamais à des audits).

    Que pensez-vous des propositions de Google ?
    Je trouve qu'il a une tendance générale à se focaliser sur ce qui est chiffrable, traçable et automatisable (contrôle des versions des dépendances, analyse statique de code,...) qui tend à faire oublier les fondamentaux (analyse et gestion des risques).

    Si ça conduit les développeurs à réinventer la roue pour sortir des radars et les décideurs à paniquer face au nombre de failles dans les bibliothèques opensource, nous n'aurons pas fait de grand progrès!

    L'actualité récente ne montre pas des carnages liés à la non mise à jour d'une bibliothèque de test unitaire malgré une mise en garde de github & co (la pertinence de certaines alertes pose question). L'actualité devrait alerter sur les effets du laxisme en matière de gestion des identités et de traçabilité pour les opérations de construction et de déploiement d'applicatif.

Discussions similaires

  1. Réponses: 0
    Dernier message: 04/08/2020, 18h18
  2. Google introduit de nouvelles règles pour les pages AMP
    Par Coriolan dans le forum Général Conception Web
    Réponses: 5
    Dernier message: 21/11/2017, 10h15
  3. Faut-il avoir recours à la publicité pour soutenir le financement des projets open source ?
    Par Michael Guilloux dans le forum Logiciels Libres & Open Source
    Réponses: 22
    Dernier message: 14/09/2017, 11h05
  4. Réponses: 29
    Dernier message: 27/08/2015, 10h38
  5. Réponses: 10
    Dernier message: 12/11/2009, 11h20

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