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 :
- 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 ? 
Envoyé par Stéphane le calme
