Un automóvil moderno ya no es solo un motor y cuatro ruedas: es un sistema digital rodante. Con más de 100 millones de líneas de código distribuidas en decenas de unidades de control electrónico (ECUs), los llamados Software-Defined Vehicles (SDV) representan una revolución en la movilidad, pero también un nuevo frente de riesgo cibernético que la industria no puede seguir subestimando.

La promesa es atractiva: actualizaciones remotas, servicios personalizados, integración con smartphones y conducción cada vez más autónoma. Sin embargo, esa sofisticación tecnológica amplía la superficie de ataque de forma dramática, atrayendo la atención de ciberdelincuentes, actores estatales y grupos hacktivistas. En la práctica, los autos ya no solo se roban con ganzúas. También se vulneran con exploits.

Un ecosistema digital tan complejo como vulnerable

Para dimensionar el desafío: un Ford F-150 Lightning opera con 150 millones de líneas de código, muy por encima de un Boeing 787 Dreamliner, que requiere 6,5 millones. Ese software controla desde el frenado hasta el infoentretenimiento, desde el aire acondicionado hasta los sistemas de asistencia a la conducción.

Cada línea de código, cada módulo de terceros y cada servidor conectado es un potencial punto de entrada. Desde 2014, la conectividad LTE integrada permite a los fabricantes recopilar datos, enviar comandos remotos e instalar actualizaciones OTA. Lo mecánico se volvió digital. Y lo digital, por definición, es hackeable.

Según Precedence Research, el mercado de SDV crecerá de 43.000 millones de dólares en 2024 a más de 150.000 millones en 2030. La digitalización avanza a toda velocidad; la seguridad, en cambio, todavía intenta alcanzarla.

Principales vectores de ataque en los Software-Defined Vehicles

Los incidentes documentados en fabricantes como Toyota, Nissan y Daimler confirman que los riesgos no son hipotéticos. Los vectores más críticos:

• Infoentretenimiento (IVI): sistemas basados en Linux embebido que almacenan datos sensibles y están conectados a componentes críticos del vehículo. Un acceso no autorizado aquí puede escalar hasta los frenos o la dirección asistida.
• Servidores telemáticos: encargados de recibir datos y ejecutar comandos remotos. Blanco ideal para ataques de control total, especialmente en flotas comerciales donde el impacto se multiplica por cada unidad comprometida.
• Actualizaciones OTA manipuladas: si se interceptan, permiten instalar malware o ransomware en flotas enteras sin que el conductor detecte nada anómalo hasta que es demasiado tarde.
• Credenciales hardcoded: claves incrustadas en el código que, al filtrarse, exponen APIs, apps móviles y servicios en la nube a cualquiera que las encuentre en un repositorio público.

Esto no es una amenaza teórica. Es la consecuencia directa de conectar sistemas críticos a redes públicas sin los controles adecuados. En este escenario, un ataque no compromete solo la privacidad de los datos: compromete la seguridad física de los pasajeros.

El problema estructural de la cadena de suministro

La realidad es que el 85% del software automotriz utiliza componentes de terceros o de código abierto. Una sola vulnerabilidad puede propagarse entre múltiples fabricantes al mismo tiempo, convirtiendo un descuido de un proveedor menor en una crisis de seguridad de escala industrial.

Uno de los puntos más críticos son los "secrets" mal gestionados: claves, certificados y credenciales incrustados en el código sin rotación ni control de acceso. El informe State of Secrets Sprawl 2023 de GitGuardian reveló más de 10 millones de secretos expuestos en repositorios públicos en solo un año. En la industria automotriz, ese descuido puede abrir acceso directo a telemática, apps móviles o bases de datos de clientes.

Un secreto hardcoded en el software de un vehículo no es solo un riesgo de privacidad: es una vulnerabilidad que puede poner en juego la seguridad física de miles de conductores.

Seamos claros: la gestión proactiva de vulnerabilidades en componentes de terceros no es una buena práctica recomendable. Es la línea de defensa que separa un incidente contenido de una crisis de seguridad pública. Una auditoría continua de vulnerabilidades en toda la cadena de suministro es el primer paso que la industria debe normalizar, no postergar.

La presión regulatoria y el debate del derecho a reparar

La industria automotriz enfrenta un doble desafío regulatorio: cumplir con marcos de privacidad como GDPR en Europa o CCPA en California y, al mismo tiempo, responder al debate sobre el derecho a reparar.

Abrir los sistemas a talleres independientes facilita la transparencia y la competencia. Pero si no existen protocolos de seguridad estrictos para ese acceso, se convierte en otra entrada potencial para actores malintencionados. La regulación establece el piso mínimo. El techo lo define cada fabricante con sus decisiones de arquitectura y control de acceso.

El factor humano que los controles técnicos no pueden ignorar

Los controles técnicos son necesarios, pero insuficientes por sí solos. Un ingeniero que no gestiona correctamente sus credenciales de acceso al repositorio de firmware, un proveedor que integra dependencias sin auditar, o un equipo de OTA que no valida la firma criptográfica de cada actualización: cualquiera de esos puntos puede derribar los controles más sofisticados de una arquitectura SDV.

En Latinoamérica, la situación añade otra capa de complejidad. El mercado de autos conectados crece con fuerza en México y Brasil, pero sin marcos regulatorios maduros en ciberseguridad automotriz ni programas de formación sectorial que cierren la brecha de talento. La vulnerabilidad no es solo tecnológica: es de cultura de seguridad.

Hacia un modelo de ciberseguridad sostenible para los SDV

La protección de los vehículos definidos por software no puede limitarse a controles de última hora insertados al final del ciclo de desarrollo. Debe integrarse desde el principio:

• Seguridad desde el diseño: cifrado, gestión de secretos y protocolos de acceso desde la primera línea de código, no como capa adicional, sino como parte del proceso de ingeniería.
• Auditoría de proveedores: exigir estándares verificables a cada proveedor de software o componente embebido, con revisiones periódicas y trazabilidad completa de dependencias.
• Monitoreo continuo de telemática y OTA: con alertas ante comportamientos anómalos en tiempo real, no auditorías trimestrales que llegan tarde a cada incidente.
• Planes de respuesta y resiliencia: procedimientos claros para aislar incidentes, notificar a los afectados y restablecer operaciones sin comprometer la seguridad en carretera ni escalar el impacto.

Conclusión: la seguridad del vehículo es seguridad pública

El automóvil moderno es un sistema crítico. Cuando falla un firewall bancario, el riesgo es financiero. Cuando falla el software de un vehículo en movimiento, el riesgo es vital. La industria automotriz no puede tratar ambos escenarios con la misma prioridad ni la misma inversión.

La pregunta ya no es si los Software-Defined Vehicles son vulnerables. Los datos confirman que lo son. La pregunta real es si la industria y los reguladores están dispuestos a construir la ciberseguridad automotriz que la magnitud del riesgo exige, antes de que un incidente de escala mayor los obligue a hacerlo por decreto.