Sécurité de la chaîne logicielle : le guide complet

Qu'est-ce que la chaîne d'approvisionnement logicielle ?

La chaîne d'approvisionnement logicielle regroupe toutes les personnes et tous les éléments qui amènent un logiciel de l'éditeur de code d'un développeur jusqu'à la production. Elle se décompose en quatre étapes, chacune avec ses propres risques.

Étape	Ce qu'elle contient	Ce qui peut mal tourner
Source	Votre code, vos dépôts et les comptes de vos développeurs	Identifiants volés, commits malveillants, secrets divulgués
Dépendances	Paquets open source, images de base, code tiers	Versions vulnérables, releases malveillantes, typosquatting
Build	Runners CI, GitHub Actions, outils de build, caches	Actions compromises, caches empoisonnés, secrets de pipeline volés
Release	Artefacts, registres, déploiements, mises à jour	Artefacts substitués, mises à jour altérées, aucune trace de ce qui a été livré

Pourquoi c'est important aujourd'hui

L'essentiel de ce que vous livrez, vous ne l'avez pas écrit. Une application moderne est principalement open source, et chaque dépendance directe en apporte d'autres que personne dans votre équipe n'a choisies. Ces paquets s'exécutent avec les mêmes accès que votre propre code, et leurs scripts d'installation peuvent s'exécuter dans votre pipeline CI, à côté de vos secrets.

Les dernières années montrent comment cela est exploité :

SolarWinds : le build a été compromis, si bien qu'un code source sain a produit une release empoisonnée.
Log4Shell : une faille dans une seule bibliothèque de journalisation a atteint des produits qui ignoraient l'utiliser.
xz utils : un contributeur de confiance a glissé une porte dérobée dans un projet présent dans les distributions Linux.
tj-actions : une GitHub Action détournée a exécuté le code des attaquants dans les pipelines qui l'utilisaient, avec des secrets à portée de main.
Shai-Hulud : un ver s'est propagé dans les paquets npm, volant des tokens sur les machines et dans les jobs CI qui les installaient.

Pour comprendre ces attaques étape par étape, voir qu'est-ce qu'une attaque de la chaîne d'approvisionnement.

Comment fonctionne la sécurité de la chaîne d'approvisionnement logicielle

Un programme a besoin de quatre choses. Tout le reste n'est que détail.

Savoir ce que vous livrez. Conservez une SBOM exacte pour chaque release, issue du build qui l'a produite, y compris les dépendances transitives.
Contrôler ce qui entre. Épinglez les versions, utilisez un lockfile, limitez les sources depuis lesquelles les builds peuvent récupérer des paquets et vérifiez les nouveaux paquets.
Protéger le build. Isolez les jobs, limitez les secrets, épinglez les actions par commit et restreignez le trafic sortant, pour qu'un paquet compromis ne puisse envoyer vos tokens nulle part. Consultez la sécurité des runners et pourquoi la sécurité de la chaîne d'approvisionnement a sa place dans la CI.
Continuer à surveiller ce qui a été livré. De nouvelles vulnérabilités touchent des logiciels déjà en production. Surveillez ces logiciels, identifiez les releases concernées et suivez chaque correction jusqu'à une nouvelle release.

Pour la checklist détaillée, consultez les bonnes pratiques de sécurité de la chaîne d'approvisionnement logicielle.

Cadres et réglementations

Nom	Ce que c'est	Idéal pour
SLSA	Des niveaux pour l'intégrité du build et la provenance	Renforcer la façon dont le logiciel est construit
NIST SSDF	Pratiques de développement sécurisé, SP 800-218	Un programme complet de développement sécurisé
NIST SP 800-161	Gestion des risques cyber de la chaîne d'approvisionnement	La gestion des risques à l'échelle de l'organisation
OpenSSF Scorecard	Contrôles automatisés de la santé des projets open source	Vérifier les dépendances
Cyber Resilience Act	Loi de l'UE sur les produits comportant des éléments numériques	Vendre dans l'UE. Voir qu'est-ce que le CRA

Quels outils sont concernés ?

Aucun produit ne couvre à lui seul tout cela. La catégorie se divise en outils SCA, outils SBOM, sécurité CI/CD et des runners, pare-feu de paquets, gestion de la posture de sécurité des applications et analyse de binaires. Pour savoir ce que fait chacun et qui le vend, consultez le comparatif des outils de sécurité de la chaîne d'approvisionnement logicielle et leur coût.

Par où commencer

Générez une SBOM de votre produit le plus important à partir de son build CI, et lisez-la.
Activez les alertes de vulnérabilité sur les dépendances, et décidez qui en est responsable.
Épinglez vos GitHub Actions par commit et passez en revue les secrets auxquels vos workflows ont accès.
Limitez le trafic sortant de vos builds aux hôtes dont ils ont réellement besoin.
Mettez en place la surveillance de ce que vous avez livré, pas seulement de ce que vous construisez.

L'approche de CRACI

CRACI commence par le build, car c'est le seul endroit qui voit tout. Il remplace vos runners hébergés par GitHub par des runners plus rapides et moins coûteux qui enregistrent chaque paquet récupéré par chaque job, à tous les niveaux de l'arbre, y compris les paquets restaurés depuis les caches CI. La politique de trafic sortant bloque les connexions dont votre build n'a pas besoin : elle vous protège donc même contre une attaque que personne n'a encore vue. CRACI continue ensuite de vérifier ce qui a été livré par rapport aux nouvelles vulnérabilités et suit chacune, du tri jusqu'à une release corrigée. Consultez la sécurité de la chaîne d'approvisionnement logicielle avec CRACI.

Sécurité de la chaîne d'approvisionnement logicielle : questions fréquentes

Qu'est-ce que la sécurité de la chaîne d'approvisionnement logicielle ?

C'est la pratique qui consiste à protéger tout ce qui entre dans votre logiciel avant qu'il n'atteigne les utilisateurs : dépendances open source, systèmes de build, outils du pipeline et releases.

Quel exemple d'attaque de la chaîne d'approvisionnement logicielle peut-on citer ?

Lors de l'attaque SolarWinds, le build a été compromis, si bien que les clients ont reçu une mise à jour empoisonnée d'un éditeur de confiance. Lors des attaques Shai-Hulud, un ver s'est propagé dans les paquets npm et a volé des tokens sur les machines qui les installaient.

Quelle est la différence entre la sécurité de la chaîne d'approvisionnement et la sécurité applicative ?

La sécurité applicative examine les failles du code que vous écrivez. La sécurité de la chaîne d'approvisionnement examine ce que vous n'avez pas écrit et la façon dont votre logiciel est construit et publié. Un programme a besoin des deux.

Une SBOM suffit-elle à sécuriser la chaîne d'approvisionnement ?

Non. Une SBOM vous dit ce que vous livrez, ce qui en est le fondement. Vous devez aussi contrôler ce qui entre, protéger le build et continuer à surveiller ce que vous avez publié.

Quels sont les principaux cadres ?

SLSA pour l'intégrité du build, le NIST SSDF pour les pratiques de développement sécurisé et NIST SP 800-161 pour la gestion des risques de la chaîne d'approvisionnement. Dans l'UE, le Cyber Resilience Act fixe des exigences légales pour les produits comportant des éléments numériques.

Qui est responsable de la sécurité de la chaîne d'approvisionnement logicielle ?

Elle relève généralement de la sécurité applicative ou produit, en lien avec les équipes plateforme et DevOps qui gèrent les pipelines. Les corrections vont ensuite aux équipes d'ingénierie responsables de chaque service.