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


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 :
[LIST][*]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é...