Google a proposé un cadre appelé SLSA pour faire face aux attaques de la chaîne d’approvisionnement, un risque de sécurité illustré par la récente compromission de la plate-forme de surveillance informatique SolarWinds Orion.

SLSA – abréviation de Niveaux de la chaîne d’approvisionnement pour les artefacts logiciels et prononcé « salsa » pour ceux qui sont enclins à ajouter des voyelles de commodité – aspire à fournir des conseils de sécurité et une assurance programmatique pour aider à défendre le processus de création et de déploiement du logiciel.

« L’objectif de SLSA est d’améliorer l’état du secteur, en particulier l’open source, pour se défendre contre les menaces d’intégrité les plus urgentes », ont déclaré Kim Lewandowski, chef de produit Google, et Mark Lodato, ingénieur logiciel Google, dans un article de blog mercredi. « Avec SLSA, les consommateurs peuvent faire des choix éclairés sur la posture de sécurité du logiciel qu’ils utilisent. »

Les attaques de la chaîne d’approvisionnement – qui tentent d’exploiter les faiblesses du pipeline de création et de distribution de logiciels – ont récemment augmenté. Au-delà de Incident de SolarWinds et l’exploitation des vulnérabilités Jambes de force Apache, il y a eu de nombreuses attaques contre les registres de progiciels comme npm, PyPI, RubyGems et Maven Central sur lesquels les développeurs de bibliothèques de code interne s’appuient pour prendre en charge des applications complexes.

Selon le business de la sécurité Sonatype [PDF], les attaques contre les projets open source ont augmenté de 430 % en 2020. L’une des diverses raisons plausibles est que la compromission d’une dépendance dans une bibliothèque largement utilisée garantit une large diffusion des logiciels malveillants. Comme indiqué dans un document de recherche de la TU Darmstadt en 2019, les cinq principaux packages npm en 2018 « atteignent chacun entre 134 774 et 166 086 autres packages, ce qui en fait une cible extrêmement attrayante pour les attaquants ».

Manger sa propre nourriture pour chien

SLSA est basé sur le processus de sécurité interne de Google, « Autorisation binaire pour Borg« , utilisé au sein du géant de la publicité depuis plus de huit ans et actuellement obligatoire pour toute charge de travail de production. Il se compose de normes (règles), d’accréditation (par laquelle la conformité aux normes peut être établie) et de contrôles techniques (métadonnées signées pour les cadres de politique automatisés) .

Actuellement, SLSA est un conseil de sécurité plus ou moins utile. Mais l’espoir est que cela devienne quelque chose de plus que cela.

« Dans sa forme finale, SLSA différera d’une liste de meilleures pratiques dans son applicabilité : il prendra en charge la création automatique de métadonnées vérifiables qui peuvent être introduites dans les moteurs de politique pour donner une « certification SLSA » à un package ou à une plate-forme de build particulier. expliquent Lewandowski et Lodato.

Quatre niveaux de conformité sont envisagés. Le plus élevé, SLSA 4, implique deux personnes examinant tous les changements et un processus de construction hermétique et reproductible comme un moyen d’être raisonnablement certain que rien n’a été falsifié.

L’espoir est que SLSA aidera à détecter des problèmes tels que l’hypocrite commet, des plates-formes de contrôle de code source compromises, une infrastructure de build modifiée ou compromise de manière malveillante, des dépendances subverties, des artefacts de build dangereux, des référentiels piratés et des attaques de typosquatting.

Sur une note de sécurité connexe, Google et ISRG, l’organisation à but non lucratif derrière Let’s Encrypt et d’autres projets utiles, ont déclaré jeudi que depuis avril, ils finançaient le développeur Miguel Ojeda pour travailler sur Rouille pour Linux et d’autres projets de sécurité et prévoient de le faire pendant un an. L’ajout de plus de code Rust au noyau Linux devrait réduire les erreurs de sécurité de la mémoire.

« Depuis [the Linux kernel is] écrit en grande partie dans le langage C, qui n’est pas sûr pour la mémoire, les vulnérabilités de sécurité de la mémoire telles que les débordements de mémoire tampon et les utilisations après libération sont une préoccupation constante », a expliqué Josh Aas, directeur exécutif de l’ISRG, dans un article de blog.

« En permettant d’écrire des parties du noyau Linux dans Rust, qui est sécurisé en mémoire, nous pouvons éliminer entièrement les vulnérabilités de sécurité de la mémoire de certains composants, tels que les pilotes. » ®