Faltan ingenieros de seguridad: automatización, IA y SOP limpio

No hay suficiente gente para hacer este trabajo. Ese es el hecho incómodo detrás de la ciberseguridad del automóvil, y va a peor, no a mejor.

Las cuentas no cuadran

Los estudios de fuerza laboral de ISC2 han situado el déficit mundial de ciberseguridad en los millones, alrededor de 4.8 million según su estimación de 2026, con un campo que necesita crecer aproximadamente un 87% para cubrir la demanda. Cerca del 90% de los equipos de seguridad reportan una brecha de habilidades.

Ahora reduce eso al ámbito del automóvil. Probar una ECU no es seguridad informática general. Hace falta gente que conozca CAN y CAN FD, UDS y DoIP, SecurityAccess, las sesiones de diagnóstico y las restricciones de tiempo real de un objetivo embebido, y que pueda mapear todo ello con ISO/SAE 21434. Ese es un subconjunto diminuto y sobrecargado de un campo que ya de por sí escasea. Mientras tanto, el mercado de la ciberseguridad del automóvil crece rápido, desde unos cuatro mil millones de dólares en 2026 hacia los doce mil millones y más allá a principios de la década de 2030. La demanda escala un precipicio mientras la cantidad de gente capaz de probar de verdad una unidad de control apenas se mueve.

Luego cuenta el trabajo. Un programa de vehículo moderno tiene docenas de ECU. Cada una tiene muchas versiones de camino a producción, y más después. Si las pruebas de seguridad en profundidad dependen de reservar a uno de los pocos especialistas para cada versión de cada ECU, la cola es más larga que el programa. Algo cede, y normalmente son las pruebas.

El SOP es un muro contra el que solo chocas una vez

El inicio de producción no se mueve. Cuando un vehículo llega al SOP, el coste de un defecto de seguridad cambia por completo: lo que antes del arranque de la línea era un comentario de revisión de código se convierte, después, en una campaña de campo o una retirada. Y bajo UN R155 e ISO/SAE 21434 no puedes simplemente lanzar y cruzar los dedos. Tienes que demostrar que las mitigaciones se probaron y que los problemas conocidos se resolvieron.

Así que el objetivo real es concreto: llegar al SOP sin nada fácil de detectar que se conozca. No una ECU perfecta, que nadie puede prometer, sino una en la que los hallazgos obvios, de alto impacto, de la primera hora han desaparecido y están documentados. Servicios de diagnóstico accesibles sin autenticación. SecurityAccess débil o por defecto. XCP o CCP expuestos. Identificadores escribibles que deberían estar bloqueados. Son comunes, son devastadores, y son completamente evitables, si alguien los prueba en cada versión.

Esa última frase es todo el problema. Un único pentest previo al SOP es una instantánea del software que tenías esa semana. La ECU sigue cambiando. Una función añadida dos sprints después vuelve a abrir en silencio un servicio, y nadie prueba de nuevo hasta la siguiente auditoría, momento en el que ya está en el coche.

No puedes salir de esto contratando. Puedes multiplicar

El instinto es contratar más especialistas. Es el instinto correcto y no basta, porque esa gente no está disponible para contratar, y ni siquiera un equipo duplicado puede volver a probar manualmente cada versión de cada ECU.

Aquí es donde la IA y la automatización cambian la economía unitaria, y vale la pena ser preciso sobre cómo. La IA no cerrará la brecha de habilidades por sí sola, y cualquiera que te diga que reemplaza a tus ingenieros de seguridad te está vendiendo algo. Lo que sí hace, y bien, es potenciar al equipo que ya tienes: codificar lo que hace un buen probador a mano en motores que corren sin él, para que los escasos humanos se dediquen al trabajo que solo los humanos pueden hacer.

En concreto, el conocimiento de cómo enumerar una pila UDS, sondear SecurityAccess, hacer fuzzing a una interfaz de forma segura o recorrer una pasarela DoIP es estable y repetible. No necesita a un especialista presente cada vez. Necesita a un especialista una vez, para construir la prueba, y luego a una máquina que la ejecute en cada versión para siempre. El especialista queda entonces libre para la ruta de ataque nueva, el TARA, lo que la automatización no puede imaginar.

Cómo se ve esto en un programa real

Esto es exactamente para lo que está hecho AutoST. Sus motores llevan el conocimiento de las pruebas: enumeración UDS, análisis de SecurityAccess (0x27), fuzzing de UDS y CAN, DoIP y SOME/IP, IVI Android. Conectas la ECU a un banco una vez, y a partir de ahí AutoST corre desde la API y en CI.

Así, las pruebas pasan de “un especialista, si hay alguno libre, antes de la auditoría” a “automáticamente, en cada versión importante”. Cada compilación de cada ECU recibe la misma pasada de seguridad de base. Lo fácil de detectar se atrapa en el momento en que se introduce, no se descubre en el coche. Para el SOP tienes un rastro fechado que muestra que cada versión se probó y que los problemas conocidos se cerraron, que es justo lo que un evaluador de ISO/SAE 21434 quiere ver.

Y los pocos ingenieros de seguridad que tienes dejan de gastar sus escasas horas en volver a encontrar el mismo SecurityAccess débil en la cuadragésima ECU. Las gastan en los ataques que de verdad necesitan a un humano.

La versión honesta

La automatización no hace innecesarios a los ingenieros de seguridad. Hace que los que tienes cuenten. AutoST se encarga de la amplitud y la regresión para que un equipo pequeño pueda cubrir un programa de vehículo entero y llegar al SOP sin nada fácil de detectar que se conozca. La profundidad, la creatividad, el TARA y la auditoría siguen necesitando gente, y Zyberum también aporta eso, como un equipo que ha llevado programas de Tier 1, Tier 2 y OEM por exactamente este camino. Hay referencias disponibles a petición.

Si tu programa tiene más ECU que ingenieros de seguridad, que es el caso de casi todos, esa brecha es el problema que AutoST se hizo para cerrar. Reserva una demo y te mostraremos cómo es de verdad probar cada versión.