Menaces liées à la chaîne d’approvisionnement

Une attaque de la chaîne logistique logicielle compromet une organisation non pas en l'attaquant directement, mais en corrompant un élément auquel elle fait confiance et qu'elle utilise : une bibliothèque, un outil de compilation, une image de base de conteneur ou un serveur de mise à jour.

Comme les logiciels modernes sont assemblés à partir de centaines de composants tiers, un seul maillon empoisonné est transmis à chaque utilisateur en aval. L'attaquant investit une fois et atteint de nombreuses victimes.

• Inversion de la confiance — la frontière de sécurité se déplace à l'extérieur de votre propre code
• Rayon d'impact transitif — un seul paquet malveillant se propage dans des milliers de compilations

Lorsque vous ajoutez une dépendance directe, vous récupérez souvent des dizaines de dépendances transitives que vous n'avez jamais choisies. Une application Node ou Python typique déclare quelques paquets, mais en résout des centaines.

Répertoriez l'arborescence complète résolue, et pas seulement le manifeste, afin de voir ce que vous livrez réellement :

Les attaquants publient des paquets malveillants dont les noms ressemblent à ceux de paquets populaires, en comptant sur une faute de frappe fatale.

• Typosquattage — reqeusts au lieu de requests
• Combosquattage — python-requests qui imite le véritable nom
• Confusion de dépendances — publication d'un paquet public portant le même nom que votre paquet privé interne, afin qu'un résolveur mal configuré récupère la version de l'attaquant

Défendez-vous en imposant un registre interne de confiance et en utilisant des paquets privés avec une portée ou un espace de noms.

Un paquet légitime et largement approuvé peut devenir malveillant si le compte de son responsable de maintenance est compromis ou si un contributeur malveillant obtient les droits de publication.

Des incidents récents montrent que des attaquants hameçonnent les identifiants des responsables de maintenance, puis publient une version corrective empoisonnée qui exfiltre des jetons pendant l'installation.

• Exigez l'authentification à deux facteurs sur tous les comptes de publication
• Privilégiez les paquets dotés de jetons de publication à portée limitée et de versions protégées
• Surveillez l'apparition inattendue de nouveaux responsables de maintenance sur les dépendances critiques

De nombreux écosystèmes exécutent du code au moment de l'installation, avant même que votre application ne s'exécute. Un npm install peut exécuter un mécanisme postinstall qui dérobe des variables d'environnement ou des clés SSH.

Désactivez les scripts d'installation arbitraires dans l'intégration continue et contrôlez chaque paquet qui en a besoin :

L'environnement de compilation lui-même est une cible de grande valeur. Si un attaquant empoisonne un compilateur, une image d'agent d'intégration continue ou un module d'extension de compilation, chaque artefact qu'il produit comporte une porte dérobée, même lorsque votre code source est sain.

L'exemple classique est un mécanisme de mise à jour transformé en cheval de Troie qui signe un logiciel malveillant avec une clé légitime de signature de code, de sorte que les victimes l'acceptent comme authentique.

• Traitez l'infrastructure de compilation comme une infrastructure de production et appliquez-y un renforcement complet
• Utilisez des agents de compilation éphémères et reproductibles
• Séparez les clés de signature de l'hôte de compilation

Un fichier de verrouillage fixe les versions exactes et les hachages du contenu, de sorte qu'une nouvelle résolution ne puisse pas remplacer discrètement un artefact par un autre. Validez-le toujours dans le dépôt et laissez l'intégration continue le vérifier plutôt que de relancer librement la résolution.

Le champ d'intégrité stocke un hachage ; si l'archive tar téléchargée ne correspond pas, l'installation échoue.

Les versions connues comme vulnérables (suivies sous forme de CVE) constituent la faiblesse la plus courante de la chaîne logistique. Les outils d'analyse de la composition logicielle (SCA) comparent vos dépendances résolues aux bases de données de vulnérabilités.

Exécutez des analyses dans l'intégration continue et faites échouer les compilations en cas de découvertes critiques :

Les plages de versions flottantes (^1.2.0) laissent automatiquement entrer les nouvelles versions, ce qui est pratique mais vous expose à une mise à jour corrective malveillante.

• Figez les versions exactes et examinez délibérément les mises à niveau
• Figez par hachage les images de conteneur, et non par des étiquettes modifiables comme latest
• Intégrez localement les dépendances critiques dans votre propre dépôt ou miroir afin qu'une suppression en amont ne puisse ni vous bloquer ni vous contaminer

Sécuriser la chaîne logistique est une activité continue, et non une analyse ponctuelle. Vous devez savoir ce que vous livrez, d'où cela provient et quand cela devient vulnérable.

• Générez une SBOM pour chaque version (dans la prochaine leçon)
• Consignez la provenance de la compilation afin de pouvoir prouver comment un artefact a été produit
• Abonnez-vous aux avis de sécurité afin qu'une nouvelle CVE déclenche une réévaluation des compilations déjà livrées

Cartographiez chaque étape où une entrée non fiable est introduite : les postes des développeurs, la gestion du code source, les registres de dépendances, le système de compilation, le stockage des artefacts et le canal de mise à jour. Chacune constitue un point d'injection potentiel.

Pour chaque étape, demandez-vous : qui peut écrire ici, que pourrait lui permettre une compromission et comment la détecterais-je ? Vous obtiendrez ainsi une liste priorisée de mesures de contrôle plutôt qu'une liste de vérification générique.

Vous avez appris pourquoi les dépendances constituent des vecteurs d'attaque et comment réduire cette exposition.

• L'inversion de la confiance signifie que votre sécurité dépend de tiers que vous ne contrôlez pas
• Menaces principales : typosquattage, confusion de dépendances, prise de contrôle d'un responsable de maintenance, scripts d'installation malveillants et outils de compilation compromis
• Défenses essentielles : fichiers de verrouillage avec hachages d'intégrité, analyse SCA, figement exact par hachage, authentification à deux facteurs pour les éditeurs et surveillance continue

Ensuite, vous dresserez l'inventaire exact du contenu de votre logiciel à l'aide d'une SBOM.