Alpha-Omega et SBOM pour sécuriser la supply chain logicielle
L’OpenSSF Day Europe de Dublin a notamment mis la focale sur la vulnérabilité de la supply chain logicielle. L'initiative Alpha-Omega Project, soutenue par Google et Microsoft, vise à pallier au manque de ressources des projets open source les plus critiques. Alors que d’autres spécialistes travaillent sur la standardisation du Software Bill of Materials (SBOM), afin d'encourager l’adoption de cette pratique à large échelle.
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 composent cette chaîne peuvent cacher des failles vectrices 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èque 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 maintenue 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 soutenue 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 a suivi en ligne, une conférence était justement 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 accomplissements de cette initiative qui bénéficie de l’ambitieux plan de financement de la Linux Foundation et de l'OpenSSF, qui prévoit 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 s’étoffer. L’autre versant, Omega, consiste à faire appel à des méthodes et des outils automatisés pour identifier les vulnérabilités de sécurité critiques de quelque 10’000 projets open source. «Nous nettoyons l'océan, si l’on peut dire, en repérant des failles zero-day puis en soutenant les développeurs qui maintiennent un projet pour les corriger», a expliqué Michael Scovetta.
Parmi les projets qui ont déjà bénéficié de 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 aussi été déployés pour améliorer le processus de publication des patchs et automatiser la détection de failles. 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 accrus 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 serait déjà nécessaire de 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 logiciels.
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, a souligné la spécialiste. Avant de faire remarquer que le challenge réside actuellement dans le besoin de standardiser ce type de documentation dans le but de disposer non seulement de la liste des composants mais aussi de toutes les dépendances qu’il existe entre eux. Le défi principal consiste à mettre au point des modèles d'inventaire à la fois simples et précis, afin de stimuler leur adoption à large échelle par les entreprises. «Nous n’en sommes pas encore tout à fait là», selon Kate Stewart, car 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 mentionné 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.
