Sécurité de la chaîne d’approvisionnement : qu’est-ce que la SLSA ? Première partie

Introduction rapide à la chaîne d’approvisionnement logicielle

Récemment, « l’attaque de la chaîne d’approvisionnement logicielle » a fait la une des journaux. Un exemple tristement célèbre est l’attaque de SolarWinds ou la violation de données du gouvernement fédéral des États-Unis en 2020. En fait, selon un rapport de 2021 de Gartner :

D’ici 2025, 45 % des organisations dans le monde auront subi des attaques sur leurs chaînes d’approvisionnement en logiciels, soit une multiplication par trois par rapport à 2021.

Qu’est-ce qu’une chaîne d’approvisionnement logicielle ?

C’est tout ce dont vous avez besoin pour livrer votre produit dans les étapes de création d’artefacts logiciels.

Il peut être utile de penser à la chaîne d’approvisionnement d’un bien physique, comme une voiture. Une chaîne d’approvisionnement pour une voiture peut inclure des choses comme celles-ci :

Composants produits en interne, comme les moteurs et les boîtes de vitesses.
Composants tiers, comme les ceintures de sécurité et les phares.
L’usine, y compris les installations, les machines et l’outillage utilisés pour construire les composants et assembler la voiture.
Les ouvriers travaillant dans l’usine de production.
Les processus, comme comment accéder aux différents outils et systèmes, comment faire le contrôle de la qualité, etc.

Pour une chaîne logistique logicielle, il contient :

Tout le code, y compris ses dépendances, et les logiciels internes et externes que vous utilisez pour développer, créer, empaqueter, installer et exécuter votre logiciel.
Systèmes
Personnes
Processus et politiques qui contribuent au développement et à la livraison de votre logiciel, à la fois à l’intérieur et à l’extérieur de votre organisation, comme les processus et les politiques d’accès aux systèmes, les tests de logiciels, la révision (à la fois codée et non codée), la surveillance, la communication, l’approbation, etc.

Maintenant que nous avons clarifié la définition de la chaîne d’approvisionnement, examinons quelques attaques de la chaîne d’approvisionnement : comment et de quelle manière elles se produisent.

Attaques de la chaîne d’approvisionnement

Compte tenu de la complexité des produits et systèmes logiciels et de la vaste portée de la chaîne d’approvisionnement logicielle, il existe de nombreuses façons d’introduire des modifications non autorisées dans les progiciels à différentes étapes du cycle de vie du développement logiciel (SDLC).

Un flux de travail de développement logiciel typique ressemble à ceci :

Menaces sur la chaîne d’approvisionnement :

Au point « A » du cycle de vie du développement, un mauvais code pourrait être soumis au référentiel. L’un des exemples les plus célèbres serait les commits hypocrites de Linux, où les chercheurs ont tenté d’introduire intentionnellement des vulnérabilités dans le noyau Linux. En raison de l’ampleur des grands projets open source, il peut être difficile de faire la distinction entre les membres de la communauté avec une intention bonne ou malveillante.
Au point « D », une plate-forme de construction compromise peut également causer des problèmes. Par exemple, dans l’attaque SolarWinds mentionnée au début de cet article, les attaquants ont compromis la plate-forme de construction et installé un implant qui a injecté un comportement malveillant lors de chaque construction.
Au point « E », une dépendance nuisible peut être utilisée. Par exemple, dans l’incident de vulnérabilité du flux d’événements, les attaquants ont ajouté une dépendance, puis mis à jour la dépendance pour ajouter un comportement malveillant. La dépendance nuisible elle-même peut être attaquée aux points « AH », et les dépendances de la dépendance peuvent également être attaquées aux points « AH », de manière récursive.
Au point « F », un artefact non construit par le système CI/CD peut être téléchargé. Par exemple, dans l’incident CodeCov, l’attaquant a utilisé des informations d’identification divulguées pour télécharger un artefact malveillant, et les utilisateurs l’ont téléchargé directement.

Je pourrais continuer, mais j’ai déjà fait valoir mon point de vue : les logiciels et le développement de logiciels sont devenus de plus en plus compliqués, et il y a de nombreuses étapes et aspects qui y sont liés, et chaque étape peut mal tourner.

Attaques de la chaîne d’approvisionnement : le passé et l’avenir

Dans le passé, les attaques de la chaîne d’approvisionnement des logiciels hérités se produisaient de manière « exploitante », où les attaquants s’attaquaient à des CVE (vulnérabilités et expositions communes) open source non corrigées et divulguées publiquement. Par exemple, le tristement célèbre incident Struts à Equifax.

Cependant, la nouvelle génération d’attaques de la chaîne d’approvisionnement logicielle est bien plus dangereuse. Les attaquants n’attendent plus les CVE divulgués publiquement. Au lieu de cela, ils prennent activement l’initiative, injectant du code malveillant dans des projets open source qui alimentent la chaîne d’approvisionnement mondiale.

On pourrait dire que les méchants « se déplacent également vers la gauche », tout comme DevSecOps le fait !

En déplaçant leur attention « en amont », les attaquants peuvent infecter un seul composant, qui sera ensuite distribué « en aval » à l’aide de workflows logiciels légitimes et de mécanismes de mise à jour.

Selon une étude réalisée par des chercheurs de l’Université de Darmstadt en 2019 :

« 391 mainteneurs très influents affectent plus de 10 000 packages, ce qui en fait des cibles de choix pour les attaques. »

Si un attaquant réussissait à compromettre des projets pris en charge par l’un de ces 391 mainteneurs, il pourrait considérablement élargir le cercle d’impact de l’attaque. Par exemple, l’équipe de Darmstadt a déclaré que vingt mainteneurs peuvent atteindre plus de la moitié de l’écosystème npm. Les risques augmentent encore davantage car la Core Infrastructure Initiative de la Linux Foundation a découvert que sept des dix packages logiciels les plus utilisés étaient hébergés sous des comptes de développeur individuels. Les chercheurs se sont alors interrogés, « que se passe-t-il si l’un de ces comptes est piraté ? Le sauriez-vous, plus loin dans la chaîne d’approvisionnement en logiciels ? »

Les attaques de nouvelle génération sont rendues possibles pour plusieurs raisons :

Les projets open source reposent généralement sur des centaines, voire des milliers, de dépendances d’autres projets open source. Ils sont aussi beaucoup utilisés. Cela rend difficile l’évaluation de la sécurité de chaque nouvelle version d’une dépendance. Peu lisent le code source des applications sur lesquelles ils s’appuient ; il y en a trop, leurs bases de code sont trop volumineuses et il est probable que la plupart des personnes lisant le code source ne pourraient de toute façon pas faire une analyse de sécurité appropriée.
L’open source s’appuie sur des milliers de contributeurs, et il est difficile, si possible, de faire la distinction entre les membres de la communauté avec une intention bonne ou malveillante.
L’open source est construit sur un « réseau de confiance », qui peut être plus sécurisé que les projets à source fermée, mais crée toujours un environnement dans lequel les attaquants peuvent s’attaquer.

Les attaques de nouvelle génération sont déjà suffisamment graves, mais la mauvaise nouvelle est qu’elles sont toujours en augmentation. Les attaques ciblant l’open source ont augmenté à 430 % depuis la publication du rapport de Darmstadt (216 attaques de ce type enregistrées de février 2015 à juin 2019, contre 929 enregistrées de juillet 2019 à mai 2020).

Présentation de SLSA : Atténuation des problèmes de sécurité de la chaîne d’approvisionnement

Comment améliorer la sécurité de la chaîne d’approvisionnement, alors ?

Bien qu’il existe des solutions « ponctuelles » capables de résoudre une menace ou une vulnérabilité spécifique à une étape particulière de la chaîne d’approvisionnement (ou du SDLC), cela ne suffit pas. Nous manquons d’un cadre complet et de bout en bout qui régit l’ensemble de la chaîne d’approvisionnement dans tous ses aspects, définit comment atténuer les menaces tout au long de la chaîne d’approvisionnement logicielle et fournit des garanties de sécurité appropriées.

Entrez dans le cadre SLSA

Les niveaux de la chaîne d’approvisionnement pour les artefacts logiciels, ou SLSA (lire : salsa), sont inspirés de l’« autorisation binaire pour Borg » interne de Google, qui est utilisée depuis plus de 8 ans et est obligatoire pour toutes les charges de travail de production de Google.

L’objectif de SLSA est d’améliorer l’état de l’industrie, en particulier l’open source, pour se défendre contre les menaces d’intégrité les plus pressantes.

À qui s’adresse SLSA, alors? Que vous soyez un développeur, une entreprise ou une entreprise, SLSA fournit une norme industrielle, un niveau de protection et de conformité reconnaissable et convenu.

Dans son état actuel, SLSA est un cadre de sécurité, un ensemble de directives de sécurité progressivement adoptables établies par consensus de l’industrie. Considérez-le comme une liste de contrôle des normes et des contrôles pour empêcher la falsification, améliorer l’intégrité et sécuriser les packages et l’infrastructure de vos projets, entreprises ou entreprises. C’est ainsi que l’on passe de « suffisamment sûr » à « être aussi résilient que possible » à n’importe quel maillon de la chaîne d’approvisionnement en logiciels.

Les normes établies par la SLSA sont des principes directeurs pour les producteurs et les consommateurs de logiciels : les producteurs peuvent suivre les directives pour rendre leurs logiciels plus sûrs, et les consommateurs peuvent prendre des décisions en fonction de la posture de sécurité d’un progiciel.

Quatre niveaux de sécurité de SLSA

SLSA a conçu quatre niveaux de sécurité, qui sont incrémentiels et actionnables, pour se protéger contre des attaques d’intégrité spécifiques. Les niveaux SLSA sont comme un langage commun pour discuter de la sécurité des logiciels, des chaînes d’approvisionnement et de leurs composants. SLSA 4 représente l’état final idéal, et les niveaux inférieurs représentent des jalons avec des garanties d’intégrité correspondantes.

Voici une introduction rapide :

SLSA: documentation du processus de construction. Le processus de génération doit être entièrement scripté/automatisé et générer la provenance (les métadonnées sur la façon dont un artefact a été créé, y compris le processus de génération, la source de niveau supérieur et les dépendances). Connaître la provenance permet aux consommateurs de logiciels de prendre des décisions de sécurité basées sur les risques. La provenance à SLSA 1 ne protège pas contre la falsification, mais elle offre un niveau de base d’identification de source de code et peut aider à la gestion des vulnérabilités. SLSA 1 est facile à adopter, vous donnant une visibilité sur la chaîne d’approvisionnement et pouvant générer la provenance.
SLSA: inviolabilité du service build. Il nécessite un contrôle de version et un service de génération hébergé qui génère une provenance authentifiée. Ces exigences supplémentaires donnent au consommateur de logiciels une plus grande confiance dans l’origine du logiciel. À ce niveau, la provenance empêche la falsification dans la mesure où le service de génération est approuvé. SLSA 2 commence à protéger contre la falsification logicielle et ajoute des garanties d’intégrité de construction minimales.
SLSA 3: résistance supplémentaire à des menaces spécifiques. Les plates-formes source et build répondent à des normes spécifiques pour garantir respectivement l’audibilité de la source et l’intégrité de la provenance. Nous envisageons un processus d’accréditation par lequel les auditeurs certifient que les plateformes répondent aux exigences, sur lesquelles les consommateurs peuvent compter. SLSA 3 offre des protections beaucoup plus robustes contre la falsification que les niveaux précédents en empêchant des classes spécifiques de menaces, telles que la contamination croisée. SLSA 3 durcit le…