Alpha-Omega et SBOM pour sécuriser la supply chain logicielle

La sécurisation de la supply chain logicielle est un enjeu crucial pour la cybersécurité des entreprises. Aussi bien les outils propriétaires que le code open source qui compose cette chaîne peut cacher des failles vectorielles d’attaques informatiques. Après plusieurs attaques à la supply chain logicielle qui avait déjà marqué les esprits (SolarWinds, Kaseya, Codecov), La faille zero-day des plus critiques Log4Shell a remis sur le devant de la scène, en décembre 2021, la fragilité potentielle de certaines bibliothèques open source massivement utilisées dans le développement d’applications d’entreprise.

Dans le cas de Log4Shell, on apprenait à l’époque que le projet incriminé (la bibliothèque de journalisation Apache Log4j) n’était maintenu que par trois bénévoles. Les appels invitant les géants de la tech à s’engager davantage en faveur de la sécurisation des outils open source, dont ils dépendent également, se sont alors multipliés… et ont manifestement été entendus. Preuve en est l’initiative Alpha-Omega Project, chapeautée par l’Open Source Security Foundation (OpenSSF) et soutune par Google et Microsoft, aussi bien techniquement que financièrement (5 millions de dollars d’investissement initial).

L’aide concrète de l’Alpha-Omega Project

A l’occasion de l’OpenSSF Day Europe, qui s’est tenu mardi 13 septembre à Dublin et que la rédaction d’un suivi en ligne, une conférence était précisément consacrée à l’Alpha-Omega Project. Michael Winser, Product Manager chez Google, et Michael Scovetta, Principal Security PM Manager chez Microsoft, ont parlé des objectifs et réalisations de cette initiative qui en a bénéficié le plan de financement ambitieux de la Linux Foundation et de l’OpenSSF, qui prévoyait un investissement échelonné d’un total d’environ 150 millions de dollars.

D’un côté, le volet Alpha vient en aide aux projets open source les plus critiques, utilisés massivement, pour les aider à améliorer leur sécurité. Le soutien est financier mais aussi technique, l’équipe Alpha-Omega cherche d’ailleurs des talents pour étoffer. L’autre face, Omega, consiste à faire appel à des méthodes et outils automatisés pour identifier les failles de sécurité de quelque 10 000 projets open source. « Nous nettoyons l’océan, si l’on peut dire, en représentant des failles zero-day puis en suivant les développeurs qui maintiennent un projet pour les corriger », explique Michael Scovetta.

Parmi les projets qui ont déjà fourni cette aide, mentionnons Node.js : l’OpenSSF a investi 300’000 dollars pour sécuriser ce framework événementiel pour applications réseau en JavaScript. Depuis avril 2022, l’équipe Alpha-Omega a décelé et contribué à corriger plus de 20 vulnérabilités. Des efforts ont également été faits pour améliorer le processus de publication des correctifs et automatiser la détection des pannes. En outre, une solution de permissions d’accès aux modules de Node.js est testée. L’Alpha-Omega Project a par ailleurs l’intention de soutenir la Python Software Foundation à hauteur de 400’000 dollars. Il s’agira entre autres de recruter un responsable de la sécurité et de compléter un audit de PyPI, dépôt tiers officiel du langage Python.

L’objectif d’un Software Bill of Materials standardisé

En parallèle aux efforts accumulés visant à sécuriser les composants open source là où ils sont créés et maintenus, des pratiques doivent se mettre en place pour que les entreprises utilisatrices puissent avoir toutes les cartes en main quand des vulnérabilités sont découvertes. Il faudrait déjà savoir précisément quels projets composent une supply chain logicielle pour agir sur un bout de code vulnérable. « La transparence, c’est la clé pour améliorer la sécurité de la supply chain », a résumé Kate Stewart lors de sa présentation à l’OpenSSF Day Europe. Vice President of Dependable Embedded Systems à la Fondation Linux, elle a présenté l’intérêt de disposer d’un Software Bill of Materials (SBOM), à savoir un inventaire formel des différentes briques utilisées dans le flux de création de softwareilles.

Un SBOM se doit d’être complet, en intégrant les composants, bibliothèques et modules open source mais aussi ceux d’outils propriétaires, gratuits ou payants, à la soirée du spécialiste. Avant de faire remarquer que le défi réside actuellement dans le besoin de standardiser ce type de documentation dans le mais de supprimer non seulement la liste des composants mais aussi de toutes les dépendances qu’il existe entre eux. L’enjeu principal est de mettre en place des modèles d’inventaire à la fois simples et précis, afin de stimuler leur adoption à grande échelle par les entreprises. « Nous n’en sommes pas encore tout à fait là », selon Kate Stewart, parce qu’il manque encore les outils permettant d’atteindre cet objectif. Une équipe dédiée de l’OpenSSF, également soutenue par le plan de financement évoqué précédemment, travaille à la création de ces modèles et pratiques qui seraient accessibles à toute entreprise. Notamment en cherchant à développer des outils open source « sans friction » qui génèrent des SBOM standardisés.

Leave a Comment