Google propose d'établir de nouvelles règles pour améliorer la sécurité open source

La sécurité des logiciels open source a attiré l'attention de l'industrie, mais les solutions nécessitent un consensus sur les défis et une coopération dans la mise en œuvre.

Le problème est complexe et il y a de nombreuses facettes à couvrir, de la chaîne d'approvisionnement, de la gestion des dépendances, de l'identité, entre autres. Pour ce faire, Google a récemment publié un cadre («Know, Prevent, Fix») qui explique comment l'industrie peut penser aux vulnérabilités dans l'open source et aux domaines spécifiques qui doivent être traités en premier.

Google explique ses raisons:

«En raison des é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 du point de vue de la sécurité, car tous les codes et dépendances sont ouverts et disponibles pour inspection et vérification. Et bien que cela soit généralement vrai, on suppose que les gens effectuent 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 des dépendances plutôt que des logiciels propriétaires et provient d'un plus large éventail de fournisseurs; le nombre d'entités indépendantes auxquelles on peut faire confiance peut être très important. Cela rend extrêmement difficile de comprendre comment l'open source est utilisé dans les produits et quelles vulnérabilités peuvent être pertinentes. Il n'y a pas non plus de garantie que ce qui est construit correspondra au code source.

Dans le cadre proposé par Google, il est suggéré de diviser cette difficulté en trois domaines de problèmes largement indépendants, chacun avec des objectifs spécifiques:

Connaissez les vulnérabilités de votre logiciel

Connaître vos vulnérabilités logicielles est plus difficile que vous ne le pensez pour de nombreuses raisons. Oui ok des mécanismes existent pour signaler les vulnérabilités, on ne sait pas si elles affectent vraiment les versions spécifiques du logiciel que vous utilisez:

  • Objectif: 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 le logiciel est affecté, et savoir quand il a été corrigé entraîne des correctifs précis et opportuns (et une fenêtre étroite pour une exploitation potentielle). Idéalement, ce flux de travail de classification 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 affectant votre logiciel peut changer constamment - certaines sont corrigées et d'autres sont ajoutées.
  • Objectif: schéma standard pour les bases de données de vulnérabilités L'infrastructure et les normes 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 à des outils communs de s'exécuter sur plusieurs bases de données de vulnérabilités et de simplifier la tâche de suivi, en particulier lorsque les vulnérabilités traversent plusieurs langues ou sous-systèmes.

Évitez d'ajouter de nouvelles vulnérabilités

L'idéal serait d'éviter la création de vulnérabilités Et si les outils de test et d'analyse peuvent aider, la prévention sera toujours un sujet difficile.

Ici, Google propose de se concentrer sur deux aspects spécifiques:

  • Comprendre les risques lors du choix d'une nouvelle dépendance
  • Améliorez les processus de développement de logiciels critiques

Réparer ou supprimer les vulnérabilités

Google reconnaît que le problème général de la réparation dépasse sa compétence, mais l'éditeur estime que les acteurs peuvent faire beaucoup plus pour résoudre le problème spécifique pour gérer les vulnérabilités dans les dépendances.

Il mentionne également: 

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

«Une option, bien sûr, est de corriger la vulnérabilité directement. Si vous pouvez le faire de manière rétrocompatible, la solution est accessible à tous. Mais le défi est qu'il est peu probable que vous ayez l'expérience du problème ou 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 divulguer la vulnérabilité.

source: https://security.googleblog.com


Un commentaire, laissez le vôtre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données : AB Internet Networks 2008 SL
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.

  1.   José Antonio dit

    L'original en anglais dit:

    Ici, nous nous concentrons sur deux aspects spécifiques:

    - Comprendre les risques lors du choix d'une nouvelle dépendance

    - Amélioration des processus de développement des logiciels critiques

    La version "LinuxAdictos" dit:

    Ici, Google propose de se concentrer sur deux aspects spécifiques:

    - Comprendre les risques lors du choix d'une nouvelle addiction.

    - Amélioration des processus de développement logiciel critiques

    Une nouvelle addiction!?