La sécurité de la chaîne d’approvisionnement logicielle passe pour un sujet réservé aux organisations dotées d’une équipe sécurité, et ce cadrage induit en erreur. Une petite équipe qui exploite quelques services dépend en général de centaines de paquets que personne chez elle n’a lus, récupérés au moment du build depuis des registres qu’elle ne contrôle pas, et qui exécutent des scripts d’installation sur des machines où sont stockés ses identifiants de déploiement.

L’exposition n’est pas proportionnelle à la taille de l’entreprise. Elle est proportionnelle au nombre de dépendances et au degré d’automatisation du build, et les petites équipes ont souvent davantage du premier et moins de contrôle sur le second que les organisations qui s’inquiètent publiquement du sujet.

L’arithmétique qui dérange : votre application compte peut-être une douzaine de dépendances directes et plusieurs centaines de dépendances transitives. La douzaine, vous l’avez choisie. Le reste, non, vous n’en avez lu aucune, et n’importe laquelle d’entre elles, en exécutant un script d’installation, obtient exactement les mêmes accès que votre processus de build. Voilà la vraie surface d’attaque, et elle n’apparaît nulle part dans la liste de dépendances que vous avez écrite.

La sécurité commence au moment de l’installation

Le moment dangereux n’est généralement pas l’exécution du code. C’est son installation.

Les gestionnaires de paquets autorisent des scripts à s’exécuter pendant l’installation, ce qui signifie qu’un paquet compromis ou malveillant tourne avec les privilèges de la personne qui a lancé la commande. Sur un poste de développement, ce sont ses identifiants à elle. Dans un pipeline de build, ce sont les clés de déploiement, et c’est nettement plus grave.

Trois formes d’attaque expliquent la plupart des incidents réels.

Typosquatting. Un paquet dont le nom ne diffère que d’un caractère de celui d’un paquet populaire, publié puis laissé en attente d’une commande d’installation mal tapée. Peu coûteux à monter et efficace à grande échelle.

Compromission du compte d’un paquet légitime. Un paquet largement utilisé dont le mainteneur s’est fait voler ses identifiants, puis republié avec un ajout nuisible. C’est le cas le plus difficile à contrer, parce que ni le nom ni le nombre de téléchargements ne présentent quoi que ce soit d’anormal.

Dependency confusion. Un paquet public publié sous le nom de l’un de vos paquets internes, alors qu’un résolveur mal configuré préfère le registre public au vôtre. Entièrement un problème de configuration, et entièrement évitable.

Aucune de ces attaques ne suppose que quelqu’un vous vise précisément, et c’est justement le point. Elles sont opportunistes et elles passent à l’échelle.

Les contrôles qui valent l’effort à petite échelle

Versionnez le lockfile et installez à partir de lui. Un lockfile fige les versions exactes et leurs empreintes. Installer depuis le manifeste résout au contraire des versions fraîches au moment du build, ce qui rend la construction non reproductible et laisse une modification amont atteindre la production sans la moindre relecture. Utilisez la commande d’installation qui échoue quand le lockfile ne correspond pas, plutôt que celle qui le met à jour en silence.

Désactivez les scripts d’installation quand vous le pouvez. Beaucoup d’écosystèmes le permettent, et la plupart des paquets n’en ont aucun besoin. C’est la plus grande réduction d’exposition disponible sans outillage supplémentaire, et les rares paquets qui cassent sont précisément ceux que vous avez intérêt à connaître.

Automatisez les alertes de vulnérabilité, puis triez. Les scanners produisent plus de résultats qu’une petite équipe ne peut en traiter, et le mode de défaillance n’est pas l’alerte manquée, c’est l’abandon complet de la file parce que la majorité des entrées ne concernent personne. Filtrez sur ce qui est réellement atteignable depuis votre code et traitez cela. Une file que personne ne lit vaut moins que pas de file du tout.

Épinglez aussi votre outillage de build. L’image de conteneur, la version du runtime et l’action ou le plugin que votre pipeline appelle sont eux aussi des dépendances. Référencer une étiquette mutable plutôt qu’une empreinte immuable revient à laisser votre build changer sans vous.

Séparez les identifiants de build de tout le reste. Un pipeline autorisé à déployer ne devrait pas détenir des identifiants permettant d’aller plus loin, et un build compromis ne devrait pas pouvoir atteindre les données de production.

Ce qu’un SBOM apporte et ce qu’il n’apporte pas

Une nomenclature logicielle, ou SBOM, énumère ce que contient votre application, et sa valeur tient à une seule question, à laquelle elle répond vite : sommes-nous concernés ?

Cette question prenait autrefois plusieurs jours. Quand un composant largement diffusé se révèle vulnérable, une organisation qui dispose d’un inventaire à jour répond en quelques minutes, et une organisation qui n’en a pas passe une semaine à chercher. Cet écart résume tout l’argument, et c’est la raison pour laquelle l’adoption des SBOM est encouragée comme une pratique de base plutôt que comme un contrôle avancé.

Ce qu’il ne fait pas, c’est vous rendre sûr. Un inventaire est une liste, pas une défense. Il ne vous dit pas si une vulnérabilité listée est atteignable dans votre code, si elle compte dans votre configuration, ni si quelque chose a déjà été compromis. Les équipes qui en produisent un et le classent ont ajouté un document, pas un contrôle.

Générez-le depuis le build, afin qu’il décrive ce qui a réellement été livré et non ce que le manifeste prétendait. Conservez celui qui correspond à chaque version publiée. Et acceptez que sa valeur réside entièrement dans la vitesse à laquelle vous répondrez à une question qui vous sera posée sous pression.

Là où les petites équipes se font vraiment mal

Rarement par une compromission exotique de paquet. Par des choses ordinaires.

Des secrets dans le dépôt, qui restent dans l’historique après suppression et que des scanners automatisés trouvent dans les minutes qui suivent un push. Une dépendance vieille de trois ans avec un exploit publié et aucun chemin de mise à jour, parce que la montée de version a été repoussée jusqu’à devenir un projet à part entière. Des pipelines de build aux permissions excessives, où une pull request venue d’un fork s’exécute avec des accès qu’elle ne devrait pas avoir. Personne qui surveille, si bien qu’une compromission dure parce qu’aucune alerte n’arrive jamais devant un humain.

La conclusion, peu spectaculaire, est que maintenir les dépendances à jour constitue en pratique l’essentiel de la sécurité de la chaîne logicielle. Le coût de maintenance logicielle que les équipes traitent comme facultatif recouvre exactement le même travail, et le repousser transforme une montée de version de routine en urgence assortie d’un exploit.

Un point de départ proportionné

Pour une petite équipe, dans cet ordre : sortez les secrets du dépôt et faites tourner tout ce qui a été exposé. Versionnez les lockfiles et installez strictement à partir d’eux. Activez les alertes de dépendances et triez-les une fois par semaine plutôt qu’en continu. Épinglez l’outillage de build sur des références immuables. Réduisez les permissions du pipeline au minimum. Générez un SBOM par version publiée une fois le reste en place.

Cette séquence couvre les menaces réalistes sans équipe sécurité dédiée, et chaque étape se compte en heures plutôt qu’en semaines. Les contrôles qui viennent ensuite, attestation de provenance, builds reproductibles, artefacts signés, ont une valeur réelle et appartiennent à une étape où les bases tiennent déjà debout.

Mecanik audite et durcit les pipelines de build dans le cadre de son analyse de sécurité applicative. Le constat n’est presque jamais une compromission sophistiquée. C’est un jeton dans un dépôt et une dépendance que personne n’a mise à jour depuis le jour où elle a été choisie.

Questions fréquentes

Pourquoi l’installation des paquets est-elle le moment risqué ? Parce que les gestionnaires de paquets laissent des scripts s’exécuter pendant l’installation, avec les privilèges de la personne qui a lancé la commande. Sur un poste de développement, ce sont ses identifiants ; dans un pipeline de build, ce sont les clés de déploiement. Le code n’a pas besoin d’être exécuté par votre application pour faire des dégâts.

Qu’est-ce que la dependency confusion ? Une attaque où un paquet public est publié sous le nom de l’un de vos paquets internes, et où un résolveur mal configuré préfère le registre public au vôtre. Elle ne suppose personne qui vous vise précisément et elle est entièrement évitable en corrigeant la configuration du résolveur.

Qu’apporte concrètement un SBOM ? Une réponse rapide à une seule question : sommes-nous concernés ? Avec un inventaire à jour cela prend des minutes ; sans inventaire, cela prend une semaine de recherche. Il ne vous dit pas si une vulnérabilité listée est atteignable dans votre code ni si quelque chose a déjà été compromis, donc un SBOM généré puis classé reste un document et non un contrôle.

Dois-je versionner mon lockfile ? Oui, et installer strictement à partir de lui avec la commande qui échoue quand le lockfile ne correspond pas, plutôt que celle qui le met à jour. Installer depuis le manifeste résout des versions fraîches au moment du build, rend les constructions non reproductibles et laisse une modification amont atteindre la production sans aucune relecture.

Par où une petite équipe doit-elle commencer ? Retirez les secrets du dépôt et faites tourner tout ce qui a été exposé, versionnez les lockfiles et installez strictement, activez les alertes de dépendances et triez-les chaque semaine, épinglez l’outillage de build sur des références immuables, réduisez les permissions du pipeline, puis générez un SBOM par version publiée. Chaque étape se compte en heures plutôt qu’en semaines.