Qué CVEs importan de verdad en tu firmware (y cuáles puedes justificar que no)

Pasa un escáner sobre cualquier imagen de Linux embebido y te saldrán cientos de CVEs. El Cyber Resilience Act no te pide que esa lista llegue a cero. Te pide que el producto salga al mercado sin vulnerabilidades explotables conocidas (anexo I) y que gestiones las que vayan apareciendo durante todo el periodo de soporte. La palabra que importa es explotables.

Este artículo es el método para pasar de la lista del escáner a esa otra lista, mucho más corta: lo que hay que arreglar ya, lo que puede esperar y lo que puedes justificar por escrito que no te afecta.

Por qué la severidad no basta

La columna “Critical / High” del escáner es la puntuación base de CVSS. Mide lo grave que es la vulnerabilidad en abstracto, sin saber nada de tu dispositivo. Dos ejemplos de lo que se le escapa:

• Una CVE crítica en una función de una biblioteca que tu firmware nunca llama pesa lo mismo que una en la función que usa tu servidor web.
• El vector de ataque viene en la propia puntuación (AV:N es por red, AV:L local, AV:P con acceso físico), pero el escáner no sabe si tu dispositivo tiene ese puerto abierto, ese USB accesible o a alguien con una shell.

La severidad sirve para ordenar dentro de un grupo. No sirve para decidir qué importa.

Dos señales de fuera: KEV y EPSS

Antes de mirar el dispositivo, cruza la lista con dos fuentes públicas y gratuitas:

• KEV (Known Exploited Vulnerabilities), el catálogo de CISA de vulnerabilidades que se están explotando de verdad. ENISA publica también una vista de vulnerabilidades explotadas en la base de datos europea de vulnerabilidades (EUVD), en marcha desde 2025. Una CVE de esa lista en un componente de tu imagen es la primera de tu cola, sin discusión.
• EPSS (Exploit Prediction Scoring System), de FIRST: la probabilidad, de 0 a 1, de que una CVE se explote en los próximos 30 días. Se recalcula a diario para todas las CVEs.

Los escáneres habituales ya lo traen: Grype, por ejemplo, añade EPSS y KEV a cada resultado. Un matiz importante: EPSS sirve para ordenar, no para descartar. Una probabilidad baja no significa que no te afecte, solo que hoy nadie la está aprovechando a escala.

Y una conexión con el reglamento: desde el 11 de septiembre de 2026, si una vulnerabilidad de tu producto se está explotando activamente, tienes 24 horas para enviar una alerta temprana. Vigilar KEV y la EUVD contra el SBOM de cada versión publicada es la forma más directa de enterarte a tiempo.

Lo que ningún catálogo sabe: tu dispositivo

Aquí es donde la lista se reduce de verdad. Para cada CVE que quede, cinco preguntas, en este orden:

1. ¿Está el componente en la imagen? Parece obvio, pero los escáneres que solo miran versiones se equivocan a menudo: paquetes que se llaman igual, herramientas de compilación que no llegan al rootfs.
2. ¿Está compilado el código vulnerable? Muchas CVEs afectan a una función opcional: un módulo del kernel, una opción de PACKAGECONFIG en Yocto, un backend de una biblioteca. Si tu build no lo incluye, no te afecta.
3. ¿Se ejecuta? El binario puede estar en la imagen sin que ningún servicio lo use.
4. ¿Puede un atacante llegar a él? Un fallo en el análisis de imágenes importa si tu dispositivo procesa imágenes que vienen de fuera; uno en un servicio importa si ese servicio escucha en la red. Aquí entran los puertos abiertos, las interfaces físicas y de dónde vienen los datos que procesa.
5. ¿Hay algo que lo mitigue? El servicio solo escucha en localhost, corre sin privilegios, hay un cortafuegos que no se puede desactivar, o la opción vulnerable está deshabilitada en la configuración.

Cada “no” es un descarte, y cada descarte tiene un nombre estándar. Los formatos VEX (OpenVEX, CycloneDX, CSAF) usan casi las mismas justificaciones que esas preguntas: component not present, vulnerable code not present, vulnerable code not in execute path, vulnerable code cannot be controlled by adversary, inline mitigations already exist. Lo que escribas tiene que poder comprobarlo otra persona: “nscd no está instalado” sirve; “no creemos que aplique”, no.

El caso del kernel

El kernel merece apartado propio. Desde febrero de 2024, el propio proyecto es autoridad de numeración de CVEs y asigna una a casi cualquier corrección que pueda tener impacto en la seguridad: su política parte de que casi cualquier fallo del kernel podría llegar a ser explotable. El resultado son miles de CVEs al año (más de cinco mil en 2025, según las cifras de Greg Kroah-Hartman) y un kernel de producto que acumula cientos.

Dos filtros las reducen mucho:

• La rama estable. El proyecto publica, para cada CVE, en qué versiones estables está corregida (repositorio vulns de kernel.org). Si tu kernel es una LTS al día, muchas ya están cerradas aunque el escáner, que solo ve “6.6”, no lo sepa.
• Tu .config. Muchas CVEs del kernel están en drivers y subsistemas concretos. Cruzando los ficheros que toca cada corrección con lo que tu configuración compila, una buena parte cae por la pregunta 2.

Lo que queda después de esos dos filtros es lo que hay que mirar a mano. Y la decisión de fondo, si actualizar a la siguiente versión estable o pasar a una rama más nueva, sale de ahí.

Un orden de trabajo

Con todo lo anterior, la cola queda así:

1. Explotadas (KEV o EUVD) en componentes presentes: arreglar ya y valorar si hay que notificar.
2. Servicios expuestos a la red (SSH, servidor web, broker MQTT, API de gestión) con vector de ataque por red, ordenados por EPSS.
3. Código que procesa datos de fuera: TLS, analizadores de formatos, bibliotecas de imagen o de compresión.
4. El kernel, ya filtrado por rama estable y configuración.
5. El resto: documentado en tu VEX con su justificación, y revisado en cada versión nueva.

El paso 5 no es trabajo perdido. Es exactamente la evidencia que el CRA espera ver en la documentación técnica, y lo que vas a enseñar cuando un cliente o una autoridad pregunte por qué tu imagen “tiene 300 CVEs”. Cómo declararlo en el build está en el artículo anterior, sobre cómo sacar el SBOM de tu firmware.

Si quieres que lo hagamos nosotros

Ese triaje es el núcleo de nuestro Quick Scan: nos envías la imagen, cruzamos el SBOM con KEV, EPSS, los datos del kernel y la configuración de tu dispositivo, y en 48 horas laborables recibes las vulnerabilidades que de verdad aplican, los descartes justificados y lo que falta frente al CRA. Si prefieres verlo antes con tu caso, reserva 30 minutos.