Qué es una CNA: la autoridad que asigna los CVE

¿Qué es una CNA y por qué te debería importar? Una CNA (CVE Numbering Authority) es una entidad autorizada por el programa CVE para asignar, mantener y distribuir identificadores de vulnerabilidades en productos de diferentes vendors. Cada CNA opera dentro de un alcance o scope definido: no puede emitir un CVE sobre cualquier software del mundo, sino sobre el que le corresponde según su rol. En palabras de la charla, una CNA funciona como un puente entre vendors, researchers y el ecosistema de CVEs en general.

Entender qué es una CNA importa por una razón práctica: el identificador que leerás en tu herramienta de gestión de vulnerabilidades nació de un proceso con reglas, tiempos y disputas. Hoy existen 544 CNAs en el mundo, distribuidas en 43 países, más una que no tiene afiliación a país alguno. Tres de ellas son CNA Last Resort, un rol especial del que hablaremos más abajo.

Sus tres funciones responden en la práctica qué es una CNA: asignar CVEs (el identificador único con formato CVE-año-número para una vulnerabilidad en una versión concreta de un software), publicar y mantener los registros de cada CVE, y coordinar el disclosure responsable entre quien reporta y quien desarrolla el producto afectado.

La CNA de Fluid Attacks: cinco años siendo la primera de Colombia

Fluid Attacks cumple cinco años como CNA y sigue siendo la primera y única en Colombia. Sus números, presentados en la charla: 111 CVEs en 2025 y 33 en 2024, con 194 advisories publicados, de los cuales 143 vienen de researchers internos, 39 de un escáner de IA que el equipo desarrolla y 12 de researchers externos. Por severidad: 47 críticos, 80 altos, 85 medios y 8 bajos.

Ser CNA no cuesta dinero y no paga nada: es trabajo por y para la comunidad. Los requisitos formales son tener una política de divulgación pública, una fuente pública donde vivan todos los advisories —la de Fluid Attacks está en fluidattacks.com/advisories— y un punto de contacto para researchers y vendors. A cambio, la organización demuestra madurez en gestión de vulnerabilidades y gana control sobre qué y cuándo publica.

La jerarquía del programa: roots, top-level roots y Last Resort

El programa CVE se organiza como una pirámide. En la base están las 541 CNAs "comunes". Encima, los roots: cada CNA tiene una autoridad padre a la que responde (hay 10, entre ellas Mitre, CISA, Google y el INCIBE de España). En la cima, dos top-level roots: Mitre, fundador del programa, y CISA. Completan la estructura un board que toma las decisiones, un secretariat administrativo, grupos de trabajo y los ADP (Authorized Data Publisher), que enriquecen los datos del programa.

¿Y las CNA Last Resort? Son la válvula de escape del sistema: cuando la CNA con el scope adecuado no responde, o cuando un researcher quiere escalar una disputa, el caso pasa a una de estas tres autoridades. La disputa no invalida el CVE: solo marca que vendor y CNA no llegaron a un acuerdo total, algo que el propio programa contempla como parte del ciclo.

Tipos de CNA: de vendor a AI Researcher

Saber qué es una CNA también implica saber que no todas hacen lo mismo. La charla repasa los tipos: las CNA vendor (443 de las 544) emiten CVEs solo para sus propios productos, como Microsoft; las open source gestionan vulnerabilidades de proyectos de código abierto; las CNA researcher, como Fluid Attacks, buscan y reciben vulnerabilidades de software de terceros que no estén en el scope de otra autoridad; también existen CNA de servicios en la nube, plataformas de bug bounty que actúan como CNA, consorcios para proyectos concretos y el tipo más nuevo: las AI Researcher, creadas para vulnerabilidades en modelos de inteligencia artificial. De estas últimas solo hay dos en el mundo (Anthropic y OpenAI) y entraron en juego hace muy poco, desde agosto.

En 2026 ya salieron 62 CNAs nuevas. La distribución global sigue concentrada en Norteamérica y Europa: los países con más CNAs son Estados Unidos, Brasil con dos en Latinoamérica, China con 14, Alemania con 23, además de Corea del Sur, Sudáfrica y Australia.

El susto de 2025: el programa CVE casi se queda sin fondos

La parte menos conocida de qué es una CNA es su fragilidad institucional. En 2025, la administración de Trump retiró los fondos que sostenían el programa CVE, que dependía del gobierno de Estados Unidos a través del Homeland Security. La base de datos completa —el mapa que le dice al mundo qué producto y qué versión tienen una vulnerabilidad— estuvo a punto de caerse. El programa se salvó con fondos que entraron por CISA en el último minuto.

El episodio dejó dos consecuencias. Primero, la creación de la CVE Foundation, una entidad para sostener el programa a largo plazo. Segundo, el nacimiento de iniciativas más descentralizadas: GCV, impulsada desde Luxemburgo; GENEAS, un modelo al que Fluid Attacks ya solicitó unirse; y la base de datos de vulnerabilidades de Europa. El problema nuevo es la fragmentación: cuando todos emiten identificadores distintos para el mismo problema, deja de saberse de quién hablan. El CVE sigue siendo el más utilizado, y su formato con año incluido permite estimar la antigüedad de una vulnerabilidad de un vistazo.

Cómo funciona el proceso de un CVE dentro de una CNA

1. El reporte y lo que la CNA no acepta

Todo empieza en el punto de contacto público: un formulario o un correo. Ahí se pide vendor, producto, versión, descripción, detalles técnicos, una prueba de concepto, un video de la explotación y un CVSS propuesto que se discute antes de aceptar. La CNA de Fluid Attacks no acepta software académico ni proyectos estudiantiles, tampoco hallazgos que vengan de programas de bug bounty (esas plataformas suelen ser CNA ellas mismas) ni nada dentro del scope de otra autoridad. Como referencia de madurez del proyecto, mencionan uno con más de mil estrellas, sin que ese número sea un filtro estricto.

2. Triaje: evidencia e impacto

El equipo monta un ambiente local y replica la vulnerabilidad, igual que haría la validación de un bounty. Sin evidencia e impacto no hay CVE: la regla es que la vulnerabilidad debe existir y afectar un producto público. El código privado de un cliente, por ejemplo, no aplica.

3. Contacto con el vendor y la regla de los 90 días

El contacto se hace por dos vías: el Security Advisory de GitHub del proyecto o correo electrónico, con una plantilla que acredita al researcher que encontró el fallo, el tipo de vulnerabilidad, la severidad y el score sugerido. La CNA insiste en hacer ella el contacto: presentarse como CNA hace que el vendor tome más en serio la conversación.

De ahí salen cuatro escenarios: el vendor no responde (se insiste), el vendor responde y luego desaparece, la CNA misma considera que no es CVE (un no que se puede conversar) o el vendor lo niega. El caso ideal es el fix antes del publication. La regla de la industria: publicar antes de 90 días, con flexibilidad si el vendor ya tiene parche y pide esperar a que sus usuarios actualicen.

4. El advisory: timeline y hasta nombre de banda

Cada advisory publica el timeline completo: cuándo se descubrió la vulnerabilidad, cuándo se contactó al vendor, cuándo respondió, cuándo se parchó y cuándo salió a luz. El nombre del advisory incluye software, versión y tipo de fallo, y los researchers pueden bautizarlo: los advisories de Fluid Attacks llevan nombres de bandas y artistas. Cuando no hay mitigación posible, el advisory igual sale: la comunidad necesita saber que esa versión tiene un problema.

War stories: lo bueno, lo malo, lo feo y lo redimido

La sección favorita del público: "los chismes de cosas que nos han pasado". Aquí se ve qué es una CNA cuando el proceso se rompe. Lo bueno: un vendor que respondió amable, parchó en cuatro días y al quinto publicó parche, CVE y hasta su propio advisory referenciando el original. Lo malo: un caso de julio de 2025 en que, tras intentos de contacto por correo y GitHub, el maintainer respondió que no iba a registrarse en la plataforma privada y que "no le mandaran más correos de marketing"; tras un mes de silencio se publicó, el vendor se molestó y el caso quedó disputado y escalado a Mitre. Lo feo: un maintainer que nunca respondió en diez días; se publicó y al día siguiente argumentó que estaba de vacaciones, que era "un pobre maintainer de un proyecto chiquito" —un proyecto gigante con un montón de estrellas—, que la falla era "de Python, no de su librería", y llegó a cambiar el README de su repositorio para anunciar que el CVE no era válido; el equipo core de Python confirmó que la responsabilidad era de la librería y la disputa igual terminó escalada.

Lo redimido cierra con la mejor historia: coordinando una vulnerabilidad en DOMPurify —una librería muy importante de JavaScript, mantenida por Cure53—, otro actor publicó el hallazgo por su cuenta sin coordinar con el vendor. El vendor pidió ayuda, el caso se escaló a Mitre, Mitre dio la razón a Fluid Attacks y le transfirió el ownership del CVE. ¿La decisión del equipo? Publicar con atribución a todos los researchers, los propios y los de la otra autoridad, referenciando ambos advisories.

Preguntas frecuentes

¿Qué es una CNA y en qué se diferencia de un CSIRT?

Una CNA asigna y gestiona identificadores CVE dentro de un scope definido. Un CSIRT es un equipo de respuesta a incidentes; también existen CNA de ese tipo, pero el rol de numerar vulnerabilidades es propio del programa CVE.

¿Qué es una CNA y cómo se financia?

"Una CNA es por amor al arte", respondió el equipo en las preguntas del público cuando le preguntaron qué es una CNA en términos de sostenimiento. No hay pago ni recompensa: la organización patrocinadora dedica personas, como hace Fluid Attacks, y el trabajo se ofrece para contribuir a la comunidad.

¿Qué pasa si un vendor no está de acuerdo con un CVE?

Puede escalar el caso y marcarlo como disputado. Ni Mitre ni el programa castigan a nadie por una disputa: es parte del ciclo, y el identificador sigue siendo válido como señal para la comunidad.

¿Los CTF sirven para llegar a publicar CVEs?

Como entrenamiento, sí. El equipo destaca que los retos de CTF a veces son más difíciles que vulnerabilidades reales: son buena forma de empezar en el camino y forjar experiencia.

¿Existe una ley que obligue a los vendors a corregir?

No a nivel global. La presión viene de los usuarios y, según el país, de gobiernos y CSIRTs. Hay normas ISO que explican cómo hacer responsible disclosure, pero ninguna obliga a remediar; a veces el propio CVE revela que un proyecto que todos usaban ya no tiene maintainer.

Conclusión

Saber qué es una CNA es entender quién sostiene el lenguaje común de la gestión de vulnerabilidades: 544 autoridades en 43 países, scopes que evitan duplicados, una regla de 90 días y un proceso de divulgación que se negocia entre researchers, vendors y programa. La charla completa muestra ese ciclo con las métricas reales de la única CNA de Colombia y las war stories de un ecosistema que avanza por consenso más que por ley.

Para seguir aprendiendo sobre seguridad ofensiva a partir de casos reales, regístrate en https://www.dragonjarcon.org. Allí podrás acceder a charlas como la que acabas de leer y conocer más sobre DragonJARCON, el congreso anual que reúne en Colombia a profesionales e investigadores de la seguridad informática.

Y si tu organización necesita este mismo nivel de análisis y escrutinio, conoce los servicios de seguridad ofensiva de DragonJAR en https://www.dragonjar.org/servicios-de-seguridad-informatica.

Mira la Charla Completa Sobre las CNAs y los CVEs