On passe notre temps à scanner nos images, à durcir nos clusters Kubernetes et à chasser les vulnérabilités dans notre code. Mais que se passe-t-il avant ? Comment être sûr que le code qui tourne en production est bien celui que les développeurs ont écrit ? C’est là que SLSA entre en jeu. Ce n’est pas un outil, mais un framework pour blinder sa chaîne de production logicielle.
J’entends parler de sécurité de la supply chain logicielle depuis des années. Après des incidents comme SolarWinds ou Codecov, le sujet est devenu critique. On a beau avoir les meilleures pratiques de sécurité applicative, si un attaquant peut injecter du code malveillant directement dans notre pipeline de build, toutes nos défenses en aval deviennent inutiles.
Le framework SLSA (Supply-chain Levels for Software Artifacts), prononcé “salsa”, est une réponse directe à ce problème. Initié par Google et maintenant sous l’égide de l’OpenSSF (Open Source Security Foundation), SLSA ne se contente pas de donner des conseils. Il fournit un cadre de maturité concret, avec des niveaux mesurables, pour évaluer et améliorer la sécurité de sa chaîne de production logicielle.
Pour moi, SLSA, c’est comme le HACCP pour l’industrie alimentaire. On ne se contente pas de tester le plat final ; on sécurise chaque étape de la préparation, de la source des ingrédients à la livraison.
Description du risque : La boîte noire du build
Le principal risque que SLSA adresse est la perte d’intégrité de la chaîne de production logicielle. Quand je lance un pipeline CI/CD, je dois avoir la certitude que :
- Le code source provient bien de mon dépôt Git et de la branche attendue.
- Le processus de build s’exécute dans un environnement isolé et éphémère, sans interférence.
- L’artefact produit (binaire, image de conteneur) est bien le résultat de ce build et n’a pas été altéré.
Sans les garanties apportées par SLSA, mon pipeline est une boîte noire. Je croise les doigts pour que l’artefact déployé corresponde bien au code que j’ai validé.
Vecteurs d’attaque ciblés par SLSA
Je distingue plusieurs points d’entrée qu’un attaquant peut exploiter dans une supply chain non sécurisée, et que SLSA vise à neutraliser :
1. Le commit empoisonné
Un attaquant obtient un accès à mon dépôt de code (via un token volé, par exemple) et injecte du code malveillant. Sans une politique de revue de code stricte (ex: 2 relecteurs), ce code peut se retrouver dans la branche principale.
2. Le cheval de Troie
Mon projet utilise une dépendance open source qui a été compromise (typosquatting, prise de contrôle du compte du mainteneur). Le code malveillant est téléchargé et intégré à mon application pendant le build.
3. Le coup d’État
L’attaquant compromet le serveur ou le service qui exécute mon pipeline CI/CD. Il peut alors modifier le processus de build à la volée pour injecter un backdoor dans l’artefact final, sans laisser de trace dans le code source.
4. L’échange standard
L’artefact est construit correctement, mais un attaquant parvient à le remplacer par une version modifiée dans le registre (ex: Docker Hub, Artifactory) avant son déploiement.
Exemple concret : L’attaque sur Codecov (2021)
L’incident de sécurité de Codecov est un cas d’école parfait.
- Le vecteur d’attaque : Des attaquants ont réussi à extraire une clé d’un conteneur Docker mal configuré utilisé par Codecov.
- L’exploitation : Avec cette clé, ils ont modifié le script
bash-uploaderde Codecov, un outil que des milliers d’entreprises utilisaient dans leurs pipelines CI/CD pour envoyer leurs rapports de couverture de code. - L’impact : La version modifiée du script exfiltrait les variables d’environnement des pipelines qui l’utilisaient. Cela incluait des secrets, des tokens d’API, des clés de base de données… tout ce qui était exposé dans l’environnement de build.
Cette attaque a eu lieu parce que les utilisateurs du script n’avaient aucun moyen de vérifier que l’outil qu’ils téléchargeaient et exécutaient était bien l’outil légitime. Ils faisaient confiance à l’URL de Codecov, qui servait désormais un script malveillant. Un mécanisme comme SLSA aurait permis de détecter que la provenance du script était suspecte ou que son intégrité était compromise.
Impact potentiel d’une supply chain compromise
| Impact | Niveau | Description de l'impact |
|---|---|---|
| Confidentialité | Élevé | Exfiltration de secrets (clés d'API, mots de passe, tokens) depuis le pipeline de build. |
| Intégrité | Critique | Injection de code malveillant (backdoors, ransomwares, mineurs de cryptomonnaie) dans les artefacts logiciels, qui sont ensuite déployés chez tous les clients. |
| Disponibilité | Modéré | Sabotage du processus de build, rendant impossible la livraison de nouvelles versions ou de correctifs de sécurité. |
| Réputation | Sévère | Perte totale de confiance des clients et de la communauté. L'entreprise devient un vecteur d'attaque pour tout son écosystème. |
Recommandations : Les niveaux de maturité SLSA
SLSA propose une approche progressive. Plutôt que de viser la perfection, on cherche à monter en maturité étape par étape, en commençant par le niveau 1.
Niveau 1 : Scripté et documenté
Le processus de build est entièrement scripté et automatisé. Je dois aussi générer des métadonnées de provenance, c’est-à-dire un document qui décrit comment l’artefact a été produit (quel dépôt, quel script, etc.).
# Exemple simple de génération de provenance
ARTIFACT_HASH=$(sha256sum my-app | awk '{ print $1 }')
cat <<EOF > provenance.json
{
"builder": { "id": "my-ci-script.sh" },
"source": { "uri": "git+https://github.com/my-org/my-repo@refs/heads/main", "digest": { "sha1": "$(git rev-parse HEAD)" } },
"artifact": { "digest": { "sha256": "$ARTIFACT_HASH" } }
}
EOF
Niveau 2 : Source authentifiée
Toutes les exigences du niveau 1, plus :
- Le build est exécuté sur une plateforme de CI/CD hébergée (ex: GitHub Actions, GitLab CI) qui authentifie la source.
- La provenance est générée par le service de build lui-même, ce qui la rend plus fiable.
Niveau 3 : Résistance aux menaces spécifiques
Toutes les exigences du niveau 2, plus :
- La plateforme de build garantit l’isolation entre les builds (environnements éphémères).
- La provenance est signée numériquement par un service qui n’est pas contrôlable par l’utilisateur (ex: via Sigstore). Cela empêche un attaquant de falsifier la provenance.
Niveau 4 : Hermétique et reproductible (Le Graal)
Le plus haut niveau de confiance. Toutes les exigences du niveau 3, plus :
- Build hermétique : Le processus de build n’a aucun accès réseau. Toutes les dépendances sont déclarées et pré-chargées.
- Build reproductible : Deux builds exécutés sur le même commit doivent produire des artefacts identiques au bit près.
Atteindre le niveau 4 est complexe, mais c’est la seule façon de garantir mathématiquement l’intégrité de la chaîne.
Quelques références pour aller plus loin
- Site officiel de SLSA : La source de vérité. Les spécifications complètes et les guides de démarrage.
- OpenSSF (Open Source Security Foundation) : L’organisation qui héberge le projet SLSA.
- Sigstore : Un projet essentiel de l’écosystème SLSA pour signer et vérifier les artefacts logiciels.
- SLSA on GitHub : Le dépôt du projet, pour suivre les évolutions.
À retenir
