Anexo · Aerodry frente al anexo I del CRA, requisito a requisito
El informe de conformidad completo al que se refiere la entrada 002. El mismo formato que producimos para fabricantes, aplicado a nuestro propio prototipo.
- Publicado
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í.