RuStore incorpora IA a la seguridad informática: cómo VK automatiza la revisión de tareas, código y pruebas DAST

RuStore ha mostrado un uso pragmático de la IA en seguridad informática: no como escaparate ni para sustituir a los especialistas, sino para aliviar las etapas más repetitivas del ciclo de lanzamientos. El equipo de seguridad ha automatizado tres áreas en las que el ingeniero suele dedicar más tiempo al análisis básico y al filtrado: el tratamiento inicial de las tareas de Security Check, la revisión de cambios en los merge requests y las pruebas dinámicas de aplicaciones.

La lógica es sencilla: si una máquina puede reunir contexto con rapidez, resaltar riesgos habituales y descartar los problemas evidentes, la persona dispone de más recursos para decisiones realmente difíciles, casos dudosos y análisis profundo de la arquitectura.

Es un cambio importante en el enfoque de la seguridad aplicada. En el desarrollo de producto, la seguridad informática hace tiempo que no se limita a incidentes críticos poco frecuentes ni a la caza de ataques sofisticados. La mayor parte de la carga es operativa y constante: leer los planteamientos de las tareas, ver qué cambia exactamente en la funcionalidad, entender qué datos se ven afectados, qué integraciones aparecen y dónde pueden surgir vulnerabilidades según patrones ya conocidos.

Este trabajo es obligatorio, pero es justo el que se come las horas de los expertos. Escalar el equipo para absorber ese flujo no siempre es racional: con el número de especialistas crece también el volumen de rutina, y no solo la profundidad de la experiencia. Por eso la apuesta por la IA parece menos un experimento de moda que un intento de redistribuir el tiempo del equipo de forma selectiva.

La primera línea es el análisis de las tareas de Security Check en una fase temprana. Normalmente el ingeniero necesita entender rápido de qué cambio se trata, dónde puede verse afectada la seguridad y si hace falta un análisis en profundidad. En este proceso, la IA puede reunir el contexto básico del planteamiento, marcar las zonas sensibles y resaltar de antemano lo que se parece a patrones de riesgo conocidos. Es especialmente útil cuando el flujo de tareas es alto y buena parte de las solicitudes no requiere una investigación completa, sino una calificación y un enrutamiento rápidos.

La segunda línea es el análisis de código en los merge requests. Aquí abundan las comprobaciones repetitivas: manejo de la entrada del usuario, accesos, tokens, secretos, registros, validación, llamadas externas. Si el modelo sabe recorrer estas capas como una lista de verificación, deja de ser un «revisor en lugar de una persona» y pasa a ser un primer filtro antes de la evaluación experta.

La tercera zona es AI-DAST, es decir, el uso de un modelo en las pruebas dinámicas de aplicaciones. Para un equipo de seguridad es la continuación lógica de la misma idea: parte de las comprobaciones se puede estandarizar, acelerar y ejecutar de forma más constante, sin esperar a que el ingeniero tenga un hueco para recorrer a mano los escenarios habituales. En este modo, la IA es útil sobre todo como asistente que no se cansa de repetir pasos y que puede detectar antes desviaciones en el comportamiento de la aplicación. Eso reduce la probabilidad de que un problema típico se pierda entre iteraciones de lanzamiento simplemente por falta de tiempo para una ejecución manual.

Aun así, la decisión final sigue en manos de una persona: es el ingeniero quien evalúa el contexto, separa el problema real del falso positivo y entiende cuán crítica es la señal detectada para un producto concreto y su arquitectura.

A escala de mercado, es un buen ejemplo de cómo la IA se integra poco a poco en procesos internos maduros. El valor más práctico no está en las promesas grandilocuentes de «seguridad autónoma», sino en reducir el coste de la rutina y acelerar la revisión inicial sin perder el control. Si este enfoque se consolida, los equipos de seguridad podrán dedicar menos tiempo a la clasificación mecánica de tareas y más al modelado de amenazas, a los escenarios de ataque no triviales y a la prevención de errores antes del lanzamiento.

Para los grandes equipos de producto, probablemente ese será el efecto principal: no una reducción del papel del experto, sino un aumento notable de su capacidad de trabajo.

En esencia, se trata de redistribuir la atención hacia las áreas donde la experiencia humana aporta el máximo valor y donde la automatización aún no puede sustituir el criterio del ingeniero.