L’IA élargit la surface d’attaque des chaînes logicielles

L’IA affaiblit une réponse de sécurité bien connue face aux attaques de la chaîne d’approvisionnement logicielle : analyser davantage de code et détecter plus d’activité malveillante. Les attaquants peuvent atteindre de nombreuses organisations plus tôt via les systèmes qui acquièrent, compilent, signent et distribuent les logiciels, tandis que l’IA augmente le nombre de personnes et d’agents qui consomment des composants tiers. Pour les RSSI, ce déplacement reporte la frontière de sécurité utile vers une décision plus en amont : quels artefacts les systèmes de build peuvent considérer comme fiables et quels environnements peuvent les traiter.

L’IA modifie l’économie des attaques de la chaîne d’approvisionnement logicielle

Cette frontière plus en amont est importante, car les attaquants se tournent de plus en plus vers les pipelines d’intégration continue et de livraison continue (CI/CD), les packages npm et PyPI, les workflows GitHub Actions et les outils d’agents IA connectés au développement. Quincy Castro, RSSI de Chainguard et auparavant RSSI dans deux grandes multinationales, affirme que des packages open-source largement utilisés sont compromis « presque chaque semaine », qu’une compromission peut potentiellement atteindre « des dizaines de milliers d’organisations en aval » et que les attaques de la chaîne d’approvisionnement logicielle ont commencé à s’accélérer au début de 2026.

Castro voit dans cette accélération un changement économique. « Les attaques de la supply chain étaient auparavant considérées comme rares et exotiques, généralement très intentionnelles et très méthodiques, et les défenseurs les voyaient surtout comme une technique d’États-nations pour pénétrer des cibles difficiles », dit-il. « Ce que nous avons vu cette année, c’est que des attaquants motivés par le profit ont compris que le développement logiciel est le talon d’Achille des organisations. À mesure que nous sommes devenus meilleurs pour défendre les terminaux traditionnels et les environnements cloud, nous avons naturellement poussé les adversaires vers une zone bien moins défendue. »

Cette économie devient encore plus favorable lorsqu’un attaquant compromet un élément consommé par de nombreuses organisations. Les campagnes de type watering hole de la décennie précédente avaient déjà établi un modèle connexe de un-à-plusieurs en compromettant des sites web et en exposant leurs visiteurs ; avec les logiciels, un projet open-source compromis peut potentiellement atteindre chaque projet qui l’installe. Le coût marginal de l’attaquant pour chaque victime supplémentaire peut tomber à « pratiquement zéro », tandis qu’il inspecte les environnements compromis en aval et cible les plus précieux.

La frontière de sécurité négligée, c’est le système de build lui-même

Cette économie de un-à-plusieurs met en lumière un décalage dans de nombreux programmes de sécurité CI/CD, car les revues se concentrent souvent sur le code alors que l’infrastructure qui le traite dispose elle-même de privilèges importants. Un runner de build peut détenir des identifiants de registre, des clés de signature et des tokens de comptes de service cloud tout en exécutant les scripts d’installation des dépendances qu’il résout. Un environnement de build compromis peut donc fournir des formes d’accès que les contrôles de qualité du code et les garde-fous de vulnérabilité n’ont jamais été conçus pour gouverner.

Ces privilèges font de GitHub Actions une autre partie de la frontière de confiance. Un workflow peut référencer une action tierce via un tag mutable, ce qui signifie qu’un propriétaire en amont peut rediriger ce tag vers un autre commit. Un build qui consommait auparavant le code attendu peut alors exécuter un code différent sans que l’organisation ne modifie délibérément son workflow, de sorte que le pipeline dépend aussi de la fiabilité de ce composant en amont.

Cette confiance en amont peut affecter les étapes ultérieures, car les systèmes de build possèdent souvent des identifiants utilisés au-delà d’un seul job de build. Un pipeline peut réussir tous les contrôles de sécurité appliqués à son code applicatif tout en exposant des identifiants capables de signer et publier une release ou de s’authentifier auprès d’un référentiel d’artefacts ou d’un service cloud. L’analyse de code peut fonctionner exactement comme prévu, tandis qu’une autre partie du même système donne à un attaquant un accès de grande valeur.

Castro décrit comment des contrôles réussis peuvent masquer le système dans son ensemble. « Vous pouvez avoir un pipeline où vous pensez : “Je suis excellent en sécurité : j’analyse mon code, j’empêche les vulnérabilités critiques de passer les contrôles CI”, et ainsi de suite », dit-il. « Puis vous prenez du recul et ce système de build est exposé sur l’internet public, parce que l’équipe de développement est répartie dans le monde entier, et vous les avez laissés mettre des personal access tokens de longue durée dans leurs scripts de build. Ce n’est pas un système sécurisé. »

La répartition mondiale évoquée dans l’exemple de Castro est importante, car l’infrastructure de développement doit prendre en charge la manière dont l’ingénierie travaille réellement. Des services de build exposés pour des raisons opérationnelles légitimes peuvent malgré tout devenir des frontières de sécurité sensibles lorsqu’ils transportent des identifiants de longue durée et exécutent du code provenant de sources externes. Le problème de contrôle couvre donc ce que l’infrastructure de build exécute et quels privilèges sont disponibles pendant l’exécution, étendant la politique de sécurité au-delà des vulnérabilités du code livré.

La supervision intervient après l’exécution

Ces privilèges du système de build rendent une supervision plus large utile pour la visibilité, mais la supervision se heurte à un vide de responsabilité. La télémétrie de sécurité couvre généralement les terminaux, les systèmes d’identité et l’infrastructure de production, tandis que l’ingénierie exploite les serveurs de build, les référentiels d’artefacts et les runners. Certains systèmes d’ingénierie peuvent rester sans supervision, laissant une partie du parcours logiciel avec des identifiants puissants et une observation plus faible que celle de la production.

Étendre la télémétrie à ces systèmes crée un problème de compréhension, car une infrastructure de build normale télécharge des dépendances, exécute des scripts, manipule des artefacts, appelle des services cloud et publie des sorties. L’activité d’ingénierie légitime peut donc se recouper avec des comportements que les défenseurs doivent examiner. Les opérations de sécurité doivent comprendre suffisamment le contexte d’ingénierie pour distinguer les deux tout en traitant le flux d’événements supplémentaire.

Castro soutient que de nombreuses équipes ne disposent pas de connaissances opérationnelles suffisantes pour faire cette distinction. « Si vous regardez la plupart des équipes de sécurité traditionnelles, elles emploient généralement peu, voire pas du tout, de personnes ayant une véritable expérience DevOps ou SRE », dit-il. « On leur demande fréquemment de superviser et de sécuriser des systèmes qu’elles n’ont jamais utilisés et qu’elles ne comprennent pas, et elles n’ont pas la confiance de leurs homologues de l’ingénierie qui craignent que l’équipe sécurité casse des choses. » L’écart est organisationnel autant que technique, car la sécurité peut être responsable de systèmes qu’elle n’a pas conçus, exploités ou utilisés régulièrement.

Cet écart organisationnel devient plus difficile à combler dans les entreprises construites par acquisitions. Chaque opération peut apporter une toolchain héritée, créant plusieurs façons de construire, stocker et publier des logiciels et rendant difficile l’imposition d’un modèle de contrôle uniforme. L’expérience antérieure de Castro comme RSSI dans deux grandes multinationales nourrit son point de vue selon lequel il s’agit d’un problème concret dans les grands environnements, tandis que la pression de livraison et l’insuffisance du support sécurité affectent les développeurs dans des entreprises de toutes tailles.

Ces contraintes donnent aux contrôles d’admission en amont un levier différent de celui de la détection en aval. Une fois qu’une dépendance inconnue s’exécute sur un runner ayant accès à des identifiants de signature ou à des tokens de comptes de service cloud, les défenseurs doivent identifier un comportement malveillant à l’intérieur d’un environnement déjà privilégié. Une politique qui décide si la dépendance peut entrer dans le build prend cette décision avant que le build n’expose ces privilèges.

L’IA supprime le point d’étranglement centralisé dont la sécurité dépendait

Les contrôles d’admission en amont deviennent plus précieux à mesure que le développement assisté par l’IA étend la création logicielle au-delà des équipes d’ingénierie dotées de plateformes CI/CD matures. Des développeurs sous pression pour livrer peuvent avoir besoin de composants qu’ils n’ont ni le temps ni l’expertise d’évaluer en profondeur, tandis que le support sécurité dont ils disposent varie fortement. « Les développeurs doivent faire ce qu’ils peuvent pour se faciliter le travail », dit Castro. « S’ils ont besoin d’une GitHub action particulière, ils vont aller la récupérer et l’exécuter, et ils doivent supposer que leur équipe sécurité fait ce qu’elle doit faire pour les protéger, même si dans de nombreux cas cela ne se passe pas réellement ainsi en coulisses. »

Les outils de code IA agentique élargissent encore la population des builders via le citizen development, où des analystes et des responsables des opérations sans expérience du code de production peuvent créer des logiciels. Une partie de ce travail se déroule en dehors des environnements et processus traditionnellement gouvernés par l’IT, y compris sur des laptops individuels qui obtiennent directement des packages depuis l’internet ouvert. Lorsque l’acquisition et l’exécution du code s’y produisent, la sécurité perd le point centralisé où une organisation pouvait appliquer de manière cohérente une politique avant l’exécution.

La perte de ce point centralisé affecte différemment plusieurs populations. Les citizen developers peuvent manquer d’expérience pour évaluer des packages ; les ingénieurs répartis dans le monde entier ont besoin de systèmes de développement accessibles depuis différents lieux ; les entreprises acquises peuvent continuer à utiliser des toolchains héritées ; et les développeurs professionnels peuvent manquer d’expertise ou de support en sécurité tout en conservant leurs responsabilités de livraison. À mesure que ces modes de travail légitimes se multiplient, une architecture de sécurité construite autour d’un environnement centralisé et standardisé couvre une part plus faible de la création logicielle.

Castro affirme que les contrôles existants de l’IT sont par conséquent insuffisants, en partie sur la base des échanges de Chainguard avec des organisations touchées par les attaques de 2026. « Ce que nous avons constaté lorsque nous avons parlé à des personnes affectées par la vague d’attaques de la supply chain cette année, c’est que souvent la seule ligne de défense dont elles disposaient était la détection et réponse sur les terminaux (EDR) traditionnelle et l’antivirus », dit-il. Les équipes d’opérations de sécurité ont alors traité à répétition des alertes de malware ou de ver et fouillé les environnements pour déterminer si des ingénieurs avaient été touchés.

Ces échanges décrivent une séquence opérationnelle précise : la consommation non restreinte de packages se produit d’abord, l’EDR ou l’antivirus observe les conséquences plus tard, et le centre des opérations de sécurité (SOC) absorbe l’enquête. Castro formule le point plus directement : « C’est le RSSI en moi qui parle, mais même si les gens emploient à tout-va des termes comme AI native, il n’y a rien de natif à l’IA dans le fait de laisser n’importe qui faire n’importe quoi et de laisser ensuite les équipes sécurité gérer les conséquences. » Son argument est que les contrôles doivent se déplacer avec l’acte d’acquérir et d’exécuter un logiciel.

L’IA modifie donc la répartition des décisions de fabrication logicielle autant que le débit du développement. Davantage de personnes et d’agents peuvent choisir des dépendances, y compris des participants dont on ne peut raisonnablement pas attendre qu’ils effectuent une revue de sécurité experte pour chaque package rencontré. Les contrôles de sécurité doivent suivre ce modèle de développement distribué en gouvernant où les logiciels sont acquis et exécutés.

Trivy montre pourquoi la découverte peut arriver trop tard

L’argument en faveur de contrôles plus en amont devient plus clair lorsqu’une compromission persiste au-delà de l’exécution immédiate du package malveillant. Les attaques de la supply chain peuvent récolter des secrets qui restent utiles après que les défenseurs ont découvert le point d’entrée, car un attaquant peut avoir collecté des identifiants distincts pour des systèmes cloud, l’infrastructure ou les données. Supprimer le composant malveillant laisse ces identifiants, utiles indépendamment, en possession de l’attaquant jusqu’à ce que les défenseurs les identifient et les invalident.

L’attaque de mars 2026 impliquant Trivy, le scanner de vulnérabilités open-source largement utilisé d’Aqua Security, illustre ce problème de persistance. Les attaquants ont récolté des clés cloud, des clés SSH, des tokens Kubernetes, des mots de passe de base de données et d’autres secrets, exposant potentiellement plus de 2 500 organisations. Ces types de secrets montrent comment la compromission d’une dépendance de développement peut créer un accès qui s’étend bien au-delà de la dépendance elle-même.

Cet accès plus large rend la séquence après la découverte critique. Aqua Security a découvert une violation antérieure et a procédé à une rotation des identifiants, mais le confinement est resté incomplet ; les attaquants ont conservé leur accès, et cet accès a contribué à permettre une attaque ultérieure de la chaîne d’approvisionnement. La rotation des identifiants a répondu à la découverte, mais la compromission antérieure avait créé des chemins qui exigeaient un confinement supplémentaire.

Trivy met donc à l’épreuve une approche qui fait porter l’essentiel de la charge sur la détection et la réponse. Une fois les secrets récoltés, les défenseurs doivent comprendre et invalider ce que l’attaquant a acquis à travers les comptes cloud, les accès SSH, les environnements Kubernetes, les bases de données et d’autres systèmes. Empêcher un artefact suspect d’obtenir cette position initiale offre un levier différent, car cela peut empêcher que l’opportunité de récolter des identifiants n’apparaisse.

La provenance transforme la confiance en amont en quelque chose que les pipelines peuvent appliquer

Ce levier préventif sous-tend le modèle défendu par Castro, qui déplace la décision de confiance avant l’exécution. « Les organisations ont besoin d’une manière radicalement différente de traiter la sécurité de la supply chain, centrée au moins autant sur la prévention que sur la détection et la réponse », dit-il. « L’objectif devrait être d’empêcher les packages compromis d’entrer dans l’environnement dès le départ. » La détection reste nécessaire, tandis qu’une décision de confiance en amont peut réduire le nombre d’artefacts non fiables que les défenseurs devront ensuite observer à l’intérieur de systèmes privilégiés.

L’échelle rend ces décisions de confiance difficiles à prendre manuellement. Castro s’attend à ce que le volume open-source continue de croître tandis que le vibe coding, c’est-à-dire le développement logiciel principalement en pilotant des outils de code IA, augmente le nombre d’agents et d’utilisateurs moins qualifiés confrontés à des packages. « Nous entrons dans un monde d’open-source illimité, et cela ne va pas disparaître », dit-il. « Par ailleurs, le volume de code et l’essor du vibe coding exposent des agents et des utilisateurs moins qualifiés à des packages malveillants ressemblants et à des attaques de typo-squatting. »

Cette échelle rend la provenance utile, car elle attache à l’artefact lui-même des preuves sur son origine et sa production. Une provenance vérifiée, des artefacts signés et des systèmes de build de confiance permettent à un pipeline d’évaluer des preuves définies avant d’accepter un package, tandis que la revue humaine peut se concentrer sur la politique et les exceptions. À mesure que la consommation de packages augmente, la validation à la vitesse machine permet à la décision de confiance de passer à l’échelle avec la création logicielle automatisée.

Les preuves cryptographiques rendent alors la question de la confiance plus précise. « Vous voulez valider que ce que vous intégrez à votre pipeline de build est exactement ce que cela est censé être, pas simplement vous fier à la parole de quelqu’un, mais pouvoir le prouver cryptographiquement », dit Castro. « Vous voulez aussi savoir que cela a été construit dans un environnement sécurisé et que rien n’y a été glissé au dernier moment. » La politique qui en résulte peut évaluer l’identité et l’intégrité de l’artefact ainsi que les conditions dans lesquelles il a été produit.

Chainguard a un intérêt commercial direct dans cette prescription, car l’entreprise en bénéficie lorsque les organisations adoptent ce modèle. Son activité comprend l’approvisionnement, l’analyse, la sécurisation et la reconstruction de packages open-source et d’images de conteneurs, puis leur distribution avec provenance afin que les clients puissent prendre une décision de confiance sur un artefact avant le déploiement. L’approche déplace une partie de la charge de sécurité vers la plateforme de développement : la plateforme fournit des preuves, et le pipeline décide si un artefact répond aux exigences de l’organisation.

Cet alignement commercial donne aux lecteurs un contexte important pour la recommandation de Castro. En tant que RSSI de Chainguard, il représente une entreprise qui vend des services construits autour du type de confiance dans les artefacts qu’il défend. Le mécanisme qu’il décrit est concret : la provenance fournit des données qu’une politique automatisée peut vérifier avant qu’un artefact ne s’exécute, déplaçant la décision plus tôt que ne peuvent agir l’EDR, l’antivirus ou la réponse à incident.

Des plateformes de développement sécurisées peuvent rétablir le contrôle dans un développement distribué

La provenance gouverne l’admission des artefacts, tandis que l’environnement de développement qui l’entoure peut limiter ce que les builders consomment et ce que du code compromis peut atteindre. Le stack proposé par Castro comprend des référentiels d’artefacts configurés et des outils CI/CD appropriés, ainsi que des actions, runners, compétences et composants intrinsèquement sécurisés et durcis. « Un attaquant pourra peut-être faire de mauvaises choses », dit-il, « mais il devra travailler beaucoup plus dur et, entre-temps, vous aurez donné beaucoup plus d’avantages à vos défenseurs. »

Cette réserve fixe l’objectif : augmenter les coûts pour l’attaquant et réduire les chemins disponibles. Un stack contraint peut limiter l’exposition à des packages arbitraires et à des composants de build faibles, tandis que des runners et des actions durcis réduisent les opportunités disponibles après qu’un élément hostile a réussi à passer. Les défenseurs gagnent en levier en déterminant les conditions dans lesquelles le développement se déroule avant qu’un incident n’oblige le SOC à reconstituer ces conditions après coup.

Ces conditions incluent aussi le lieu d’exécution. La sécurité peut proposer un environnement cloud supervisé avec les ressources dont les développeurs ont besoin, en maintenant le travail expérimental assisté par l’IA dans une infrastructure que l’organisation peut observer et en réduisant la part dispersée sur des laptops individuels. Les builders peuvent toujours expérimenter, tandis que la sécurité conserve de la visibilité sur l’environnement où s’exécutent les packages, les outils et le code généré.

Rendre cet environnement praticable exige que la sécurité le construise avec les équipes d’ingénierie et de site reliability engineering (SRE), car ces équipes comprennent les systèmes qui font fonctionner le processus de développement. Castro affirme qu’une collaboration proactive peut soutenir la sécurité de la chaîne d’approvisionnement logicielle et la sécurité applicative tout en permettant l’adoption de l’IA, la transformation numérique et l’innovation. Pour une organisation avec des équipes distribuées, des citizen developers et des toolchains héritées, la frontière scalable devient ce que les builders et les agents IA sont autorisés à considérer comme fiable et où ils sont autorisés à l’exécuter.

En conclusion

Pour les dirigeants, la chaîne d’approvisionnement logicielle devient autant un problème de contrôle métier qu’un problème d’ingénierie de la sécurité. Le développement assisté par l’IA augmente le nombre de personnes, d’agents et d’environnements capables de sélectionner et d’exécuter des logiciels tiers, tandis que les systèmes de build peuvent exposer des identifiants et des privilèges capables d’aller bien au-delà d’une seule application. Cette combinaison fait de la détection en aval un contrôle incomplet.

La décision de direction est donc de savoir où l’organisation veut appliquer la confiance. L’EDR, l’analyse des vulnérabilités et la réponse à incident restent nécessaires, mais ils interviennent après qu’un logiciel est entré dans un environnement ou a commencé à s’exécuter. La provenance, des sources d’artefacts de confiance, une infrastructure de build durcie et des politiques d’admission peuvent déplacer une partie de cette décision plus tôt, avant qu’un composant inconnu n’obtienne l’accès à des systèmes et identifiants de valeur.

Ce changement exige aussi une coordination entre les équipes sécurité, ingénierie, SRE et plateforme. Les dirigeants doivent savoir où les logiciels sont acquis, quels environnements de build peuvent accéder à des identifiants sensibles, quelles preuves sont requises avant qu’un artefact ne s’exécute et si le développement assisté par l’IA en dehors de l’ingénierie traditionnelle suit les mêmes règles. Les acquisitions et le développement décentralisé rendent l’uniformisation des outils difficile, mais ils augmentent la valeur d’une politique de confiance cohérente.

À mesure que l’IA réduit le coût de création des logiciels, les organisations doivent s’attendre à ce que le volume des dépendances et l’activité de la chaîne d’approvisionnement logicielle continuent d’augmenter. La réponse scalable n’est pas de demander à chaque développeur ou agent IA de porter des jugements de sécurité experts. Elle consiste à intégrer ces jugements dans les plateformes et les politiques qui déterminent quels logiciels l’organisation considère comme fiables et où elle autorise leur exécution.