The EVerest Dataset for Secure Software Engineering
El artículo presenta el conjunto de datos EVerest, un recurso multi-artefacto único que comprende requisitos de seguridad, modelos arquitectónicos y código fuente de una pila de carga de vehículos eléctricos, lo cual permite la investigación de la verificación de seguridad de extremo a extremo y facilitó el descubrimiento y la remediación de una vulnerabilidad de seguridad del mundo real.
Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo
Imagina que estás construyendo una estación de carga de vehículos eléctricos de alta tecnología. Para asegurarte de que sea segura frente a los hackers, necesitas revisar tres capas diferentes de tu proyecto:
- La Lista de Deseos: Lo que los desarrolladores dicen que quieren (por ejemplo, "Debe ser seguro").
- El Plano: Los dibujos arquitectónicos que muestran cómo se conectan las partes.
- Los Ladrillos: El código informático real que hace funcionar la máquina.
El problema es que la mayoría de las herramientas de investigación solo miran una de estas capas. Pueden tener una lista de deseos, o un montón de código, pero nunca tienen las tres conectadas entre sí. Es como intentar arreglar un techo con goteras mirando únicamente los planos, sin llegar a revisar las tejas reales o la lista de quejas del propietario.
El Conjunto de Datos EVerest es un nuevo y gigante kit de herramientas "todo en uno" creado por investigadores del Instituto de Tecnología de Karlsruhe para solucionar esto. Conecta la Lista de Deseos, el Plano y los Ladrillos para un proyecto de software del mundo real llamado EVerest (que controla los cargadores de VE) de código abierto.
Así es como lo construyeron, utilizando una analogía sencilla:
1. Recopilación de la "Lista de Deseos" (Requisitos)
Primero, los investigadores necesitaban saber qué reglas de seguridad necesitaba realmente el proyecto.
- La Encuesta: Enviaron un cuestionario a la comunidad de desarrolladores, preguntando: "¿Cuáles son los objetivos de seguridad?" (Como preguntar: "¿Quieres que la puerta esté cerrada con llave?"). Esto les dio una lista aproximada de 67 ideas.
- La Entrevista: La lista aproximada era demasiado vaga. Por ello, se sentaron con cuatro desarrolladores expertos para tener conversaciones profundas. Tomaron esas ideas generales y las refinaron en instrucciones específicas, como cambiar "Cerrar la puerta con llave" por "El módulo OCPP debe rechazar la entrada malformada del CSMS".
- El Resultado: Terminaron con 84 requisitos de seguridad precisos.
2. Dibujo del "Plano" (Arquitectura)
El proyecto EVerest no tenía un mapa arquitectónico formal; solo tenía código.
- La Traducción: Tres estudiantes, supervisados por expertos, examinaron el código fuente y construyeron manualmente un modelo de componentes Palladio. Piensa en esto como tomar un montón de piezas de Lego y dibujar un diagrama detallado que muestra exactamente cómo se conecta cada pieza, qué datos fluyen entre ellas y cómo se comunican.
- El Resultado: Un plano digital con 29 componentes y 144 descripciones de servicio detalladas.
3. Etiquetado de los "Ladrillos" (Código y Elementos)
Ahora, necesitaban conectar los puntos entre la Lista de Deseos y el Plano.
- El Juego de Etiquetado: Tres personas revisaron los 84 requisitos y resaltaron palabras específicas. Etiquetaron cosas como "componentes", "datos", "estados" y "flujos de datos".
- El Rastro: Dibujaron líneas digitales (enlaces de traza) que conectaban una frase específica en el requisito (por ejemplo, "El proveedor de pago debe ser seguro) directamente con la parte específica del plano y el código que gestiona el pago.
- El Resultado: Etiquetaron 1,445 diminutos elementos de seguridad, creando una enorme red de conexiones.
La Prueba del Mundo Real
Lo mejor de este conjunto de datos no es solo que existe; es que realmente encontró un error real.
Mientras construían el conjunto de datos, los investigadores notaron una discrepancia. Uno de los requisitos decía: "Los tokens de autenticación no deben almacenarse en texto plano". Sin embargo, al observar el código real (los "ladrillos"), encontraron una línea donde el código sí estaba almacenando los tokens en texto plano.
- La Solución: Informaron de esto a los mantenedores del proyecto. Los desarrolladores confirmaron que era una debilidad real (conocida como CWE-1295) y la corrigieron de inmediato.
Por qué esto es importante
Antes de esto, los investigadores que intentaban construir herramientas para verificar automáticamente la seguridad del software tenían que adivinar cómo se relacionaban los requisitos, el diseño y el código porque ningún conjunto de datos proporcionaba las tres cosas.
El conjunto de datos EVerest es como un manual de entrenamiento completo y etiquetado para la IA y los investigadores. Les permite practicar:
- Enseñar a las computadoras a entender los requisitos de seguridad.
- Encontrar automáticamente dónde se implementa un requisito en el código.
- Comprobar si el software final coincide realmente con las promesas de seguridad originales.
En resumen, el artículo presenta un recurso único y de múltiples capas que cierra la brecha entre lo que el software debería hacer, cómo se diseña y cómo se construye, demostrando su valor al detectar un agujero de seguridad real en el proceso.
¿Ahogado en artículos de tu campo?
Recibe resúmenes diarios de los artículos más novedosos que coincidan con tus palabras clave de investigación — con resúmenes técnicos, en tu idioma.