Security Vulnerabilities in Software Supply Chain for Autonomous Vehicles

Los vehículos autónomos no son meramente coches con motores avanzados; son computadoras sobre ruedas, donde la seguridad de los pasajeros y peatones depende enteramente de líneas de código. Estas máquinas dependen de una compleja cadena de suministro de software, una vasta red de ingredientes digitales que los desarrolladores entrelazan para que el coche vea, piense y se mueva. Esta cadena incluye el código original escrito por el fabricante del automóvil, pero también depende fuertemente del software de código abierto —bloques de construcción disponibles gratuitamente creados por comunidades de programadores en todo el mundo. Si bien este enfoque compartido acelera la innovación y permite la prueba rápida de nuevas ideas, introduce un peligro único: si una sola pieza de este software compartido contiene un fallo oculto, esa debilidad puede propagarse a través de todo el sistema, haciendo que el vehículo potencialmente malinterprete su entorno o no se detenga. A medida que estos vehículos pasan de los laboratorios de investigación a las carreteras públicas, asegurar la integridad de cada componente digital se convierte en una cuestión de vida o muerte.

Investigadores de la Universidad de Alabama se propusieron examinar la salud de este fundamento digital observando directamente el código de tres de las plataformas de vehículos autónomos de código abierto más prominentes: Autoware, Apollo y openpilot. Estos proyectos representan la vanguardia de la tecnología de conducción autónoma, con Autoware y Apollo apuntando a altos niveles de automatización donde el coche se conduce a sí mismo, y openpilot enfocándose en sistemas de asistencia al conductor que ayudan a los humanos a mantener el control. El equipo trató estos repositorios de software como un mecánico inspeccionando un motor complejo, pero en lugar de buscar pernos oxidados, utilizaron herramientas de escaneo especializadas para buscar grietas digitales. Se centraron en dos áreas principales: el código escrito por los propios equipos del proyecto, y las librerías de terceros —fragmentos de código preescritos tomados de otras fuentes— en los que estos proyectos dependen para funcionar.

La investigación reveló que, si bien estas plataformas son poderosas, no son inmunes a los errores comunes que plagan al software en todas partes. Los investigadores encontraron que el código contenía patrones recurrentes de debilidad conocidos como enumeraciones de debilidades comunes. En el código escrito en C y C++, lenguajes utilizados a menudo para las tareas pesadas de la conducción, los escaneos identificaron problemas relacionados con la gestión de memoria, como desbordamientos de búfer (buffer overflows), donde los datos se desbordan de su espacio de almacenamiento previsto y pueden corromper el sistema. En el código Python, utilizado a menudo para la planificación y herramientas de alto nivel, los escaneos descubrieron problemas con la forma en que el software maneja situaciones e entradas inesperadas. Uno de los problemas más frecuentes encontrados en los tres proyectos fue el manejo inadecuado de condiciones excepcionales, lo que significa que el software a veces fallaba al reaccionar correctamente cuando las cosas salían mal. Otro hallazgo importante fue la presencia de fallos de inyección de comandos, donde un actor malicioso podría potencialmente engañar al sistema para que ejecute comandos no autorizados.

El estudio también profundizó en la cadena de suministro, examinando los miles de paquetes externos de los que dependen estos vehículos. Los resultados aquí fueron marcadamente diferentes según el proyecto. La plataforma Apollo, que está diseñada para la producción a gran escala, resultó tener una vasta cantidad de dependencias, y el escaneo identificó 91 de estos componentes externos con vulnerabilidades de seguridad conocidas. Entre estas se encontraban fallos críticos en paquetes utilizados para el manejo de archivos y renderizado web, algunos de los cuales podrían permitir a un atacante tomar el control del sistema o acceder a datos sensibles. En contraste, el proyecto openpilot, que tiene un alcance más estrecho, mostró muchos menos problemas con sus dependencias externas, detectando solo un componente vulnerable. El proyecto Autowware mostró la menor cantidad de problemas en esta área, ya que los escaneos no encontraron vulnerabilidades conocidas en sus librerías de terceros al momento del estudio.

A pesar de las diferencias en la cantidad de fallos encontrados, el mensaje central de la investigación es claro: el software que impulsa estos vehículos está actualmente expuesto a riesgos significativos. Los investigadores señalaron que casi la mitad de todos los ciberataques en el sector automotriz ya explotan debilidades en los sistemas de software, y su análisis confirma que estas vulnerabilidades existen en el mismísimo código que debe mantener a las personas seguras. El estudio no encontró que los sistemas estén rotos sin reparación, sino más bien que están construidos sobre un fundamento que requiere vigilancia constante. Los autores sugieren que la seguridad no puede ser una ocurrencia tardía; debe estar tejida en el proceso de desarrollo desde el principio. Mediante el uso de herramientas automatizadas para verificar continuamente estos fallos y mediante la gestión cuidadosa de los componentes de software que se incorporan al sistema, los desarrolladores pueden reducir el riesgo de fallos catastróficos. El trabajo sirve como un recordatorio de que, en un mundo cada vez más automatizado, la seguridad de la máquina depende de la seguridad de su código.