Anexo · Aerodry frente al anexo I del CRA, requisito a requisito

Este es el informe que sirve de base a la entrada 002. Es el formato que entregamos a los clientes: cada requisito esencial del anexo I, el estado en el prototipo, la evidencia concreta que sustenta ese estado, y la naturaleza de la corrección. La última columna suele ser la que sorprende, porque muestra cuántos requisitos no se resuelven tocando el código.

Estado: ✗ no cumple · ◑ cumple en parte · ✓ cumple · N/A no se aplica.

Parte I, propiedades de seguridad del producto

#	Requisito (anexo I, Parte I)	Estado	Evidencia en el prototipo	Naturaleza de la corrección
1	Sin vulnerabilidades explotables conocidas al ser introducido en el mercado	◑	Dependencias congeladas, sin proceso de triaje de CVE	Proceso y SBOM
2	Configuración segura por defecto	✗	Contraseña de acceso fija y compartida; servicios en claro por defecto	Firmware y fabricación
3	Corrección de vulnerabilidades mediante actualizaciones	◑	El mecanismo OTA existe, pero sin canal seguro	Firmware e infraestructura
4	Protección contra accesos no autorizados	✗	Dirección de actualización y servidor sin autenticación	Firmware e infraestructura
5	Confidencialidad de los datos, incluido el cifrado en reposo y en tránsito	✗	HTTP en claro; Wi-Fi de la casa guardada sin cifrar	Firmware
6	Integridad de datos, comandos, configuración y firmware	✗	Firmware sin firma; comandos sin verificación	Firmware e infraestructura
7	Recoger solo los datos necesarios	✓	Solo temperatura, humedad y estado del relé	Mantener en el diseño
8	Disponibilidad de las funciones esenciales	◑	Los cortes de seguridad existen; sin protección de red contra denegación de servicio	Firmware
9	No perjudicar a otros aparatos ni a la red	✓	Superficie reducida, sin efecto de amplificación	Mantener en el diseño
10	Minimizar la superficie de ataque	◑	Pocos servicios, pero el OTA por HTTP está siempre activo	Firmware
11	Reducir el impacto de un incidente	✗	Sin separación entre la función de control y la interfaz de red	Firmware
12	Registrar la actividad relevante para la seguridad	✗	Hay registros operativos, pero no de eventos de seguridad	Firmware
13	Permitir borrar datos y ajustes al final de la vida útil	✗	Sin restablecimiento seguro; las credenciales persisten en la reventa	Firmware y documentación

Parte II, tratamiento de vulnerabilidades

#	Requisito (anexo I, Parte II)	Estado	Evidencia en el prototipo	Naturaleza de la corrección
1	Inventario de componentes (SBOM legible por máquina)	✗	Dependencias copiadas al repositorio, sin SBOM	Documentación y build
2	Corregir las vulnerabilidades sin demora	◑	El mecanismo existe; el proceso de respuesta no	Firmware y proceso
3	Pruebas de seguridad regulares	✗	Sin ciclo de pruebas definido	Proceso
4	Divulgar las vulnerabilidades corregidas	✗	Sin canal ni historial de seguridad del producto	Proceso y organización
5	Política de divulgación coordinada de vulnerabilidades	◑	El security.txt del sitio es un embrión; faltan PGP y política del producto	Organización
6	Facilitar la notificación de vulnerabilidades	◑	Hay contacto genérico; falta un contacto de seguridad dedicado	Organización
7	Distribuir las actualizaciones de forma segura	✗	OTA sin firma y sin canal cifrado	Firmware e infraestructura
8	Actualizaciones de seguridad disponibles sin demora y gratuitas	◑	Técnicamente posible; sin período de soporte asumido	Proceso e infraestructura

Recuento

Son 21 requisitos aplicables, 13 en la Parte I y 8 en la Parte II. Se cumplen 2, se cumplen en parte 8, y fallan 11.

La entrada 002 describe nueve fallos: son los que tienen consecuencia directa para quien usa el producto, y se reparten entre las dos partes. Este anexo muestra el cuadro completo, incluido lo que la entrada no desarrolla, como las lagunas de proceso de la Parte II, menos visibles pero igualmente exigidas.

La lectura por naturaleza de la corrección

Si miramos las correcciones por su naturaleza, en lugar de requisito a requisito, el firmware aparece en unos once requisitos, pero casi nunca solo. La infraestructura aparece en unos seis, el proceso en unos siete, la documentación en unos cuatro, y la organización en unos cuatro. La fabricación aparece solo en uno, el de la contraseña por unidad, pero es de corrección obligatoria y no se resuelve en código.

La suma pasa de los 21 porque la mayoría de los requisitos necesita más de una naturaleza de corrección al mismo tiempo. Es esa superposición la que convierte la secuencia del trabajo, el tema de la entrada 003, en el verdadero valor del servicio, y no la lista en sí.