Skip to main content

Centre de ressources

Fondamentaux et certification pour les ingénieurs en sécurité de l’IA

Découvrez le programme, obtenez votre certificat et faites passer vos compétences en sécurité de l’IA au niveau supérieur.

Faites progresser vos compétences en IA avec le programme AI Security Engineer Foundations de Snyk. Participez à l’une des six sessions d’une demi-heure et obtenez un badge officiel pour chaque session suivie. Participez aux six sessions et recevez un certificat de réussite attestant votre capacité à créer, déployer et sécuriser des applications basées sur l’IA dans le monde réel.

Les sessions sont proposées en présentiel et en ligne. Elles s’adressent aux créateurs, aux ingénieurs et aux professionnels de la sécurité qui souhaitent avancer rapidement sans compromettre la sécurité dans un environnement de développement natif de l’IA. Découvrez les détails des sujets ci-dessous.

Session_1_x9pjkq

OWASP Top 10

En savoir plus
Session_2_ltawvp

Lutter contre le Shadow AI

En savoir plus
Session_3_sfbhyj

Modélisation des menaces liées à l’IA

En savoir plus
Session_4_nk7ghf

Sécuriser les compétences des agents et MCP

En savoir plus
Session_5_ju0nkm

Sécuriser le Vibe Coding

En savoir plus
Session_6_tebcv8

Tests d’intrusion des systèmes d’IA

En savoir plus

Modules

Module 1

Top 10 de l’OWASP pour les applications agentiques

Acquérez une compréhension pratique des principaux risques de sécurité introduits par les applications d’IA agentique. Ce module explique comment les risques évoluent lorsque les systèmes d’IA peuvent raisonner, planifier, utiliser des outils, accéder à une mémoire, interagir avec d’autres agents et effectuer des actions dans le cadre de workflows métier.

À la fin de ce module, vous serez capable de :

  • Expliquer pourquoi l’OWASP Top 10 for Agentic Applications existe et en quoi il diffère de l’OWASP Top 10 for Web Applications et de l’OWASP Top 10 for LLM Applications.

  • Décrire comment l’IA agentique modifie le modèle de sécurité à travers les objectifs, les outils, la mémoire, l’identité, les autorisations, l’orchestration et les actions en aval.

  • Définir les dix risques liés aux agents : détournement des objectifs de l’agent, utilisation abusive des outils, abus d’identité et de privilèges, vulnérabilités de la chaîne d’approvisionnement agentique, exécution inattendue de code, empoisonnement de la mémoire et du contexte, communication interagents non sécurisée, défaillances en cascade, exploitation de la confiance entre les humains et les agents, et agents renégats.

  • Distinguer les risques au niveau du modèle, les risques au niveau de l’application, les risques liés à la couche d’outils, les risques liés à l’identité, les risques liés à la mémoire et au contexte, ainsi que les risques liés aux systèmes en aval.

  • Associer chaque risque à des mesures de contrôle pratiques telles que le principe du moindre privilège, les identités limitées à un périmètre défini, la liste blanche des outils, les étapes d’approbation, l’isolation de la mémoire, la validation du contexte, l’examen de la chaîne d’approvisionnement, la surveillance à l’exécution et la journalisation d’audit.

  • Expliquer comment une seule faiblesse agentique peut s’amplifier en une chaîne d’attaque plus vaste, par exemple lorsqu’un détournement des objectifs entraîne une utilisation abusive des outils, un abus de privilèges, une exposition des données ou une automatisation dangereuse.

  • Faire la distinction entre les systèmes d’IA qui recommandent uniquement des actions et les systèmes agentiques capables d’exécuter des actions, et expliquer pourquoi l’exécution modifie la gouvernance et la responsabilité.

  • Utiliser l’OWASP Top 10 for Agentic Applications comme taxonomie commune pour la modélisation des menaces, le red teaming, l’examen de l’architecture, la conception sécurisée, la mise en correspondance des contrôles et la planification de la réponse aux incidents.

  • Évaluer si un agent opère dans des limites sûres : ce qu’il peut faire, l’autorité qu’il utilise, les données auxquelles il peut accéder, les outils qu’il peut appeler, ainsi que la manière dont ses actions sont journalisées et approuvées.

Module 2

Remédier à l’IA fantôme

Mettez-vous dans la peau d’un ingénieur en sécurité de l’IA pour naviguer parmi les « choses inattendues » qui apparaissent lorsque vous examinez les dessous de votre posture de sécurité liée à l’IA.

  • Découvrez comment un ingénieur en sécurité de l’IA débute et évolue à l’intersection de la sécurité des plateformes, de l’ingénierie ML et du renseignement sur les menaces.

  • Découvrez les outils nécessaires pour révéler le « Shadow AI » et comment les discussions sur la sécurité évoluent désormais au sein des organisations.

  • Découvrez comment fournir du renseignement et appliquer des politiques à une IA autonome sans ralentir l’innovation.

À la fin de ce module, vous serez capable de :

  • Définir le Shadow AI et expliquer les caractéristiques qui le distinguent du Shadow IT.

  • Citer les principaux chiffres de 2025–2026 sur la prévalence et le coût du Shadow AI.

  • Reconnaître les quatre propriétés qui rendent structurellement le Shadow AI plus difficile à gouverner que ses prédécesseurs.

  • Identifier les quatre scénarios de risque liés au Shadow AI les plus courants dans les environnements d’entreprise.

  • Définir un AIBOM et décrire les trois fonctions qu’il remplit dans un programme de gouvernance de l’IA.

  • Comparer l’AIBOM et le SBOM en termes de périmètre, de comportement, de catégories de risques, de fréquence des mises à jour, de normes et de chaîne d’approvisionnement.

  • Identifier les quatre anti-modèles les plus couramment observés dans les programmes de Shadow AI et expliquer pourquoi chacun échoue.

  • Générer un AIBOM pour un projet d’exemple à l’aide de la Snyk CLI et examiner le résultat dans la plateforme Evo.

Module 3

Modélisation des menaces liées à l’IA

Ce module vous présente la modélisation des menaces liées à l’IA : une pratique structurée visant à identifier, analyser, hiérarchiser et atténuer les menaces propres aux systèmes alimentés par l’IA. En s’appuyant sur les principes fondamentaux de la modélisation traditionnelle des menaces (STRIDE, DREAD, arbres d’attaque), ce module explique pourquoi les approches conventionnelles montrent leurs limites lorsqu’elles sont appliquées à des systèmes d’IA probabilistes et non déterministes, et présente un workflow pratique pour modéliser les menaces tout au long du cycle de vie de l’IA/ML, de l’ingestion des données à l’inférence, jusqu’à l’invocation d’outils par des agents.

À la fin de ce module, vous serez en mesure de :

  • Définir la modélisation des menaces et expliquer son rôle dans un pipeline DevSecOps moderne.

  • Appliquer les frameworks traditionnels de modélisation des menaces (STRIDE, DREAD, arbres d’attaque) à l’architecture des systèmes.

  • Identifier la surface d’attaque spécifique introduite par les systèmes d’IA/ML, y compris l’IA agentique.

  • Reconnaître les nouvelles catégories d’actifs et les frontières de confiance propres aux systèmes d’IA.

  • Mettre en œuvre un workflow pratique de modélisation des menaces liées à l’IA couvrant la découverte, l’énumération, la hiérarchisation et l’atténuation.

  • Intégrer la modélisation des menaces liées à l’IA dans un pipeline DevSecOps continu et adaptatif.

Module 4

Sécuriser les agents et MCP

Comment SKILL.md a introduit des malwares

La première partie de cette session sera consacrée à la recherche « ToxicSkills », dans laquelle nous analyserons les premières menaces majeures de la chaîne logistique visant les écosystèmes d’agents IA.

Dans la deuxième partie de cette session, nous présenterons des techniques d’exploitation active contre les déploiements MCP : comment une simple description d’outil malveillante peut exfiltrer des identifiants, et comment des attaquants exploitent des serveurs MCP non sécurisés pour exécuter du code arbitraire.

À la fin de ce module, vous serez capable de :

  • Expliquer ce qu’est le Model Context Protocol, pourquoi il est devenu nécessaire et ce qu’est fondamentalement un serveur MCP du point de vue de la sécurité.

  • Formuler les trois raisons structurelles qui rendent la sécurité MCP urgente en 2026 : l’ampleur des téléchargements des SDK, l’adoption des environnements de développement intégrés agentiques et la position de MCP dans le contexte le plus privilégié du développeur.

  • Définir l’empoisonnement d’outil et reconnaître comment des instructions dissimulées dans les descriptions d’outils peuvent pousser un agent à effectuer des actions dangereuses.

  • Distinguer deux modes de défaillance MCP catégoriquement différents : les serveurs MCP malveillants (la couche protocolaire) et le code de serveur MCP vulnérable (la couche d’implémentation), et identifier le contrôle de sécurité qui répond à chacun d’eux.

  • Reconnaître les schémas d’attaque MCP canoniques — empoisonnement d’outil, injection de commandes et traversée de chemins — à partir de la structure du code, et appliquer à chacun les méthodes standard de remédiation.

  • Exécuter MCP-Scan sur une configuration MCP locale et interpréter ses résultats, notamment les avertissements W001/E001 liés aux descriptions d’outils et les alertes de flux toxique TF001/TF002.

  • Exécuter Snyk Code sur le code source d’un serveur MCP et interpréter ses résultats, notamment les CWE liés à l’injection de commandes et à la traversée de chemins, avec des correctifs générés par l’IA.

  • Formuler les arguments en faveur d’une défense en profondeur reposant sur l’exécution conjointe de MCP-Scan et de Snyk Code dans un programme mature de sécurité MCP.

Module 5

Sécuriser le Vibe Coding

Dans cette session, nous décortiquons les implications du Vibe Coding en matière de sécurité et partageons des stratégies concrètes pour sécuriser le code généré par l’IA à grande échelle.

  • Découvrez comment le Vibe Coding transforme le développement et les risques qui l’accompagnent

  • Découvrez des stratégies pratiques pour sécuriser le code généré par l’IA à grande échelle

  • Découvrez comment Snyk sécurise votre SDLC alimenté par l’IA, du code au déploiement, grâce à Snyk Studio

À la fin de ce module, vous serez capable de :

  • Définir le vibe coding et expliquer ses origines

  • Décrire le « Lobster Ecosystem », la constellation d’outils d’IA agentique, de registres de compétences pour agents et de frameworks d’automatisation open source, et expliquer la surface d’attaque de la chaîne d’approvisionnement qu’il introduit, en faisant référence à l’empoisonnement des compétences des agents et au slopsquatting.

  • Appliquer le Secure-by-Design Playbook en cinq couches à un projet réalisé avec le vibe coding

  • Identifier les modèles de vulnérabilités les plus courants dans le code généré par l’IA — sécurité au niveau des lignes désactivée, secrets codés en dur, authentification manquante, logique de sécurité côté client, slop-squatting et empoisonnement des fichiers de règles — et associer chacun d’eux à l’OWASP Top 10 for LLM Applications

  • Distinguer le vibe coding du vibe hacking

Module 6

Tests d’intrusion des systèmes d’IA

Acquérir une compréhension pratique de la manière de tester la sécurité des applications alimentées par l’IA et des applications agentiques. Ce module explique en quoi les tests d’intrusion de l’IA vont au-delà des tests traditionnels des applications web et des API en examinant les prompts, le comportement des modèles, la gestion du contexte, l’accès aux outils, la mémoire, les autorisations et les actions en aval.

À la fin de ce module, les apprenants seront capables de :

  • Expliquer en quoi les tests d’intrusion de l’IA diffèrent des tests traditionnels des applications, des API et de l’infrastructure.

  • Identifier les surfaces d’attaque propres à l’IA, telles que les prompts, les instructions système, les pipelines RAG, les embeddings, les outils, les agents, la mémoire, les plugins et les services connectés via MCP.

  • Tester les faiblesses courantes de la sécurité de l’IA, notamment l’injection de prompts, la divulgation d’informations sensibles, la fuite du prompt système, l’autonomie excessive, le traitement non sécurisé des sorties, l’empoisonnement du contexte et l’utilisation abusive des outils.

  • Élaborer des cas de test sûrs et reproductibles pour les applications d’IA, sans recourir à des techniques nuisibles, incontrôlées ou susceptibles d’avoir un impact sur la production.

  • Évaluer si un système d’IA sépare correctement les instructions fiables des entrées utilisateur non fiables, du contenu récupéré, des documents, des tickets, des journaux ou des pages web.

  • Évaluer comment un agent d’IA sélectionne les outils, transmet les arguments, gère les autorisations et empêche les actions dangereuses ou non autorisées.

  • Tester si des données sensibles peuvent être divulguées par les réponses du modèle, les journaux, les traces, la mémoire, la recherche vectorielle, les sorties des outils ou les workflows d’agents enchaînés.

  • Associer les résultats des tests d’intrusion de l’IA à des mesures correctives pratiques, telles que la validation des entrées et des sorties, l’autorisation explicite des outils, les jetons à portée limitée, les étapes d’approbation humaine, l’isolation de la mémoire, le filtrage du contexte et la journalisation d’audit.

  • Combiner les tests propres à l’IA avec les tests de sécurité standard des API, de l’authentification, de l’autorisation, du SSRF, de l’injection, du contrôle d’accès, des risques liés aux dépendances et des configurations non sécurisées.

  • Mieux comprendre EVO COS (Continuous Offensive Security)