Pour que le secteur puisse continuer à partager des logiciels, il doit disposer d’un système fiable permettant de signaler et de suivre les paquets compromis.
Bien que les logiciels open source soient plus nombreux que jamais, leur utilisation n’a jamais présenté autant de risques. Pourquoi ? Parce que de récents rapports sur l’empoisonnement de paquets montrent que l’analyse du code source dans un dépôt public ne garantit pas que le paquet distribué est sûr.
Puisque nous supposons que les paquets sont sûrs alors qu’il est démontré qu’ils ne le sont pas, l’écosystème de la chaîne d’approvisionnement logicielle se retrouve exposé. Les artefacts de compilation, les paquets, les pipelines, les points de distribution des paquets et les mécanismes d’installation sont régulièrement détournés à des fins malveillantes.
Plus le paquet est populaire, plus les dégâts se produisent rapidement. À l’heure actuelle, nous constatons que les outils d’IA sont les principales cibles de ces empoisonnements, tandis que les agents d’IA en amplifient les dommages à une telle vitesse que l’on peut affirmer sans risque que le secteur est dépassé par la compromission des paquets.
Ce que nous avons fait ne nous permettra pas d’y parvenir
L’écosystème des logiciels open source ne dispose d’aucun registre officiel recensant les paquets logiciels compromis. Les organisations ne disposent donc d’aucun système fiable leur permettant d’accorder leur confiance aux paquets de code qu’elles utilisent. En outre, les pipelines de compilation, les processus d’installation et les dépôts de paquets partent du principe que les logiciels sont sûrs plutôt que compromis. L’automatisation et les agents d’IA aggravent et accélèrent ce risque à la vitesse des machines.
Pour relever ce nouveau défi, l’écosystème des logiciels open source a besoin des éléments suivants :
- Une collaboration à l’échelle du secteur afin de signaler les paquets compromis en s’appuyant sur une source unique de référence.
- Effort ciblé visant à combler les failles de sécurité dans la chaîne d’approvisionnement logicielle de l’écosystème.
- Engagement de l’écosystème à élaborer, promouvoir et mettre en œuvre les meilleures pratiques du secteur.
Une culture fondée sur l’apprentissage et l’amélioration continus constitue une défense redoutable. Nous ne devons jamais cesser de renforcer la sécurité de notre écosystème de code source, de nos pipelines de compilation et de nos dépôts de paquets.
Bien démarrer
Nous disposons d’une solution qui se rapproche de ce dont nous avons besoin. Elle est hébergée par l’Open Source Security Foundation (OpenSSF) et s’appelle le Malicious Packages Repository (MPR). Elle offre un espace et un processus centralisés pour définir et signaler les paquets malveillants. Pour devenir la norme de facto en matière de suivi et de correction des paquets compromis, elle doit bénéficier d’une large participation de l’ensemble du secteur.
Le MPR utilise une spécification de fichier exploitable par les machines, appelée format Open Source Vulnerability (OSV), qui s’appuie sur JSON pour automatiser l’envoi et la collecte des rapports, ainsi que pour alimenter les outils d’analyse. Ce format prend en charge une procédure spécifique permettant aux chercheurs de confiance de fournir de nouvelles données en continu, rapidement et efficacement. Enfin, il est géré par un groupe de travail actif, ouvert à de nouveaux contributeurs et à des améliorations.
Nous avons besoin d’un dispositif comme le MPR de l’OpenSSF, qui cible les paquets empoisonnés, afin de leur appliquer ce que le programme CVE fait déjà pour les vulnérabilités du code source. Le changement commence par la reconnaissance de la situation actuelle, et c’est certainement ce qui a motivé la création du MPR de l’OpenSSF. Ainsi, même si le travail a commencé, il reste encore beaucoup à faire avant qu’il ne devienne aussi utile que la base de données CVE. En tant que secteur, nous pouvons et devons collaborer pour rendre notre écosystème logiciel commun plus fiable.
À propos de l’auteur
Articles de blog associés
Top 10 des risques liés à la mise en production d’applications d’IA : manque de sécurité et de conformité réglementaire
L’IA étend la conformité au-delà de la sécurisation des chemins d’accès et des espaces de stockage pour englober la gouvernance du comportement à l’exécution — accès aux modèles, contexte de récupération, résultats et actions des agents —, de sorte que les contrôles doivent être rapprochés de l’inférence.
Top 10 de la livraison d’applications d’IA : contrôles du trafic insuffisants
Les limites de débit et les mécanismes de régulation traditionnels ne tiennent pas compte de l’étendue réelle des répercussions. Les charges de travail d’IA se répartissent entre les modèles, les bases de données vectorielles et les services, provoquant des pics de latence, des défaillances en cascade et des nouvelles tentatives.
Comportements et limites : le tournant de la sécurité agentique
Les agents génèrent des séquences émergentes et non bornées, au fil desquelles les risques s’accumulent. La sécurité doit passer de la validation de requêtes individuelles à une gouvernance comportementale continue couvrant des flux évolutifs en plusieurs étapes.
Compétences des agents : un standard ouvert émergent
Les skills expriment une intention, mais n’imposent aucun contrôle. La véritable sécurité doit se situer à la frontière des outils, là où les réflexions des agents se transforment en actions et où les politiques peuvent être appliquées.
Des paquets aux prompts : l’inférence ajoute une nouvelle couche à la pile
L’inférence n’est ni de l’entraînement, ni de l’expérimentation, ni un exercice de science des données. Elle correspond au comportement d’exécution en production et fonctionne comme une couche applicative.