arrow - Fotolia

Dépendances open source : Google veut automatiser les scans de vulnérabilités

L’équipe de sécurité commence par proposer OSV-Scanner, un outil open de scan de vulnérabilités s’appuyant sur sa base de données OSV. Il est d’ores et déjà utilisé par l’OpenSSF.

Le 13 décembre, l’équipe de sécurité de Google a présenté OSV-Scanner, un outil écrit en Go pour trouver des vulnérabilités existantes affectant des projets open source. La page GitHub d’OSV-Scanner le décrit comme le « front-end officiel » d’OSV (Open Source Vulnerabilities).

OSV-Scanner, le « front-end » d’une métabase de données de vulnérabilités

Pour rappel, OSV a été lancée en février 2021. Il s’agit d’une base de données open source pensée pour rassembler l’ensemble des informations sur les vulnérabilités affectant des projets libres et, si possible, les correctifs et les moyens d’y remédier.

Plus précisément, OSV a été étudiée pour réduire le travail nécessaire aux gestionnaires des paquets open source au moment de publier une vulnérabilité. Il s’agit également d’améliorer la précision des recherches sur les vulnérabilités en faisant en sorte de proposer une interface de recherche efficace.

Pour ce faire, l’équipe de Google a mis au point une architecture capable d’automatiser la remontée et la liaison des informations de sécurité dans OSV.

Base de données OSV
L'architecture qui motorise la base de données de vulnérabilités OSV.

Elle a aussi imaginé un schéma de données pour normaliser les données envoyées par les gestionnaires de paquets. Il permet de lier une CVE à un nom de paquet et des versions. Après un test mené auprès de la communauté OSS-Fuzz, l’équipe a agrégé et indexé les vulnérabilités en provenance de plusieurs bases de données ayant adopté le schéma OSV. Au total, la base de données OSV liste et documente pas moins de 39 000 vulnérabilités.

Pour interroger la base de données, Google a mis à disposition un moteur de recherche accessible via une page Web et une API. OSV-Scanner est une « étape supplémentaire » dans la diffusion de ce dispositif. Ici, il s’agit d’utiliser une interface homme-machine pouvant retourner une réponse lisible par un humain, soit sous forme de texte, soit dans un format JSON, mais également d’automatiser la procédure de scan.

Google entend suivre les directives du gouvernement américain. Cette phase d’automatisation des recherches de vulnérabilités est une des recommandations inscrites dans l’US Executive Order consacré à la cybersécurité, publié en mai 2021.

En l’occurrence, l’identification manuelle des dépendances logicielles peut s’avérer complexe, voire impossible. Il n’est pas rare qu’une application s’appuie sur plusieurs centaines de dépendances open source. Trouver les vulnérabilités qui affectent les dépendances et les versions des composants applicatifs demeure un parcours du combattant.

Dans le cadre de son rapport annuel sur la sécurité et les risques de l’open source, l’éditeur Synopsis a audité plus de 2 400 bases de code en 2021. Pas moins de 78 % du code étudié était open source et 81 % des bases contenaient au moins une vulnérabilité. Une très large portion (85 %) du code open source n’avait pas été mise à jour depuis plus de quatre ans. Environ 29 % des bases auditées présentaient au moins une des plus grosses vulnérabilités CVE identifiées dans l’année. Une seule CVE peut avoir des répercussions considérables. Selon Synopsis, la faille Log4Shell aurait pu impacter plus de 7 000 projets open source utilisant Log4j 2.

Pour tenter d’accélérer la détection et in fine la remédiation de ces potentielles failles, OSV-Scanner collecte une liste de dépendances et leurs versions, avant d’essayer de les faire correspondre avec la liste enregistrée dans la base de données OSV via API. Cette liste peut être constituée en « pointant » le scanner vers le fichier racine d’un projet ou en examinant chacun des fichiers de manifeste. Pour effectuer cette analyse, OSV-Scanner scrute les manifestes Lockfiles, les fichiers SBOM SPDX et CycloneDX, ainsi que les hashs des commits GitHub.

Avant de proposer cet outil, l’équipe sécurité de Google voulait s’assurer d’avoir une large couverture des écosystèmes de programmation. La base de données OSV prend en charge 16 d’entre eux. La majorité des vulnérabilités référencées affectent le kernel Linux (27,4 %), ses distributions Debian (23,2 %), Alpine (7,9 %) et Android (1,3 %). OSV inclut également les avertissements concernant des paquets npm, Pypi, Maven, Go ou encore RubyGems.

L’équipe de sécurité de Google a réussi à convaincre les mainteneurs des bases de données de vulnérabilités de GitHub, de Pypi, de Go, de Rust, de Global Security, d’OSS-Fuzz et de LoopBack. Ils ont tous adopté le fameux schéma OSV.

Renforcer l’automatisation des scans et s’attaquer aux librairies C/C++

OSV-Scanner permet donc d’identifier les vulnérabilités dans des projets majoritairement écrits en Go, Java, Python, JavaScript et Ruby. La couverture peut encore être améliorée, selon les chercheurs en sécurité de Google. « L’un des écosystèmes les plus complexes en matière de gestion de vulnérabilités demeure C/C++, parce qu’il n’y a pas de gestionnaires de paquets canoniques pour les logiciels écrits dans ces langages », écrivent-ils. Il faut encore nourrir OSV de métadonnées concernant les vulnérabilités affectant les composants C/C++.

Un autre objectif est de fournir un moyen d’enclencher automatiquement ce scan. L’équipe a d’abord développé un flux CI via GitHub Actions. OSV-Scanner est maintenant intégré au vérificateur du projet Security Scorecard de l’OpenSSF (Open Source Security Foundation). Plus de 1,2 million de dépôts GitHub sont régulièrement analysés à l’aide de cette solution, selon Google. Voilà qui devrait faciliter l’adoption d’OSV-Scanner.

Plus tard, l’équipe responsable du projet entend analyser les graphes d’appel, des graphes de flux de contrôle qui représentent les relations d’appel entre les sous-programmes d’une application, afin de « pouvoir remédier automatiquement aux vulnérabilités en suggérant des changements de version minimaux, qui ont un impact maximal » et de créer les déclarations VEX.

Pour approfondir sur Gestion des vulnérabilités et des correctifs (patchs)

Close