Cómo afrontar el aumento de CVE cuando su equipo es pequeño

Qué ha cambiado: las cifras de CVE

Las cifras siguientes proceden de los propios registros del CVE Program, que reconstruimos cada día en nuestra página de tendencias de publicación de CVE. Según la instantánea tomada el 12 nov 2026 UTC:

• 47.801 registros se publicaron en 2025, un 20 % más que el año anterior.
• 95.494 registros se han publicado en lo que va de 2026, 303 al día, un +131 % respecto al ritmo diario de 2025.
• 155 al día tienen una gravedad alta o crítica.
• 17 % de todos los registros desde 2020 no tienen puntuación CVSS, ni del asignador ni del enriquecimiento de CISA. La cobertura ha mejorado: en 2026 la proporción es 6 %.
• 505 organizaciones asignaron estos registros, y las 20 mayores suman 75 % de ellos.

• Alta o crítica
• Otras gravedades y sin puntuación

1. 39 2020
2. 54 2021
3. 68 2022
4. 78 2023
5. 109 2024
6. 131 2025
7. 303 2026*

Media diaria de registros publicados cada año; * indica el año en curso hasta la fecha. Fuente: registros cvelistV5 del CVE Program, instantánea del 12 nov 2026 UTC. Filtros por mes, gravedad y asignador: tendencias de publicación de CVE.

No es un mal trimestre. La cifra ha subido cada año desde 2020, y varios cambios estructurales la mantienen al alza:

• Más asignadores, que asignan de forma más amplia. El proyecto del kernel de Linux se convirtió en CVE Numbering Authority en febrero de 2024. Su política documentada es asignar una CVE a cualquier corrección de un fallo que pueda ser una vulnerabilidad en cuanto la corrección llega a un kernel estable, porque cuando se publica una corrección a menudo no está claro si es explotable. Solo la CNA del kernel ha publicado 18.221 registros desde entonces.
• Descubrimiento asistido por IA. En noviembre de 2024, Project Zero y DeepMind, de Google, informaron de que su agente Big Sleep había encontrado un fallo de seguridad de memoria explotable en SQLite antes de que llegara a una versión publicada, que consideran el primer ejemplo público de un agente de IA que lo logra en software de uso generalizado. Herramientas como esta aumentan lo que puede encontrar un solo investigador.
• La NVD ya no puede enriquecerlo todo. El NIST afirma que la National Vulnerability Database acumuló desde principios de 2024 un retraso de CVE sin enriquecer y no pudo reducirlo mientras los envíos seguían creciendo. En abril de 2026 pasó a un modelo basado en el riesgo: primero se enriquecen las CVE del catálogo Known Exploited Vulnerabilities de CISA y las de software federal o crítico, y el resto figura como no programado para enriquecimiento inmediato. Un proceso que depende de los datos de productos afectados de una sola base de datos ahora espera, o se pierde cosas.
• Menos tiempo para responder. Mandiant midió un tiempo medio hasta la explotación de 63 días en 2018 y 2019. Su informe M-Trends 2026 lo estima en menos siete días para 2025: la explotación ya empieza con frecuencia antes de que se publique un parche.
• Plazos regulatorios. Según el Cyber Resilience Act de la UE, los fabricantes notifican una vulnerabilidad explotada activamente con una alerta temprana en un plazo de 24 horas, una notificación en 72 horas y un informe final en los 14 días siguientes a que haya una corrección disponible (qué exige el CRA). El plazo es el mismo para un equipo de tres personas que para uno de trescientas.

Nada de esto significa que el software sea cada vez menos seguro. Significa que la cantidad de cosas que un equipo tiene que revisar crece cada año, mientras que el equipo no.

Qué falla en el proceso de un equipo pequeño

El aumento de cifras no rompe la gestión de vulnerabilidades porque haya más vulnerabilidades que corregir. La rompe porque cada paso manual se repite por cada CVE.

Paso manual	Por qué falla con el volumen actual
Elaborar el inventario a mano	Una hoja de cálculo, o una SBOM hecha antes de una auditoría, queda obsoleta al día siguiente de la próxima versión.
Leer el feed	Con 155 registros de gravedad alta o crítica al día, nadie da abasto.
Preguntar a ingeniería «¿usamos X?»	La misma pregunta para cada CVE, a las mismas personas ocupadas. La pregunta es el cuello de botella.
Un ticket por CVE y por repositorio	La CVE de una biblioteca compartida se convierte en decenas de tickets duplicados que saturan el backlog.
Responder a cada cliente uno por uno	Las consultas crecen con la base de clientes, no con el número de vulnerabilidades.
Documentos en PDF o en una wiki	Las herramientas de los clientes no pueden cotejar un PDF con su inventario, así que cada lector vuelve a preguntar.
Plazos que no se mueven	El tiempo hasta la explotación se reduce mientras un proceso manual se vuelve más lento a medida que crece el volumen.

El inventario. La mayoría de los equipos que mantienen a mano una lista de componentes la actualizan antes de una auditoría o de un cuestionario de un cliente. Entre esas fechas describe un software que ya no se distribuye. Cada pregunta sobre una CVE empieza entonces por reconstruir lo que contenía la versión.

El feed. Leer avisos es el paso con el que empiezan los equipos, y el primero en hundirse. Hay equipos que nos cuentan que todavía lo hacen a mano, entre ellos uno en el que escanear vulnerabilidades significa que unas personas leen foros de CVE. Funciona hasta el día en que deja de funcionar, y nada avisa de ese día.

La pregunta a ingeniería. «¿Usamos esta biblioteca, y qué versión?» interrumpe a un desarrollador por cada CVE que podría aplicarse. Un equipo de seguridad de producto de dos personas nos contó que su trabajo consiste en pulsar botones solo para no quedarse atrás, sin tiempo para mejorar el proceso.

Los tickets. Cuando una biblioteca compartida tiene una CVE y cada repositorio abre su propio ticket, el backlog cuenta la misma decisión muchas veces. Los equipos aprenden a ignorar el backlog, y luego se les escapa el ticket que importaba.

Las respuestas a clientes. Tras una vulnerabilidad muy mediática o un ataque a la cadena de suministro, los clientes preguntan «¿nos afecta?». Responder a cada uno por separado cuesta más tiempo justo el día en que menos hay.

Los documentos. Una declaración en PDF o una página de wiki tiene que leerla una persona en el lado del cliente. Los escáneres de los clientes, y cada vez más los reguladores, esperan SBOM, VEX y avisos en formatos que una máquina pueda cotejar.

Los plazos. Una alerta temprana que vence en 24 horas, o un exploit que aparece antes que el parche, no espera a que se vacíe la cola.

Qué automatizar, en orden

Cada paso quita trabajo al siguiente, así que el orden importa más que la elección de herramientas.

1. Sepa lo que distribuye. Una SBOM de cada build convierte «¿nos afecta?» en una consulta.
2. Coteje de forma continua, con más de una fuente. Las nuevas CVE se comprueban contra cada SBOM almacenada, así que nadie lee el feed.
3. Reduzca el ruido. Los hallazgos de lo que no distribuye, y los duplicados, nunca llegan a una persona.
4. Haga un triaje semiautomático. Los datos se rellenan solos; una persona toma la decisión.
5. Hágalo todo legible por máquina. Cada decisión se toma una vez y la reutilizan todos los lectores.
6. Responda una vez, en público. La consulta que nunca llega no cuesta nada.

1. Genere automáticamente una SBOM para cada build

Qué sustituye: la hoja de cálculo y la pregunta a ingeniería. Una SBOM generada durante el build describe lo que el build usó realmente, y conservar una por cada versión distribuida le permite responder tanto por la versión del año pasado como por main. Los clientes usan versiones antiguas; su inventario tiene que cubrirlas.

Versión mínima: una SBOM generada en CI para cada build de versión, almacenada junto al artefacto de la versión. Mejor: una SBOM registrada a partir del propio build en lugar de deducida después de los lockfiles, para que también contenga los componentes descargados fuera del gestor de paquetes (SBOM durante el build, automatización de SBOM).

Coste: uno o dos días de trabajo en el pipeline para la versión mínima, y después nada por versión. Señal de que funciona: para cualquier versión, puede enumerar sus componentes sin preguntar a nadie.

2. Coteje de forma continua con varias fuentes de vulnerabilidades

Qué sustituye: leer el feed. Cotejar es trabajo de una máquina: cada nueva CVE contra cada SBOM almacenada, no solo contra la SBOM del build que acaba de ejecutarse. Una versión antigua que estaba limpia cuando se distribuyó queda afectada el día en que se publica una CVE para uno de sus componentes.

Una sola fuente no basta. El retraso de enriquecimiento de la NVD hace que los datos de productos afectados puedan llegar tarde o no llegar. Los avisos de los ecosistemas, como la GitHub Advisory Database y OSV, suelen ser más rápidos e indican qué versiones de paquetes están afectadas en los términos del propio ecosistema. La EU Vulnerability Database de ENISA añade el contexto de la UE.

Versión mínima: una tarea programada que vuelve a escanear cada día todas las SBOM almacenadas contra una fuente agregada e informa de las nuevas coincidencias. Señal de que funciona: sabe que una versión está afectada antes de que se lo diga un cliente. Consulte el seguimiento de vulnerabilidades para ver cómo funciona en CRACI.

3. Reduzca el ruido antes de que nadie mire

Qué sustituye: la revisión manual de hallazgos que no importan. La mayor parte del ruido se genera antes: en inventarios que enumeran cosas que usted no distribuye, en varias herramientas que notifican la misma CVE y en dependencias que nadie necesita. Corrija el inventario, cuente cada hallazgo una sola vez por package URL (PURL), versión y CVE, distribuya menos dependencias y, después, añada contexto de explotabilidad de CISA KEV, EPSS y VEX. Cómo reducir el ruido de vulnerabilidades recorre estas palancas una a una. Señal de que funciona: los hallazgos por versión distribuida bajan, y los motivos quedan registrados.

4. Haga un triaje semiautomático

Qué sustituye: a una persona que reúne los datos de cada hallazgo. Reparta el trabajo con precisión:

• Automático: la gravedad, si se sabe que se explota, qué productos y versiones contienen el componente, el equipo responsable, una prioridad propuesta y una fecha límite.
• Humano: la decisión. Corregir, mitigar, aceptar con fecha de caducidad o marcar como no afectado con una justificación.

Lo que no es seguro automatizar: cerrar un hallazgo como no afectado sin un motivo registrado. Eso es supresión, y vuelve en una auditoría o en un incidente. Las reglas de clasificación se tratan en priorización de vulnerabilidades.

Versión mínima: 15 minutos al día sobre una cola ya ordenada y rellenada. Señal de que funciona: cada decisión tiene un motivo registrado, y nada espera a que alguien busque un dato.

5. Hágalo todo legible por máquina

Qué sustituye: PDF, páginas de wiki y correos que tiene que leer una persona. Publique las SBOM en CycloneDX o SPDX (CycloneDX vs SPDX), las decisiones de no afectado como VEX y los avisos en CSAF. Así, los escáneres de los clientes y los reguladores pueden consumirlos sin intervención humana, y cada decisión se toma una vez y la reutilizan todos los que preguntan.

Versión mínima para un equipo pequeño: SBOM y VEX bajo petición, desde una ubicación estable; CSAF cuando los clientes empiecen a pedirlo. Señal de que funciona: las herramientas de los clientes dejan de señalar lo que usted ya respondió.

6. Responda una vez, en público

Qué sustituye: un hilo de correo por cliente. Publique un aviso o una página de estado para cada CVE relevante, con las versiones afectadas y las corregidas, y mantenga una plantilla de respuesta que enlace a ella. La guía para responder «¿nos afecta esta CVE?» explica cómo averiguar la respuesta. Para la respuesta en sí, cómo responder a los clientes tras un ataque a la cadena de suministro incluye plantillas de respuesta. La consulta más barata es la que nunca llega. Señal de que funciona: la mayoría de las consultas se responden con un enlace.

Después, corrija

Las pull requests automáticas de actualización de dependencias mantienen en marcha el trabajo rutinario; agrúpelas por semana o por versión para que la revisión siga siendo manejable. Actualizar un paquete de nivel superior suele eliminar a la vez varias dependencias transitivas vulnerables, y sale más barato que parchear cada una (corrección automatizada de vulnerabilidades). Después, impida que vuelvan a entrar componentes con vulnerabilidades conocidas con controles de política que bloquean el build.

Un plan según el tamaño del equipo

Las horas son estimaciones ilustrativas para planificar, no benchmarks.

	Una persona, a tiempo parcial	Una función de seguridad o PSIRT de 2 a 5 personas	Un equipo más grande
Automatizar primero	Pasos 1 y 2: una SBOM por build y cotejo continuo	Pasos 1 a 3, y después la asignación a responsables del paso 4	Los seis, con controles de política en cada pipeline
Sigue siendo manual	La decisión sobre cada hallazgo de gravedad alta o crítica; respuestas a clientes desde una plantilla	Decisiones, justificaciones VEX, avisos para CVE relevantes	Decisiones, excepciones y el propio proceso
Tiempo semanal, ilustrativo	De 2 a 4 horas	De 4 a 8 horas por persona	Lo marca el volumen de decisiones, no el feed

Si ya tiene un PSIRT, se aplica el mismo orden; el modelo de proceso completo está en el ciclo de vida de la gestión de vulnerabilidades. Para las consultas de clientes que se multiplican con cada CVE, consulte cómo escalar un PSIRT.

Cómo saber si funciona

• El tiempo desde la publicación de una CVE hasta «afectado» o «no afectado», por producto.
• La proporción de consultas de clientes respondidas con material publicado.
• Los hallazgos por versión distribuida, no por escaneo.
• La proporción de decisiones con un motivo registrado.
• Las horas semanales dedicadas a vulnerabilidades, y si bajan.

Mida primero su propia línea de base. No hay benchmarks fiables del sector para estas métricas, y no citamos ninguno.

¿Contratar, comprar o cambiar el proceso?

• Contrate cuando el trabajo consista en corregir vulnerabilidades en su propio código, o en trabajo de seguridad de cara al cliente que requiere criterio.
• Compre herramientas para los pasos que se repiten por cada CVE: los pasos 1, 2, 3 y 5.
• Cambie el proceso en lo relativo a responsables y plazos: quién decide y para cuándo.

Sea honesto con lo último. Una herramienta sin responsable produce un panel que nadie lee.

Dónde encaja CRACI

CRACI automatiza los pasos 1 y 2, y parte de los pasos 3 y 4, para el software que se compila en GitHub Actions. Sustituye sus runners alojados en GitHub y, mientras se ejecuta cada job, registra los paquetes que el job descargó realmente, incluidos los paquetes restaurados desde cachés de CI y las dependencias ocultas que ningún lockfile enumera.

• Una SBOM de cada build. La SBOM de cada job identifica cada componente por su PURL e incluye un estado de completitud, para que sepa cuándo algo no se pudo ver. El historial de builds conserva cada build anterior con su SBOM, de modo que puede ver qué builds contenían una dependencia vulnerable, directa o transitiva.
• Cotejo continuo. Las SBOM monitorizadas se reevalúan de forma continua, y los hallazgos se agregan entre builds y repositorios, de modo que la CVE de una biblioteca compartida aparece como un solo problema, no como cuarenta.
• Notificaciones y controles. CRACI notifica a las personas pertinentes una vulnerabilidad y su gravedad, y los controles de política pueden detener un build en tiempo real, también un build que contenga una CVE concreta.
• Triaje y asignación. Los equipos de seguridad hacen el triaje de los hallazgos en CRACI y dirigen cada uno al equipo responsable de la corrección.
• SBOM legibles por máquina. Las SBOM se exportan en CycloneDX o SPDX, y CRACI es compatible con VEX.

CRACI no publica avisos, no ofrece análisis de alcanzabilidad y no escanea su propio código. Solo cobra por los minutos de build: $0.002 por vCPU-minuto ($0.004 para un runner predeterminado de 2 vCPU), medidos por segundo, sin cuota mensual, sin cargo por SBOM y, por ahora, sin cuota de licencia. Consulte los precios.

Automatice hoy los dos primeros pasos: ejecute sus builds en CRACI. Estamos incorporando personalmente a cada equipo antes de la disponibilidad general.

Cuándo CRACI no es la respuesta

• Su software no se compila en GitHub Actions. GitLab CI y Jenkins están en la hoja de ruta.
• Su exposición es sobre todo de infraestructura: servidores, endpoints y configuración en la nube. Las herramientas de gestión de vulnerabilidades de infraestructura encajan mejor.
• Integra firmware de terceros que no compila usted. Las herramientas de análisis de binarios encajan mejor.
• Su backlog son sobre todo hallazgos reales y explotables en su propio código. Eso es un problema de capacidad de corrección, no de automatización.

Automatización de la gestión de vulnerabilidades: preguntas frecuentes

¿Por qué hay ahora tantas más CVE?

Más organizaciones asignan CVE, y algunas las asignan de forma amplia: el kernel de Linux se convirtió en CVE Numbering Authority en 2024 y asigna una a cualquier corrección de un fallo que pueda ser una vulnerabilidad. Las herramientas asistidas por IA encuentran más fallos por investigador. En 2025 se publicaron 47.801 registros, y 2026 va a un ritmo de 303 al día. La tendencia dura ya años.

¿Cómo puede un equipo pequeño estar al día con las nuevas CVE?

No leyéndolas. Genere una SBOM para cada build, coteje automáticamente las nuevas CVE con cada SBOM almacenada, reduzca el ruido y deje que las personas tomen solo las decisiones sobre lo que queda. Un equipo pequeño está al día eliminando los pasos que se repiten por cada CVE, no trabajando más rápido.

¿Qué deberíamos automatizar primero en la gestión de vulnerabilidades?

El inventario: una SBOM generada en CI para cada build de versión, almacenada con la versión. Todos los pasos posteriores dependen de ella, y convierte «¿nos afecta?» de una pregunta a ingeniería en una consulta. El cotejo continuo con esas SBOM viene en segundo lugar.

¿Necesitamos un equipo de seguridad para gestionar las vulnerabilidades?

No para empezar. Una persona responsable del proceso a tiempo parcial puede llevarlo si el inventario, el cotejo y la reducción del ruido están automatizados. Necesita un responsable con nombre y plazos más que un equipo. Contrate cuando el trabajo pase a ser corregir su propio código o trabajo de seguridad de cara al cliente.

¿Cómo sabemos qué nuevas CVE afectan a nuestro producto?

Conserve una SBOM de cada versión distribuida y vuelva a comprobarlas todas cada vez que se publiquen nuevas CVE, con más de una fuente de vulnerabilidades. Una CVE le afecta cuando coincide con un componente y una versión que usted distribuye realmente. El contexto de explotabilidad y VEX indican después si importa.

¿Qué significa «legible por máquina» para SBOM, VEX y avisos, y por qué importa?

Significa un formato estructurado y estándar que una herramienta puede procesar: CycloneDX o SPDX para las SBOM, VEX para las declaraciones de no afectado, CSAF para los avisos. El escáner de un cliente puede cotejarlos con su inventario sin que nadie los lea, de modo que una decisión que usted toma una vez la reutilizan todos los clientes y herramientas.

¿Qué parte del triaje se puede automatizar con seguridad?

La recopilación de datos: la gravedad, si se está explotando, qué productos y versiones contienen el componente, el responsable, una prioridad propuesta y una fecha límite. La decisión en sí debe quedar en manos de una persona. Nunca cierre automáticamente un hallazgo como no afectado sin un motivo registrado.

¿Cuánto tiempo tenemos para responder a una CVE crítica?

Menos de lo que supone la mayoría de los procesos. El informe M-Trends 2026 de Mandiant estima el tiempo medio hasta la explotación en 2025 en menos siete días, es decir, explotación antes de que exista un parche. Según el Cyber Resilience Act de la UE, una vulnerabilidad explotada activamente requiere una alerta temprana en un plazo de 24 horas. Fije su propio plazo según la gravedad y la explotación, y mídase con él.