Pourquoi les applications natives de l’IA mettent à mal les modèles AppSec traditionnels

Les applications natives de l’IA ne se comportent pas comme les logiciels que les équipes de sécurité ont l’habitude de protéger. Au lieu de suivre des chemins logiques prévisibles, ces systèmes génèrent du code à la volée, remanient les entrées des utilisateurs et prennent des décisions contextuelles à l’exécution. Le comportement d’un modèle est façonné par une combinaison de données d’entraînement, de réglages fins, d’invites et de variables liées aux sources de récupération, qui font évoluer ses décisions d’une manière que les développeurs ne peuvent pas toujours anticiper.

La surface d’attaque s’étend ainsi au-delà du code et de la configuration. Une invite peut réorienter le raisonnement d’un modèle, un jeu de données empoisonné peut fausser ses résultats futurs, et un agent insuffisamment encadré peut effectuer des actions que les développeurs n’ont jamais programmées. Rien de tout cela ne correspond aux schémas statiques et reproductibles sur lesquels s’appuient les outils AppSec traditionnels.

Il en résulte un paysage constellé de questions auxquelles les scanners traditionnels ne peuvent pas répondre. Quel modèle pilote un flux de travail essentiel, et quelles données l’ont façonné ? Comment un système RAG se comporte-t-il lorsque sa source de récupération change ? Il s’agit de préoccupations de sécurité fondamentales, mais les outils traditionnels n’offrent pas la visibilité nécessaire pour y répondre. Les logiciels natifs de l’IA ont transformé le problème, et les anciennes hypothèses ne tiennent plus.

L’AppSec traditionnelle suppose des chemins de code prévisibles

Les pratiques AppSec traditionnelles partent du principe que les logiciels suivent des chemins prévisibles. Les tests statiques de sécurité des applications (SAST) fonctionnent parce que le code peut être analysé, et les tests dynamiques de sécurité des applications (DAST) parce que les interfaces se comportent de manière reproductible. Ces deux approches reposent sur l’idée que les développeurs ont écrit la logique et qu’elle se comportera de façon constante à chaque exécution.

Les applications natives de l’IA remettent en cause ce fondement. Un LLM peut produire des résultats différents pour des entrées similaires, car son comportement évolue en fonction des invites, du contexte et des informations qu’il récupère. Cette variabilité n’est pas liée aux modifications du code, mais au raisonnement interne du modèle.

Cette variabilité compromet la prévisibilité sur laquelle s’appuient les scanners traditionnels. Le SAST ne peut pas cartographier une logique non déterministe, et le DAST ne peut pas rejouer les interactions lorsque les résultats changent à l’exécution. Aucun des deux ne peut évaluer une logique générée à la volée. Lorsqu’un modèle détermine le comportement fondamental à la place d’un code statique, les outils traditionnels ne peuvent pas fournir d’évaluations fiables.

Les catégories de menaces propres à l’IA native ne correspondent pas aux anciennes catégories

Le décalage est encore plus marqué lorsqu’on examine les catégories de menaces elles-mêmes. Les scanners traditionnels excellent dans l’identification des vulnérabilités du code, mais les risques liés à l’IA native trouvent souvent leur origine ailleurs. Ils découlent du comportement et échappent donc à la plupart des outils existants.

L’injection de prompt l’illustre clairement : une seule entrée peut réorienter le raisonnement d’un modèle, contourner les garde-fous ou révéler des données internes sans toucher au code. L’empoisonnement des données présente un risque similaire, mais plus tôt dans le cycle de vie : des données d’entraînement contaminées entraînent des résultats nuisibles ou exploitables longtemps après le déploiement.

Les flux de travail RAG introduisent des risques, car des sources de récupération manipulées peuvent influencer le comportement du modèle sans qu’aucune modification du code soit nécessaire. La chaîne d’approvisionnement plus vaste des modèles, qui comprend les modèles préentraînés, les représentations vectorielles et les agents tiers, introduit des dépendances opaques que les équipes adoptent souvent sans visibilité complète.

Toutes ces menaces apparaissent à l’exécution plutôt que dans le code statique, créant une catégorie de vulnérabilités que les scanners traditionnels ne peuvent pas détecter. Il en résulte une multiplication des angles morts auxquels la plupart des programmes AppSec n’ont jamais été conçus pour faire face.

Le point de rupture : l’AppSec ne dispose d’aucune visibilité sur la couche des modèles

Ces nouvelles catégories de menaces révèlent un problème plus profond : la plupart des programmes AppSec n’ont presque aucune visibilité sur la couche des modèles. Les équipes peuvent cartographier les dépendances logicielles, mais elles suivent rarement les modèles exécutés en production ou les données et processus d’entraînement qui les ont façonnés.

Les interactions essentielles sont elles aussi opaques. Il n’existe aucune méthode standard pour suivre les invites, examiner les garde-fous ou observer les décisions prises au moment de l’inférence. Les journaux traditionnels enregistrent les appels d’API, et non les étapes de raisonnement ou les actions des agents qui déterminent le comportement de l’IA.

Par conséquent, les scanners traditionnels ne peuvent pas détecter la dérive des modèles, les actions inattendues des agents ni les changements induits par des données externes. Ils n’ont jamais été conçus pour observer le comportement de la couche des modèles : sans nouvelles méthodes de visibilité, les angles morts sont inévitables.

Les applications natives de l’IA nécessitent un nouvel artefact de sécurité : la nomenclature de l’IA (AI-BoM)

Cette lacune en matière de visibilité souligne la nécessité d’un nouveau type d’artefact de sécurité dans les systèmes natifs de l’IA. La nomenclature de l’IA (AI-BoM) fournit une méthode structurée pour documenter les modèles utilisés, les jeux de données qui les ont façonnés et les invites ou agents qui influencent leur comportement, tout comme une SBOM clarifie les composants de la chaîne d’approvisionnement logicielle.

Le regroupement de ces éléments rétablit le contexte qui fait défaut aux programmes AppSec. Il offre aux équipes une vision claire de l’origine des modèles, de l’influence des données et de l’évolution des risques. L’AI-BoM contribue également à la gouvernance et à la conformité en montrant comment les systèmes d’IA sont conçus et sur quoi ils reposent. À mesure que les flux de travail se complexifient, il devient un point de repère constant pour évaluer et détecter les risques.

L’AI-BoM rétablit les fondements dont l’AppSec a besoin. Sans elle, les équipes doivent réagir à des comportements qu’elles ne peuvent pas voir. Grâce à elle, l’IA peut s’inscrire dans le même cadre de sécurité structuré et responsable que celui utilisé à grande échelle pour les logiciels.

Pourquoi le comportement agentique constitue le point de rupture

À mesure que les équipes commencent à documenter les modèles, les jeux de données et les invites au moyen d’une AI-BoM, un autre défi devient impossible à ignorer : les systèmes d’IA ne se contentent plus de générer des résultats, ils passent à l’action. Les agents autonomes peuvent appeler des outils, écrire des fichiers, mettre à jour des systèmes et déclencher des flux de travail en fonction d’objectifs plutôt que d’une logique fixe. Leur comportement évolue selon le contexte et les informations récupérées, créant un niveau d’autonomie que l’AppSec traditionnelle n’a jamais été conçue pour analyser.

Les approches traditionnelles peuvent évaluer les fonctions et les flux de contrôle, mais elles ne peuvent ni interpréter une intention ni cartographier les chaînes d’actions ramifiées qu’un agent peut former à l’exécution. Ces chemins changent d’un instant à l’autre, non pas parce que le code change, mais parce que le raisonnement à l’origine des actions évolue.

Sécuriser les applications natives de l’IA, c’est suivre non seulement le code, mais aussi le comportement qu’il produit au fil du temps. Cela exige une visibilité sur la manière dont les agents agissent, leurs interactions et l’évolution de leurs décisions. Cette autonomie dynamique marque le point de rupture de l’AppSec traditionnelle et rend inévitable l’adoption d’un nouveau modèle de sécurité.

Les exigences d’une approche de sécurité moderne alignée sur les modèles

Reconnaître les limites de l’AppSec traditionnelle n’est que la première étape. Il faut ensuite définir à quoi ressemble un modèle de sécurité aligné sur le comportement réel des systèmes d’IA. Si la logique est dynamique et que les agents peuvent agir de manière autonome, la sécurité doit passer de l’analyse d’artefacts statiques à la compréhension du cycle de vie complet du comportement des modèles.

Tout commence par la visibilité. Les équipes doivent savoir clairement quels modèles sont utilisés, quelles données les ont façonnés, comment ils se comportent au moment de l’inférence et quelles actions leurs agents peuvent déclencher. Sans ce contexte, tous les contrôles en aval deviennent réactifs.

Les garde-fous doivent eux aussi évoluer. Il ne suffit plus de vérifier la qualité du code ou la rigueur de la configuration. Les garde-fous modernes doivent évaluer le comportement des modèles, suivre les flux d’invites et détecter les écarts des résultats par rapport aux schémas attendus. Ils doivent pouvoir signaler un raisonnement qui s’aventure en terrain dangereux, et pas seulement les erreurs intégrées au code.

Comme ces systèmes sont adaptatifs, une surveillance continue est nécessaire. La dérive, l’empoisonnement des données, les résultats dangereux et l’utilisation inattendue d’outils peuvent apparaître progressivement ou soudainement. Les analyses périodiques traditionnelles ne détectent pas ces changements. Les systèmes natifs de l’IA nécessitent une observation permanente afin que les équipes repèrent les changements dès qu’ils deviennent importants.

Enfin, tous ces éléments doivent s’intégrer aux flux de travail de développement existants. Si la sécurité n’intervient qu’après le déploiement, les organisations finissent par adapter les contrôles à un comportement déjà établi. Intégrer ces capacités plus tôt dans le cycle de vie permet aux équipes d’agir avant que les risques ne s’installent.

Une approche de sécurité alignée sur les modèles ne remplace pas l’AppSec. Elle l’étend pour tenir compte de la manière dont les systèmes d’IA réfléchissent, prennent des décisions et agissent.

L’AppSec évolue vers l’orchestration de la sécurité de l’IA

Une approche alignée sur les modèles en constitue le fondement, mais les organisations ont toujours besoin d’un moyen de la mettre en pratique. C’est là que la sécurité des applications commence à évoluer vers une nouvelle discipline : l’orchestration de l’ensemble du système d’IA. Au lieu de traiter les modèles, les invites, les jeux de données et les agents comme des composants opaques, la sécurité doit les coordonner, observer leur comportement et appliquer des garde-fous pendant leur fonctionnement.

Evo incarne cette évolution. La solution étend la sécurité au-delà du code et de la configuration en orchestrant des agents spécialisés qui surveillent le comportement des modèles, détectent les menaces au niveau des modèles et appliquent des garde-fous en temps réel. Ces agents permettent aux équipes de comprendre et de contrôler les composants des systèmes d’IA invisibles pour l’AppSec traditionnelle : le raisonnement, les choix de récupération et les actions des flux de travail autonomes.

Snyk Studio complète cette approche à l’autre extrémité du cycle de vie. La solution guide les assistants de programmation IA pendant la génération du code, afin que le code écrit par l’IA soit sécurisé dès le départ plutôt que de devoir être corrigé par la suite. Studio garantit la sécurité dès la conception, tandis qu’Evo assure la sécurité du comportement à mesure que les modèles s’exécutent, s’adaptent et agissent.

Ensemble, ces solutions élargissent la définition de la sécurité des applications. Dans un monde natif de l’IA, sécuriser une application signifie sécuriser le code qui l’exécute, les modèles qui la pilotent et les agents qui agissent en son nom. Evo rassemble ces éléments et oriente l’AppSec vers un avenir fondé sur l’orchestration plutôt que sur l’analyse statique.

L’AppSec traditionnelle n’a pas tort : elle est incomplète

L’AppSec traditionnelle n’a pas échoué. C’est l’environnement dans lequel elle s’inscrit qui a changé. Les logiciels natifs de l’IA remettent en cause les idées reçues sur la manière dont la logique est écrite, dont les systèmes se comportent et dont les risques apparaissent. Le code n’est plus l’unique source de vérité. Le comportement, le contexte et la prise de décision pilotée par les modèles façonnent les applications d’une manière que les outils statiques n’ont jamais été conçus pour interpréter.

Sécuriser cette nouvelle catégorie de systèmes exige une visibilité continue sur le raisonnement des modèles, les actions des agents et l’évolution des flux de travail. Les organisations qui reconnaissent rapidement cette évolution éviteront les angles morts qui ralentissent le développement et les exposent à des risques cachés. Elles avanceront plus vite, développeront avec davantage de confiance et feront de l’IA un accélérateur plutôt qu’une variable incontrôlée.

Snyk contribue à mener cette transformation. En étendant la sécurité du code aux modèles, aux invites et aux comportements agentiques, nous faisons évoluer l’AppSec d’une discipline centrée sur le code vers une approche alignée sur l’IA. C’est la voie que doit suivre le secteur, et celle que nous nous employons à construire.

Vous souhaitez commencer à développer des applications natives de l’IA avec des garde-fous intégrés ? Découvrez le guide ultime pour sécuriser les applications agentiques et évoluer dans ce nouveau paysage des menaces.