RuStore a déployé l'IA en sécurité de l'information : comment VK automatise l'examen des tâches, du code et les tests DAST

RuStore a démontré une approche pragmatique pour utiliser l'IA en sécurité de l'information : non pas pour une belle vitrine ni pour remplacer des spécialistes, mais pour décharger les étapes les plus répétitives du travail au sein du cycle de lancement. L'équipe de sécurité a automatisé trois zones où les ingénieurs dépensent le plus souvent du temps sur l'examen basique et le filtrage : le traitement initial des tâches Security Check, l'examen des changements dans les merge requests et les tests dynamiques des applications. La logique est simple : si la machine peut rapidement rassembler le contexte, mettre en évidence les risques typiques et filtrer les problèmes évidents, les humains ont plus de ressources pour les solutions vraiment complexes, les cas litigieux et l'analyse architecturale profonde.

Ceci représente un changement important dans l'approche de la sécurité appliquée. Dans le développement de produits, la sécurité a longtemps consisté en bien plus que des incidents critiques rares et la chasse aux attaques sophistiquées. L'essentiel de la charge de travail est une opération constante : il faut lire les descriptions de tâches, voir ce qui change exactement dans la fonctionnalité, comprendre quelles données sont affectées, quelles intégrations apparaissent et où les vulnérabilités pourraient émerger selon des modèles déjà connus.

Un tel travail est obligatoire, mais c'est exactement ce qui consomme les heures des experts. Augmenter l'équipe pour ce flux n'est pas toujours rationnel : avec le nombre de spécialistes augmente le volume de routine, pas seulement la profondeur de l'expertise. Donc parier sur l'IA ici ressemble non à une expérience à la mode, mais à une tentative de redistribuer ponctuellement le temps au sein de l'équipe.

La première direction est l'examen des tâches Security Check à un stade précoce. Normalement un ingénieur doit rapidement comprendre quel changement est en question, où la sécurité est potentiellement affectée et si l'analyse approfondie est vraiment nécessaire. L'IA dans un tel processus peut rassembler le contexte basique de la description de la tâche, mettre en évidence les domaines sensibles et signaler les choses qui ressemblent à des modèles de risque connus.

C'est particulièrement utile où le flux de tâches est élevé et une partie significative des demandes ont finalement besoin de qualification rapide et d'acheminement, pas d'enquête complète. La deuxième direction est l'analyse du code dans les merge requests. Ici il y a particulièrement beaucoup de vérifications routinières : gestion des entrées utilisateur, contrôles d'accès, tokens, secrets, logging, validation, appels externes.

Si le modèle peut parcourir ces couches comme une liste de contrôle, il devient non pas "un examinateur à la place d'un humain" mais un premier filtre avant l'évaluation expert. La troisième zone est l'AI-DAST, c'est-à-dire l'utilisation du modèle dans les tests dynamiques des applications. Pour une équipe de sécurité c'est une extension logique de la même idée : certains contrôles peuvent être standardisés, accélérés et exécutés de manière plus cohérente sans attendre qu'un ingénieur trouve une fenêtre pour passage manuel par des scénarios typiques.

Dans un tel mode, l'IA est utile principalement comme assistant qui ne se fatigue pas d'effectuer des étapes répétitives et peut plus rapidement remarquer des écarts dans le comportement de l'application. Cela réduit la probabilité qu'un problème routinier se perde entre les itérations de lancement simplement par manque de temps pour les tests manuels. Pendant ce temps, la décision finale reste celle de l'humain : c'est l'ingénieur qui évalue le contexte, distingue un vrai problème d'une fausse alerte et comprend combien le signal trouvé est critique pour le produit particulier et son architecture.

Au niveau du marché, c'est un bon exemple de la façon dont l'IA est progressivement intégrée dans les processus internes matures. La valeur la plus pratique ici n'est pas dans les grandes promesses d'« une sécurité autonome », mais dans la réduction du coût du travail routinier et l'accélération des vérifications initiales sans perte de contrôle. Si une telle approche s'établit, les équipes de sécurité pourront passer moins de temps sur le tri mécanique des tâches et plus de temps sur la modélisation des menaces, les scénarios d'attaque non triviaux et la prévention des erreurs avant le lancement.

Pour les grandes équipes de produits, c'est probablement ce qui deviendra l'effet principal : non pas une réduction du rôle de l'expert, mais une augmentation notable de son débit. Essentiellement, il s'agit de redistribuer l'attention en faveur de ces domaines où l'expertise humaine fournit vraiment une valeur maximale et où l'automatisation n'est pas encore capable de remplacer le jugement d'ingénierie.