Pour répondre à la préoccupation des développeurs qui s’inquiètent de la sécurité de la supply chain des logiciels open source dont ils dépendent fortement, Google prévoit de mettre à disposition son propre référentiel de composants open source sécurisé via un service payant. Appelé Assured Open Source Software (Assured OSS), ce service propose des paquets open source communs construits à partir du code source pour lequel la provenance du code et de ses dépendances a été vérifiée, et qui ont été examinés et testés pour détecter les vulnérabilités. Les paquets résultants contiendront des métadonnées riches, conformes au récent cadre SLSA (Supply chain Levels for Software Artifacts), et seront signés numériquement par Google.

Selon Eric Brewer, vice-président de l'infrastructure de Google Cloud, la firme disposent déjà de nombreux composants open source testés pour son propre pipeline de développement, de sorte que les bases du service Assured OSS sont déjà en place. Annoncé hier, il ne sera d’abord disponible que sous forme de test pour des clients sélectionnés et devrait entrer dans une phase beta public au troisième trimestre 2022. La tarification n'a pas encore été décidée, mais ce service payant pourra alléger les coûts d'infrastructure associés à la construction et à l'hébergement des paquets ainsi qu'aux tests de sécurité, lesquels comprennent des tests automatisés de fuzz avec plus de 100 000 cœurs. Dans un premier temps, le service proposera une série d'environ 500 paquets Java et Python utilisés par Google, mais il sera étendu plus tard à d'autres langages de programmation. Les clients pourront également soumettre toutes briques open source dont ils dépendent afin qu'il soit ajouté et géré par le biais du référentiel et qu'il bénéficie de la même garantie de sécurité que les paquets existants.

Faciliter la maintenance des composants logiciel en local

L'approche de Google correspond à ce que toutes les entreprises qui développent des logiciels devraient déjà faire pour éviter certains risques liés à la supply chain à savoir conserver des copies en local des composants qu'elles utilisent dans leurs référentiels locaux au lieu de les extraire directement des référentiels publics. Cette pratique leur permettrait de disposer d'un tampon au cas où l'un des paquets ou ses dépendances serait compromis et empoisonné par un code malveillant. Cependant, elle peut aussi entraîner des retards dans l'application des correctifs si elle n'est pas gérée correctement, car les versions internes des paquets peuvent devenir obsolètes si les correctifs de sécurité en amont ne sont pas régulièrement intégrés.

Ce qui n'est pas toujours facile, si ces correctifs de sécurité ne concernent que les dernières versions qui apportent aussi des changements de fonctionnalités majeurs susceptibles de casser les applications et de nécessiter d'importants efforts de réingénierie. Depuis un certain temps, plusieurs études montrent que les applications d'entreprise utilisent des versions obsolètes et vulnérables de composants open-source dans leurs applications. Ce fût le cas, par exemple, de la vulnérabilité critique et très médiatisée de Log4Shell, découverte en décembre dans la bibliothèque de journalisation Java log4j, très couramment utilisée. Trois mois plus tard, près de 40 % des téléchargements de log4j2 à partir du référentiel Maven Central délivraient toujours des versions vulnérables de la bibliothèque.

Corrections des anciennes versions du code open source

Google prévoit de résoudre certains de ces problèmes en rétablissant les correctifs de sécurité dans les anciennes versions des paquets concernés, même si le responsable initial ne le fait pas. « Si le propriétaire de paquet apporte un changement radical dans une nouvelle version, son adoption ne sera pas facilitée pour la plupart des utilisateurs », a expliqué M. Brewer. « Dans ce genre de situation, les corrections de sécurité que l’on peut apporter à l'ancienne version en cours d’utilisation comme à la dernière version qui sera utilisée de préférence à l'avenir, peuvent avoir une certaine importance », a-t-il ajouté. Cela dit, il y aura toujours un délai entre le moment où la version récente est publiée et celui où une copie vérifiée et signée par Google sera disponible dans le référentiel Assured OSS, tout simplement parce qu’il faut un certain temps pour effectuer les tests de sécurité et examiner les modifications du code. Mais Eric Brewer espère que ce décalage sera de plus en plus court à mesure que le processus sera automatisé. « Cela fait partie du service, car il ne fournit pas la copie en amont », a-t-il déclaré. « Cette copie arrive avec une certaine latence et une certaine révision et, dans certains cas, cette latence peut être significative, parce que nous ne sommes pas sûrs de la dernière version. Inversement, s'il s'agit d'un correctif de sécurité minime, nous essaierons probablement de choisir celui avec la plus faible latence ».

Mais ce processus est à double sens, car les équipes de développement de Google et les chercheurs en vulnérabilités trouvent régulièrement des failles de sécurité dans les logiciels open source et créent des correctifs pour celles-ci. Dans ce cas, la version de Google d'un paquet peut recevoir les correctifs pour une vulnérabilité découverte en interne avant les versions officielles, parce qu'il faut généralement un certain temps pour que les correctifs soient acceptés par le projet en amont. Google est l'un des plus grands contributeurs aux projets de logiciels open source et ses chercheurs ont déjà découvert plus de 16 000 vulnérabilités à ce jour. De plus, Google s'associera à l’entreprise de sécurité pour développeurs Snyk. En particulier, Assured OSS sera intégré à la plate-forme et aux outils de Snyk, ainsi qu'aux renseignements sur les vulnérabilités de l’éditeur. Des actions déclenchées et des recommandations de remédiation seront disponibles pour les clients communs dans les outils du cycle de vie du développement logiciel de Google Cloud.