Sécurité logicielle : l’IA règle le problème… ou le déplace ?

Par Yoav Landman, CTO et cofondateur de JFrog

Lorsque Anthropic a annoncé les nouvelles fonctionnalités de scan de sécurité de Claude Code, à la suite du lancement d'Aardvark par OpenAI, cela a marqué un tournant important pour le secteur. Pour la première fois, l'examen de sécurité par des experts est directement intégré au processus d'écriture du code. Les vulnérabilités subtiles, dépendantes du contexte, peuvent désormais être signalées dès leur création. Les vulnérabilités zero-day peuvent ainsi potentiellement être corrigées avant même d'être intégrées dans une version.

Et cela ne s'arrêtera pas à Anthropic. Cette annonce ne restera sans doute pas isolée : elle annonce une évolution plus large du marché, à laquelle d’autres fournisseurs d’IA, commerciaux comme open source, seront amenés à se conformer. La détection et la correction des vulnérabilités au niveau du code deviendront largement accessibles. Avec le temps, cela pourrait même devenir monnaie courante.

Mais voici la question plus profonde : si l'IA peut rendre le code plus sûr avant sa compilation, que reste-t-il à sécuriser ?

La disparition discrète du code

Dans le modèle traditionnel de développement logiciel, le code source était au centre de tout. C'était ce que les équipes analysaient, testaient et sécurisaient, et ce sur quoi elles collaboraient. Mais un changement subtil est en train de s'opérer : le code n'est plus le produit final. Il s'agit désormais d'une étape intermédiaire.

Le résultat réel, c'est-à-dire ce qui est livré, déployé et exécuté, est un artefact binaire. Une image de conteneur. Un paquet. Une bibliothèque. Une version compilée.

Une grande partie de ce qui influe finalement sur le comportement, la sécurité, les performances et la conformité d'une version n'est pas du tout écrite par l'équipe de développement ou l’agent de codage. Dans les logiciels modernes, la majorité de ce qui est intégré dans un artefact livré provient d'ailleurs :

- De dépendances open source

- De paquets tiers

- Des bibliothèques internes développées par l'organisation

- Des bibliothèques transitives profondes résolues par des gestionnaires de paquets

- Des systèmes de compilation, compilateurs et extensions de développeurs

- Et désormais, des artefacts d'IA tels que les skills, les agents, les plugins et les serveurs MCP

Une application n’est plus une simple base de code. C’est un assemblage complexe issu d’une chaîne d’approvisionnement logicielle mondialisée. Et le centre de gravité s'est déplacé du code source vers l'artefact qui intègre tout ce qui l'entoure.

Ainsi, si l'IA rend le code source plus propre, la version elle-même devient plus complexe. Cette complexité modifie également les risques.

Même lorsque le code est parfait, la version reste vulnérable

À court terme, le code généré par l’IA pourrait atteindre un niveau proche de la perfection. Il se compile sans erreur, passe avec succès l’analyse statique et corrige automatiquement les vulnérabilités avant même qu’elles ne soient détectées. À la lecture du code source, tout semble parfaitement sain.

Mais une fois le code compilé, la version ne se compose plus uniquement de ce que l'équipe ou l'IA a écrit. Elle comprend des dizaines, voire des centaines, de binaires tiers. L'un d'entre eux peut contenir une vulnérabilité récemment divulguée. Un autre peut contenir un code malveillant délibérément conçu pour échapper à la détection.

Dans des scénarios plus avancés, les attaquants peuvent même utiliser l'IA pour créer des charges utiles spécialement conçues pour contourner les systèmes d'inspection basés sur l'IA. La même technologie qui aide les défenseurs peut être transformée en un outil offensif, générant une logique obscurcie, des déclencheurs contextuels ou des portes dérobées dormantes qui se fondent dans des modèles de code légitimes. 

Et du jour au lendemain, la production est exposée. Le code généré ne présentait aucun problème. Le problème réside dans une dépendance que vous n’avez pas écrite. 

C'est exactement ce qui s'est passé lors des incidents avec React2Shell ou Log4Shell. Les équipes de production ne se sont pas précipitées parce que la révision du code avait échoué. Elles se sont précipitées parce qu'elles ne savaient pas que les versions déployées contenaient le binaire vulnérable. Le défi ne résidait pas dans la qualité du code, mais dans la visibilité du binaire. Log4Shell a montré pourquoi les SBOM sont importantes : il est indispensable de savoir quels composants existent dans chaque version. Mais leur présence seule ne suffit pas, il faut également déterminer si la vulnérabilité est réellement accessible dans le binaire.

Aujourd'hui, il s'agit également d'une obligation légale. En vertu du règlement européen sur la cyber-résilience (CRA), les organisations doivent suivre leurs logiciels commercialisés et signaler sans délai les vulnérabilités connues. L’incapacité d’identifier immédiatement les versions concernées et d’en évaluer l’exploitabilité expose à des risques, tant techniques que juridiques. 

Dans un monde axé sur l'IA, le goulot d'étranglement n'est pas l'écriture d'un code sécurisé. Il s'agit de savoir ce qui a été commercialisé.

Deux mondes de défense

L'annonce d'Anthropic renforce un niveau critique : la défense au niveau du code. Ce niveau consiste à prévenir les vulnérabilités au moment de la création. Il est proactif, contextuel et de plus en plus assisté par l'IA.

Une autre couche qui coexiste avec la sécurité du code source est la gouvernance au niveau binaire, qui sert à la fois de source unique de vérité et de gardienne de la chaîne d'approvisionnement logicielle. Une fois que le code est compilé, packagé et distribué, il devient autre chose. Il devient un artefact qui circule entre les référentiels, les pipelines, les ordinateurs de bureau et les clusters de production.

À ce stade, la sécurité ne consiste plus à examiner des lignes de code ou à effectuer des analyses. Il s'agit d'un problème de plan de contrôle. Il s'agit alors de répondre à des questions telles que :

- Qu'est-ce qui est exactement entré dans l’organisation ?

- Que contient chaque version ?

- Qu'est-ce qui est actuellement en cours d'exécution en production ?

- Est-il possible de tracer, l'auditer et le corriger à grande échelle ?

- Est-il possible de prouver la conformité aux exigences réglementaires ?

Pourquoi l'IA seule ne suffit pas pour la gouvernance d'entreprise

L'IA excelle dans le raisonnement textuel et logique. Mais la gouvernance ne relève pas de l’inférence. Ce sont des responsabilités fondamentalement différentes. Et une véritable gouvernance nécessite un système d'enregistrement faisant autorité.

L'IA seule ne peut pas :

- Agir comme une source unique et immuable de vérité

- Appliquer les politiques de publication dans tous les environnements

- Empêcher les binaires dangereux d'entrer dans l'organisation

- Conserver des métadonnées fiables sur les artefacts

- Enregistrer les journaux de publication pour les contrôles d'audit

- Garantir les attestations de provenance

- Servir de système réglementaire de preuves

L'IA peut conseiller, analyser et même générer, mais seul un système d'enregistrement régi peut appliquer, contrôler et prouver.

La nécessité d'une source unique et fiable

Pour le code source, les plateformes Git servent de système d'enregistrement. Dans un monde où le code est de plus en plus généré par l'IA, les fondements de la collaboration orientée Git évoluent discrètement. 

Quel est l'équivalent pour les binaires ?

Les organisations ont besoin de plus qu'un simple stockage évolutif. Elles ont besoin d'une source unique et fiable, d'un gardien qui protège ce qui entre dans l'organisation et qui a un impact direct sur ce qui est publié.

Un système d'enregistrement binaire actif doit fonctionner comme un plan de contrôle chargé de faire respecter les politiques qui régit chaque dépendance, artefact de construction stocké et distribué, version déployée dans les environnements d'exécution et chaque correction requise après la divulgation de nouvelles vulnérabilités. Mais surtout, ce contrôle ne commence pas au moment de la publication. Il commence au moment de l'installation.

L'IA transforme la création ; la gouvernance doit suivre le rythme

Les promesses de l'IA en matière de développement sont extraordinaires. Elle réduit les frictions, accélère les itérations et démocratise l'expertise. Enfin, elle modifie également la vitesse et l'ampleur des risques.

Lorsque les logiciels peuvent être générés à grande échelle, le tsunami de fichiers binaires qui envahit l’organisation croît tout aussi rapidement. Les dépendances, les outils, les plugins, les composants générés par l'IA se multiplient.

La sécurité ne peut se limiter à l'examen de ce qui est écrit. Elle doit régir ce qui existe.

C'est là que les plateformes de Software Supply Chain jouent un rôle essentiel en tant que couche de contrôle et système d'enregistrement, fournissant une suite de fonctionnalités de sécurité centrées sur les binaires qui permettent la gouvernance, l'application des politiques et une visibilité de bout en bout sur toute la chaîne d'approvisionnement logicielle.

L'IA renforce ce qui est produit. La supervision s’exerce sur ce qui est téléchargé, construit, stocké, distribué, exécuté et publié. Ensemble, ces mécanismes structurent un cycle de vie sécurisé, de la demande à la production.