Aller au contenu principal

La chaîne d'approvisionnement logicielle

Résumé : la majorité du code qui s'exécute dans votre application ne vient pas de vous. Elle vient de bibliothèques, elles-mêmes construites sur d'autres bibliothèques, dans une chaîne dont vous ignorez généralement l'étendue. Cette leçon explique les risques de cette chaîne — dépendances indirectes, typosquatting, compromission de mainteneur — et les réponses : SBOM, verrouillage de version, signature et le cadre SLSA.

1. L'ampleur du problème​

C'est le constat qui fonde toute cette leçon. La question n'est pas « mon code est-il sûr ? » mais « l'ensemble de ce qui s'exécute chez moi est-il sûr ? ». Et cet ensemble, vous ne l'avez ni écrit, ni lu, ni choisi entièrement.

Un chiffre parlant : dans l'écosystème JavaScript, installer un outil de développement courant peut amener plus de mille paquets. Chacun est un point de confiance, et chacun peut publier une nouvelle version demain matin.

2. Les cinq façons d'être attaqué par la chaîne​

Une hiérarchie importante à garder en tête. Le vecteur 1 représente l'immense majorité des incidents réels et il est entièrement évitable : il suffit de suivre ses dépendances et d'appliquer les correctifs. Les vecteurs 4 et 5 sont spectaculaires et font les gros titres, mais ils sont rares.

Le conseil pratique qui en découle : consacrez d'abord votre énergie au vecteur 1. Une équipe qui applique ses correctifs élimine plus de risque réel qu'une équipe qui met en place des vérifications de signature sophistiquées sans mettre à jour ses bibliothèques.

3. Le typosquatting et la confusion de dépendances​

La confusion de dépendances est particulièrement redoutable parce qu'elle exploite une configuration par défaut plutôt qu'une erreur humaine. Elle a été démontrée publiquement en 2021 contre plusieurs très grandes entreprises technologiques, avec un succès qui a surpris tout le monde.

4. Le verrouillage de version​

C'est la mesure la plus rentable de toute cette leçon, et elle est gratuite. Selon votre écosystème, le fichier s'appelle package-lock.json, yarn.lock, poetry.lock, Gemfile.lock, go.sum ou Cargo.lock. Versionnez-le toujours.

Le complément indispensable en intégration continue : utilisez la commande qui respecte strictement le fichier de verrouillage et échoue s'il est incohérent — npm ci plutôt que npm install, par exemple. Sinon votre verrouillage peut être silencieusement contourné.

5. Le SBOM — l'inventaire de vos composants​

Le meilleur argument en faveur du SBOM est l'expérience vécue de décembre 2021. Quand Log4Shell est apparu, la question posée dans toutes les entreprises du monde a été : « utilisons-nous Log4j, et où ? ». Les organisations disposant d'un inventaire ont répondu en quelques minutes. Les autres ont mobilisé des équipes entières pendant des jours — sans certitude d'avoir tout trouvé.

Point réglementaire à connaître : le SBOM devient progressivement une exigence contractuelle, notamment pour les fournisseurs du secteur public américain depuis un décret présidentiel de 2021, et de plus en plus dans les appels d'offres européens.

Comment en produire un : des outils comme Syft, Trivy ou les fonctions intégrées de Docker génèrent un SBOM en une commande. Ce n'est pas un chantier, c'est une étape de pipeline.

6. La signature d'artefacts​

L'innovation apportée par Sigstore mérite d'être soulignée. Historiquement, signer supposait de gérer des clés privées — les stocker, les protéger, les faire tourner — ce qui décourageait la plupart des équipes. Sigstore permet de signer avec une identité éphémère fournie par le système de CI, sans aucune clé à conserver. C'est ce qui a rendu la signature réellement accessible.

7. Que faire concrètement​

L'étape 6 est celle dont personne ne parle et qui est pourtant la plus efficace à long terme. Avant d'ajouter une dépendance, posez-vous trois questions : « en ai-je vraiment besoin ? », « puis-je écrire ces vingt lignes moi-même ? », « ce projet est-il activement maintenu ? ». Une dépendance non ajoutée est une vulnérabilité future qui ne vous concernera jamais.

Comment évaluer une dépendance avant de l'adopter : regardez la date du dernier commit, le nombre de mainteneurs actifs (un seul mainteneur est un risque), le nombre de dépendances qu'elle apporte elle-même, et l'existence d'une politique de sécurité déclarée.

Retenir en 30 secondes​

  • Vous écrivez une fraction infime du code qui s'exécute. 25 dépendances directes en amènent souvent plusieurs centaines d'indirectes.
  • Cinq vecteurs d'attaque : vulnérabilité non corrigée, typosquatting, compromission de mainteneur, contributeur malveillant patient, compromission de la chaîne de construction.
  • Le vecteur 1 représente l'immense majorité des incidents réels et il est entièrement évitable. Commencez par là.
  • La confusion de dépendances exploite une configuration par défaut, pas une erreur humaine. Réservez un préfixe pour vos paquets internes.
  • Versionnez toujours votre fichier de verrouillage, et utilisez la commande stricte en CI (npm ci, pas npm install).
  • Un SBOM est l'inventaire complet de vos composants. Formats : CycloneDX et SPDX.
  • L'intérêt du SBOM se révèle pendant un incident : réponse en secondes plutôt qu'en jours. Souvenez-vous de Log4Shell.
  • La signature d'artefacts ferme le scénario de substitution. Sigstore et Cosign l'ont rendue accessible, sans clé à gérer.
  • SLSA est le cadre de référence, avec des niveaux progressifs de garantie sur la construction.
  • Le gain le plus durable : réduire le nombre de dépendances. Une bibliothèque non ajoutée est un risque définitivement éliminé.

Suivant : Les secrets et les identités : où stocker vos clés →