RuStore intègre l'IA à la sécurité informatique : comment VK automatise la revue des tâches, du code et les contrôles DAST

RuStore présente un usage pragmatique de l'IA en sécurité informatique : ni vitrine, ni moyen de remplacer les spécialistes, mais un outil pour décharger les étapes les plus répétitives du cycle de livraison. L'équipe sécurité a automatisé trois domaines où l'ingénieur passe le plus de temps en analyse de base et en filtrage : le traitement initial des tâches Security Check, la relecture des changements dans les merge requests et les tests dynamiques d'applications.

La logique est simple : si la machine sait rassembler rapidement le contexte, mettre en évidence les risques classiques et écarter les problèmes évidents, l'humain dispose de plus de ressources pour les décisions vraiment difficiles, les cas litigieux et l'analyse approfondie de l'architecture.

C'est un changement important dans l'approche de la sécurité applicative. Dans le développement produit, la sécurité informatique ne se résume plus depuis longtemps aux rares incidents critiques et à la chasse aux attaques sophistiquées. L'essentiel de la charge est opérationnel et permanent : lire les énoncés des tâches, voir ce qui change exactement dans la fonctionnalité, comprendre quelles données sont touchées, quelles intégrations apparaissent et où des vulnérabilités peuvent surgir selon des schémas déjà connus.

Ce travail est obligatoire, mais c'est lui qui dévore les heures des experts. Faire grossir l'équipe pour absorber ce flux n'est pas toujours rationnel : avec le nombre de spécialistes, le volume de routine augmente aussi, et pas seulement la profondeur d'expertise. Le pari sur l'IA ressemble donc moins à une expérimentation à la mode qu'à une tentative de redistribuer ponctuellement le temps au sein de l'équipe.

Le premier axe est l'analyse des tâches Security Check dès la phase initiale. L'ingénieur doit généralement comprendre vite de quel changement il s'agit, où la sécurité est potentiellement concernée et si une analyse approfondie est vraiment nécessaire. Dans ce processus, l'IA peut rassembler le contexte de base de l'énoncé, repérer les zones sensibles et signaler d'avance ce qui ressemble à des schémas de risque connus. C'est particulièrement utile quand le flux de tâches est élevé et qu'une bonne part des demandes exige non pas une enquête complète, mais une qualification et un routage rapides.

Le deuxième axe est l'analyse du code dans les merge requests. Les vérifications y sont très répétitives : gestion des entrées utilisateur, accès, jetons, secrets, journalisation, validation, appels externes. Si le modèle sait parcourir ces couches comme une checklist, il devient non pas un « relecteur à la place de l'humain », mais un premier filtre avant l'évaluation de l'expert.

Le troisième domaine est l'AI-DAST, c'est-à-dire l'utilisation d'un modèle dans les tests dynamiques d'applications. Pour une équipe sécurité, c'est le prolongement logique de la même idée : une partie des contrôles peut être standardisée, accélérée et lancée de façon plus régulière, sans attendre que l'ingénieur trouve un créneau pour un passage manuel sur les scénarios classiques. Dans ce mode, l'IA est utile avant tout comme assistant qui ne se lasse pas des étapes répétitives et peut repérer plus vite des écarts dans le comportement de l'application. Cela réduit le risque qu'un problème classique se perde entre deux itérations de livraison, simplement faute de temps pour un passage manuel.

La décision finale reste toutefois à l'humain : c'est l'ingénieur qui évalue le contexte, distingue un vrai problème d'un faux positif et mesure la criticité du signal détecté pour un produit donné et son architecture.

À l'échelle du marché, c'est un bon exemple de l'intégration progressive de l'IA dans des processus internes matures. La valeur la plus concrète ne réside pas dans les promesses tapageuses de « sécurité autonome », mais dans la baisse du coût de la routine et l'accélération du contrôle initial sans perte de maîtrise. Si cette approche s'installe, les équipes de sécurité pourront consacrer moins de temps au tri mécanique des tâches et davantage à la modélisation des menaces, aux scénarios d'attaque non triviaux et à la prévention des erreurs avant la mise en production.

Pour les grandes équipes produit, ce sera probablement l'effet principal : non pas une réduction du rôle de l'expert, mais une hausse sensible de sa capacité de traitement.

Au fond, il s'agit de redistribuer l'attention vers les domaines où l'expertise humaine apporte le plus de valeur et où l'automatisation ne peut pas encore remplacer le jugement de l'ingénieur.