Swordfish Security publie les conférences de PRO DevSecOps Conf 2026 consacrées à la sécurité des systèmes d'IA

Trois semaines après la conférence, Swordfish Security a ouvert l'accès aux enregistrements de PRO DevSecOps Conf 2026. L'événement s'est tenu le 22 septembre ; il s'agit du forum annuel du groupe de sociétés consacré au développement sécurisé et à l'IA protégée. Les vidéos sont disponibles dans une playlist RUTUBE, et l'annonce a été publiée sur Habr le 13 octobre. La motivation des organisateurs est formulée sans détour : l'IA arrive en production plus vite que les équipes ne parviennent à bâtir sa protection. S'y ajoute le contexte réglementaire : selon eux, la loi 243-FZ sur l'IA est déjà en vigueur en Russie et les exigences en matière de développement sécurisé augmentent.

Que sait-on de l'événement ?

L'annonce est brève. Elle ne contient ni liste d'intervenants ni liste de sujets ; résumer les interventions reviendrait donc à les inventer. Voici ce que le texte permet de confirmer :

• organisateur : le groupe de sociétés Swordfish Security ;
• format : conférence annuelle PRO DevSecOps Conf, édition 2026 ;
• date : 22 septembre ;
• thèmes : développement sécurisé (DevSecOps) et IA protégée ;
• où regarder : playlist RUTUBE, lien dans la publication sur Habr ;
• contexte réglementaire : la loi 243-FZ sur l'IA, selon la désignation des organisateurs.

Le simple fait de réunir ces deux thèmes dans un même programme montre l'évolution des priorités du métier. Les équipes de sécurité se concentraient auparavant sur le code et les dépendances. Aujourd'hui, leur périmètre inclut aussi les modèles, les jeux de données, les prompts et les agents.

Pourquoi l'IA complique le pipeline de développement

Le DevSecOps classique s'organise autour d'artefacts bien identifiés : code source, conteneurs, bibliothèques, infrastructure as code. Il dispose pour cela d'analyses statique et dynamique, de scanners de dépendances et de SBOM. Les composants d'IA ouvrent de nouvelles surfaces d'attaque.

Première surface : la prompt injection. Une application reposant sur un LLM reçoit du texte provenant de sources non fiables, qu'il s'agisse d'e-mails, de pages web ou de documents dans un RAG. Le modèle ne distingue pas les données des instructions comme le ferait un parseur : une commande malveillante peut donc s'exécuter. L'OWASP tient une liste distincte des risques liés aux applications LLM, et les injections y figurent toujours parmi les principaux.

Deuxième surface : la chaîne d'approvisionnement des modèles. Les poids sont téléchargés depuis des dépôts publics, et certains formats de sérialisation, comme pickle, peuvent exécuter du code au chargement. Le risque est le même qu'avec une bibliothèque inconnue, mais il est nettement moins souvent vérifié.

Troisième surface : les agents. Dès qu'un modèle accède à des outils, à la messagerie, à une base de données ou au CI, une erreur ou une attaque ne se limite plus à une mauvaise réponse : elle devient une action réelle, exécutée avec de vrais droits.

La réglementation comme accélérateur

Les organisateurs mentionnent la loi 243-FZ sur l'IA. L'annonce ne détaille pas ce que le texte exige précisément des développeurs ; mieux vaut vérifier les normes exactes à la source plutôt que dans des résumés. La logique, elle, est claire : lorsque les systèmes d'IA tombent sous le coup d'exigences formelles, la sécurité cesse d'être une initiative d'enthousiastes au sein de l'équipe et devient un point de contrôle. Pour les entreprises qui travaillent en Russie et sont déjà soumises à des exigences de développement sécurisé, cela implique de documenter la manière dont elles vérifient aussi la partie IA de leur produit.

Par où commencer pour une équipe

Les enregistrements de la conférence sont une bonne occasion de mener un audit interne. Voici un socle minimal d'actions, indépendant de telle ou telle intervention :

• dresser un registre de tous les composants d'IA : API externes, modèles locaux, bases RAG, agents et leurs droits ;
• étendre l'inventaire des dépendances aux modèles et aux jeux de données : source, version, format, somme de contrôle ;
• interdire le chargement de poids dans des formats non sûrs sans vérification préalable en environnement isolé ;
• ajouter au CI des tests de prompt injection et de fuite de contexte, en tant que classe de contrôles à part entière ;
• accorder aux agents des droits minimaux et journaliser chaque action effectuée avec les outils ;
• désigner un responsable chargé de rapprocher les exigences de la loi 243-FZ des processus existants.

Il est ensuite pertinent d'ouvrir la playlist et de choisir les interventions adaptées à sa stack. Tant que le programme n'est pas publié sous forme de liste distincte, il faudra se repérer d'après les titres des vidéos sur RUTUBE.