Pourquoi l’IA de pointe change les règles de la sécurité logicielle

Frontier AI redéfinit la sécurité de la chaîne d’approvisionnement logicielle en accélérant la détection des vulnérabilités

La sécurité logicielle est entrée dans une nouvelle phase. L’importance de « Mythos » d’Anthropic ne réside pas seulement dans le fait qu’il s’agisse d’un énième modèle d’IA avancé. Cela montre que l’IA est désormais capable de détecter des vulnérabilités logicielles au sein de bases de code gigantesques, avec une intervention humaine très limitée. Cela modifie la dynamique économique de la cybersécurité.

Pendant des années, les organisations ont fonctionné selon un postulat simple : la détection de failles logicielles graves nécessitait l’intervention de chercheurs hautement qualifiés, qui y consacraient des semaines, voire des mois de travail. Ce postulat a influencé tous les aspects, des budgets de sécurité aux calendriers de correctifs, en passant par les cadres de gestion des risques. L’IA bouleverse cette donne. Les vulnérabilités cachées au sein des bibliothèques open source, les dépendances imbriquées et les piles logicielles complexes peuvent désormais être identifiées bien plus rapidement que ne le permettaient les outils de sécurité traditionnels.

Cela revêt une importance particulière, car les entreprises modernes s’appuient fortement sur les logiciels libres. Chaque application contient des centaines, voire des milliers de composants externes. De nombreuses organisations ne maîtrisent pas pleinement l’ensemble des dépendances qu’elles déploient en production. Les outils d’analyse traditionnels identifient les problèmes connus, mais ils passent souvent à côté des failles enfouies au plus profond des chaînes de dépendances. L’intelligence artificielle améliore à la fois la rapidité et la profondeur de la détection des vulnérabilités, ce qui facilite considérablement la mise en évidence de failles auparavant négligées.

Il en résulte que le délai entre l’apparition d’une vulnérabilité et la première tentative d’exploitation de celle-ci se réduit considérablement. Les équipes de sécurité ne disposent plus de la même marge de manœuvre qu’auparavant pour mener leurs enquêtes, établir des priorités et mettre en œuvre des mesures correctives. Cela oblige les organisations à repenser leur manière d’évaluer le risque acceptable.

Quincy Castro, directeur de la sécurité chez Chainguard, décrit clairement cette évolution. Il déclare : « L’IA a complètement bouleversé cette dynamique. Nous sommes face à un monde sur le point d’être submergé par de nouvelles vulnérabilités « zero-day », et potentiellement par de nouvelles catégories de vulnérabilités que les êtres humains n’ont pas encore été en mesure de découvrir. Les vulnérabilités « zero-day » sont désormais beaucoup plus courantes. »

Les investissements existants en matière de sécurité ont été mis en place sur la base d’hypothèses qui ne sont peut-être plus valables. Les modèles de gouvernance, les processus opérationnels et les discussions sur les risques au sein de la direction doivent tenir compte d’un monde où la découverte de vulnérabilités ne cesse de s’accélérer. Les organisations qui s’adapteront rapidement bénéficieront d’un avantage significatif par rapport à celles qui continueront à fonctionner avec des modèles de sécurité conçus pour un environnement de menaces moins dynamique.

Les assistants de programmation basés sur l’IA élargissent la surface d’attaque tout en accélérant le processus d’exploitation

Les assistants de programmation basés sur l’IA améliorent considérablement la productivité du développement logiciel. Les équipes peuvent ainsi développer des fonctionnalités plus rapidement, publier des mises à jour plus fréquemment et permettre à davantage de collaborateurs de participer à la création de logiciels. Il s’agit là d’une opportunité majeure. Cela pose toutefois un nouveau défi en matière de sécurité.

Chaque nouvelle application, dépendance, script d’automatisation ou bibliothèque open source ajoute à la complexité. L’IA accélère le développement logiciel, ce qui signifie que la quantité de code mis en production augmente bien plus rapidement qu’auparavant. Les processus de sécurité reposant sur des analyses périodiques et des vérifications manuelles peinent à suivre le rythme de cette évolution.

L’IA permet également d’identifier plus facilement les vulnérabilités que les équipes de sécurité considéraient auparavant comme peu prioritaires. Prises isolément, ces failles peuvent sembler gérables. Combinées, elles peuvent toutefois constituer des vecteurs d’attaque efficaces lorsque l’IA aide les pirates à associer plusieurs failles au sein d’une attaque coordonnée.

Cela modifie la manière dont les organisations doivent aborder la hiérarchisation des risques. Les équipes de sécurité ne peuvent plus partir du principe que les vulnérabilités de faible gravité resteront difficiles ou coûteuses à exploiter. L’intelligence artificielle réduit l’effort nécessaire pour détecter et combiner les failles, ce qui rend une part bien plus importante du paysage des vulnérabilités pertinente sur le plan opérationnel.

Cette tendance se confirme déjà dans la pratique. Des chercheurs ont identifié une nouvelle catégorie de vulnérabilités liées aux workflows CI/CD, baptisée « Cordyceps ». Ces failles peuvent permettre à des pirates de compromettre les workflows de développement logiciel et de prendre le contrôle des dépôts de code au sein d’organisations telles que Microsoft, Google, Apache et Cloudflare.

Les exemples sont concrets. Dans le cadre du projet Azure Sentinel de Microsoft, un commentaire sur une pull request pouvait permettre d’exécuter du code contrôlé par un attaquant au sein de l’environnement d’intégration continue (CI) de Microsoft et de voler une clé d’application GitHub sans date d’expiration. Dans le kit de développement d’agents IA de Google (« adk-samples »), une pull request pouvait exécuter du code malveillant au sein de l’infrastructure de CI de Google et obtenir un contrôle total sur un dépôt Google Cloud.

L’écosystème logiciel dans son ensemble subit déjà les conséquences des attaques visant la chaîne d’approvisionnement. GitHub a révélé que des pirates avaient compromis son environnement après qu’un développeur eut installé une extension malveillante de Visual Studio Code. Le groupe de pirates TeamPCP a affirmé avoir accédé à environ 4 000 dépôts GitHub. Ce groupe a également désigné OpenAI et la société de sous-traitance de données Mercor comme victimes supplémentaires et a revendiqué la responsabilité de 20 campagnes d’attaques par la chaîne d’approvisionnement qui ont permis d’injecter des logiciels malveillants dans plus de 500 progiciels.

Quincy Castro, directeur de la sécurité chez Chainguard, met en avant un autre défi opérationnel. Chaque correctif d’urgence engendre son propre risque pour l’entreprise. Il explique : « Chaque fois que vous déclenchez ce processus de correctif d’urgence, vous prenez le risque de perturber une partie des ressources déployées. Vous vous retrouvez soudainement confronté à un choix : soit laisser vos clients exposés à une vulnérabilité grave, soit perturber le fonctionnement du produit pour lequel ils ont payé. »

Pour les dirigeants, la conclusion est claire. Accélérer le développement logiciel est un atout, mais cela ne peut pas reposer sur des modèles de sécurité conçus pour des cycles de mise en production plus lents. Les entreprises ont besoin de pratiques de sécurité qui fonctionnent en continu et s’adaptent au développement piloté par l’IA. La sécurité ne peut plus être considérée comme une simple étape de contrôle à la fin du développement. Elle doit faire partie intégrante du processus de création des logiciels dès le début.

Les récentes attaques visant la chaîne d’approvisionnement montrent que les environnements de développement logiciel sont désormais des cibles de premier plan

Les attaques visant la chaîne d’approvisionnement logicielle ne constituent plus des incidents isolés. Elles sont devenues un moyen concret et de plus en plus efficace pour les pirates d’accéder aux systèmes des entreprises. Plutôt que d’attaquer directement une entreprise, les pirates ciblent les outils de développement de confiance, les composants open source ou les processus de déploiement logiciel dont dépendent de nombreuses organisations.

Cette approche offre aux attaquants un levier considérable. Une seule dépendance, un seul outil de développement ou un seul workflow CI/CD compromis peut affecter des milliers d’utilisateurs en aval. À mesure que les organisations s’appuient de plus en plus sur des écosystèmes logiciels partagés, l’impact de ces attaques s’étend bien au-delà de la cible initiale.

GitHub a révélé que des pirates avaient compromis une partie de sa chaîne logistique logicielle après qu’un de ses développeurs eut installé une extension malveillante de Visual Studio Code. Le groupe de pirates TeamPCP a affirmé avoir accédé à environ 4 000 dépôts GitHub.

TeamPCP a identifié OpenAI et la société de sous-traitance de données Mercor parmi les autres victimes. Le groupe a par ailleurs revendiqué la responsabilité de 20 campagnes distinctes d’attaques visant la chaîne d’approvisionnement, qui ont permis d’introduire des logiciels malveillants dans plus de 500 progiciels. Bien que les organisations doivent vérifier de manière indépendante les affirmations des acteurs malveillants, ces incidents montrent à quel point les attaquants se concentrent de plus en plus sur les écosystèmes de développement logiciel plutôt que sur les terminaux traditionnels.

Pour les dirigeants, la leçon est claire. La confiance ne peut plus reposer uniquement sur le fait que le logiciel provienne d’une source connue. Les organisations doivent comprendre d’où proviennent les composants logiciels, comment ils sont développés, comment ils sont maintenus, et si leur intégrité peut être vérifiée tout au long du processus de développement. La provenance logicielle, c’est-à-dire la capacité à vérifier l’origine et l’historique de développement d’un logiciel, devient une capacité stratégique plutôt qu’une simple fonctionnalité technique.

Cela modifie également la gestion des risques liés aux tiers. Les évaluations des fournisseurs ne doivent pas se limiter à des questionnaires de conformité, mais doivent également permettre d’avoir une visibilité sur les pratiques de développement, la gestion des dépendances, la signature des logiciels et la sécurité des processus de compilation. À mesure que les chaînes d’approvisionnement logicielles deviennent de plus en plus interconnectées, les failles au sein d’une organisation peuvent rapidement avoir des répercussions sur de nombreuses autres.

Les modèles de sécurité réactifs s’avèrent désormais trop lents face aux menaces liées à l’IA

De nombreux programmes de sécurité d’entreprise reposent encore sur des calendriers prévisibles. Les vulnérabilités critiques sont traitées en priorité, les cycles de correctifs suivent des calendriers établis et les cadres de conformité définissent des délais de correction acceptables. Ces approches ont été mises au point à une époque où la découverte des vulnérabilités et le développement d’exploits nécessitaient un effort humain considérable.

L’IA remet cette hypothèse en cause. Elle permet aux pirates d’identifier plus rapidement les vulnérabilités, de comprendre comment les systèmes sont interconnectés et de mettre au point des vecteurs d’exploitation qui nécessitaient auparavant une expertise pointue. À mesure que ces capacités se généralisent, l’écart entre la découverte d’une vulnérabilité et son exploitation ne cesse de se réduire.

Cela rend la sécurité réactive traditionnelle de plus en plus inefficace. Les organisations acceptent souvent certaines vulnérabilités parce que le risque d’exploitation semble faible ou parce que leur correction perturberait leurs activités. L’IA modifie ce raisonnement en rendant bon nombre de ces risques, auparavant acceptés, plus faciles à traiter.

Quincy Castro, directeur de la sécurité chez Chainguard, remet en question l’idée selon laquelle la sécurité peut être gérée principalement à l’aide de délais de mise en conformité fixes. Il déclare : « La cyberdéfense n’est pas une simple liste de contrôle lorsqu’elle est menée efficacement. L’adversaire a lui aussi son tour de rôle. Si vous pensez qu’un délai de 30 jours pour corriger une vulnérabilité critique est suffisant, vous serez à chaque fois perdant dans ce calcul. »

Son point de vue reflète une évolution plus générale de la stratégie en matière de cybersécurité. La conformité reste importante, mais elle ne suffit pas à elle seule à offrir une protection contre des attaquants qui s’adaptent sans cesse. Les organisations qui considèrent les exigences réglementaires comme un objectif final plutôt que comme une base minimale risquent de se retrouver de plus en plus exposées.

M. Castro fait également valoir que les responsables de la sécurité ont une responsabilité importante qui va au-delà de la technologie. Selon lui, les dirigeants ne prennent pas toujours immédiatement conscience de la manière dont l’IA modifie le paysage des menaces ; il est donc essentiel que les équipes de sécurité communiquent ces changements en termes compréhensibles pour l’entreprise. Les conseils d’administration et les équipes de direction doivent comprendre que l’IA a une incidence sur le risque opérationnel, la résilience, les priorités d’investissement et la continuité des activités à long terme.

Pour les dirigeants, les implications sont considérables. La sécurité doit devenir une capacité opérationnelle permanente plutôt qu’une activité opérationnelle ponctuelle. Une détection plus rapide, une réaction plus rapide et des contrôles préventifs plus efficaces seront plus importants que le simple respect des délais de mise en conformité. Les organisations qui adaptent dès à présent leurs stratégies de gouvernance et d’investissement seront mieux armées face à l’accélération, induite par l’IA, tant du développement logiciel que des cybermenaces.

La sécurité doit être intégrée dès le départ dans les logiciels

Les entreprises ne peuvent pas résoudre les défis de sécurité liés à l’IA en se contentant d’ajouter davantage d’outils de sécurité, de renforcer leurs équipes chargées de la sécurité des applications ou d’intensifier les vérifications manuelles. Ces approches ne traitent que les symptômes et non le problème sous-jacent. À mesure que l’IA accélère à la fois le développement logiciel et la détection des vulnérabilités, le volume de travail lié à la sécurité continuera d’augmenter à un rythme supérieur à ce que les entreprises peuvent raisonnablement gérer.

Il faudrait plutôt s’attacher à instaurer la confiance dans les logiciels avant même que le développement ne commence. Cela implique de partir de composants open source vérifiés, de garantir une traçabilité claire des logiciels, de mettre à jour en permanence les dépendances et d’éliminer, dans la mesure du possible, les paquets inutiles ou non vérifiés. Si les logiciels intégrés au processus de développement sont fiables dès le départ, le nombre de problèmes de sécurité en aval peut être considérablement réduit.

Cette approche reflète également l’évolution du développement logiciel. Les outils de développement basés sur l’IA permettent désormais à des collaborateurs n’appartenant pas aux équipes d’ingénierie traditionnelles de créer des applications internes et d’automatiser des processus métier. Un professionnel de la finance, des opérations ou du marketing peut désormais créer des logiciels sans posséder de connaissances approfondies en matière de cybersécurité ou de pratiques de codage sécurisées. Cela ouvre de nouvelles perspectives en termes de productivité, mais souligne également l’importance de faire du développement sécurisé la norme, plutôt que d’attendre de chaque utilisateur qu’il devienne un expert en sécurité.

Quincy Castro, responsable de la sécurité chez Chainguard, illustre ce point à l’aide d’un exemple concret. Évoquant le cas d’un employé du service financier qui développe une application interne, il explique : « Larry, du service financier, n’a pas d’équipe SRE ni de spécialistes de la sécurité des applications pour le surveiller. Il essaie simplement de faire son travail. La seule façon de procéder en toute sécurité, au sein d’une entreprise traitant des dossiers médicaux ou des documents financiers sensibles, est que les composants qu’il utilise soient intrinsèquement sûrs et fiables. Il ne devrait pas avoir à s’en soucier. La confiance doit être intégrée en amont. »

La simplification de la sécurité devrait devenir un objectif stratégique. Au fil du temps, de nombreuses organisations ont accumulé une multitude d’outils d’analyse, de moteurs de règles, de processus d’approbation manuels et de workflows de correction. Si chaque mesure de contrôle a pu répondre à un besoin spécifique, leur combinaison peut ralentir le développement tout en laissant des risques importants sans solution.

Plutôt que d’ajouter une couche supplémentaire de complexité, les organisations devraient réduire le nombre de décisions en matière de sécurité que les développeurs doivent prendre au cours du processus de développement logiciel. Des paramètres par défaut sécurisés, des composants logiciels vérifiés, l’application automatisée des politiques et des environnements de compilation fiables permettent aux équipes d’ingénierie d’avancer rapidement tout en garantissant des résultats plus solides en matière de sécurité. Cela réduit les frictions opérationnelles et permet aux équipes de sécurité de se concentrer sur des tâches à plus forte valeur ajoutée plutôt que de gérer un arriéré de vulnérabilités qui ne cesse de croître.

M. Castro estime que cette évolution devient de plus en plus urgente à mesure que les modèles d’IA de pointe continuent de s’améliorer. Il déclare : « Nous n’avons même pas encore exploré les nouvelles catégories de vulnérabilités qui vont nécessiter une refonte en profondeur des protocoles largement utilisés. Il n’y a pas suffisamment de ressources dans le monde pour s’attaquer à ces problèmes par des moyens traditionnels. Plutôt que de répondre à la complexité par davantage de complexité, nous devons y faire face par la simplicité. »

Il conclut en attribuant la responsabilité aux dirigeants : « Les dirigeants doivent prendre les devants face à ces problèmes et adopter une approche proactive pour intégrer la sécurité dans les systèmes dont ils ont la charge. Nous ne voulons pas continuer à investir dans des solutions qui nous font déjà défaut. »

Pour les dirigeants de haut niveau, il s’agit en fin de compte d’une décision stratégique en matière de gouvernance plutôt que d’une simple décision technique. Les investissements en matière de sécurité devraient accorder une priorité croissante à l’intégrité des logiciels, à la fiabilité des chaînes d’approvisionnement, à la sécurité des plateformes de développement et à l’automatisation permettant d’empêcher les vulnérabilités d’atteindre l’environnement de production. Les organisations qui intègrent la sécurité dans le processus de création logicielle seront mieux à même de favoriser une innovation plus rapide tout en gérant les risques croissants liés au développement piloté par l’IA.

Principaux enseignements pour les dirigeants

• L’IA a bouleversé la dynamique économique de la cybersécurité : elle est désormais capable de détecter des vulnérabilités dans de vastes bases de code bien plus rapidement que les équipes de sécurité traditionnelles, ce qui réduit le délai entre la découverte et l’exploitation de ces failles. Les dirigeants doivent réévaluer les modèles de risque, les priorités en matière de correctifs et les investissements en sécurité qui partent du principe que les attaquants agissent plus lentement.
• Un développement logiciel plus rapide nécessite une sécurité intégrée plus solide : les assistants de codage basés sur l’IA augmentent la productivité, mais accroissent également le volume de code, les dépendances et les vecteurs d’attaque potentiels. Les organisations devraient intégrer la sécurité dans le cycle de vie du développement plutôt que de se contenter d’analyses périodiques et de correctifs réactifs.
• La sécurité de la chaîne d’approvisionnement logicielle constitue désormais un risque relevant du conseil d’administration : les récentes attaques visant les outils de développement, les référentiels et les écosystèmes open source montrent que des logiciels jugés fiables peuvent devenir un point d’entrée pour des compromissions à grande échelle. Les dirigeants doivent renforcer la traçabilité des logiciels, la gestion des risques liés aux tiers et les pratiques de compilation sécurisées tout au long de leurs chaînes d’approvisionnement.
• La conformité à elle seule ne suffit plus : l’intelligence artificielle permet aux pirates d’identifier et de combiner les vulnérabilités beaucoup plus rapidement, ce qui rend moins efficaces les calendriers de correctifs traditionnels et les mesures de sécurité basées sur des listes de contrôle. Les dirigeants doivent considérer la cybersécurité comme une capacité opérationnelle continue, s’appuyant sur une détection et une réaction plus rapides, ainsi que sur des contrôles préventifs.
• La simplicité et la sécurité intégrée dès la conception doivent devenir des priorités stratégiques : l’ajout d’outils de sécurité supplémentaires ne sera pas adapté au développement logiciel piloté par l’IA. Les organisations doivent privilégier les composants logiciels fiables, les paramètres par défaut sécurisés et les contrôles automatisés qui réduisent la complexité tout en permettant aux équipes d’innover en toute sécurité.