No se puede contratar al ritmo al que crece el volumen de consultas, ni hacer el triaje cada vez más deprisa indefinidamente. Un PSIRT escala respondiendo a la mayoría de las preguntas «¿estamos afectados?» con datos que registró cuando se construyó cada versión, y publicando la respuesta antes de que los clientes pregunten. Hoy el paso caro es preguntar a ingeniería qué contiene un producto. Lleve ese paso al momento del build, y la mayoría de las consultas se convierten en búsquedas que soporte puede cerrar.
Este artículo da por hecho que ya tiene un PSIRT; si lo está creando, empiece por qué es un PSIRT y cómo crear uno. A continuación: por qué ha cambiado el volumen, adónde se va el tiempo en el proceso habitual y qué cambiar, por orden.
Por qué ha cambiado el volumen
El aumento es estructural, no un mal trimestre. Hay cuatro factores que presionan a la vez sobre la misma cola.
Más CVE. El CVE Program publicó 39.718 registros CVE en 2024 y 47.801 en 2025. En 2026 la cifra superó el total de todo 2025 mucho antes de que terminara el año; nuestras tendencias de publicación de CVE en directo la siguen día a día. La actualización de 2026 de la previsión de vulnerabilidades de FIRST (15 de junio de 2026) elevó su estimación para el año a unas 66.000 CVE y señaló la causa sin rodeos: la IA puede encontrar muchos más fallos que los analistas humanos, y «la limitación ya no es el descubrimiento; es la capacidad humana de verificar, coordinar y parchear». Un PSIRT es esa capacidad humana.
Los clientes escanean su producto. Los clientes pasan escáneres por sus imágenes, su firmware y sus appliances, y reenvían cada hallazgo como un ticket. La mayoría de esos hallazgos son ruido del escáner sobre componentes que usted no distribuye o versiones que no están afectadas, y ese ruido se convierte en su entrada de trabajo. Reducir el ruido de vulnerabilidades trata el lado del escáner.
La regulación añade plazos. Desde el 11 de septiembre de 2026 se aplican las obligaciones de notificación del Cyber Resilience Act de la UE. Una vulnerabilidad explotada activamente en un producto vendido en la UE exige una alerta temprana en un plazo de 24 horas desde que el fabricante tiene conocimiento de ella.
Menos ayuda de la NVD. El 15 de abril de 2026, el NIST pasó la National Vulnerability Database a un enriquecimiento basado en el riesgo: primero van las CVE del catálogo KEV de CISA, el software que usa la administración federal y el software crítico según la EO 14028, y el resto se marca como «Lowest Priority - not scheduled for immediate enrichment» (prioridad mínima, sin enriquecimiento inmediato previsto). Llegan menos CVE con datos CPE, así que la correspondencia por nombre de producto empeora justo cuando sube el volumen.
| Factor | Qué provoca en la cola del PSIRT |
|---|---|
| Volumen de CVE, descubrimiento con IA | Más CVE de terceros que evaluar por producto, cada mes |
| Escaneos de los clientes | Más consultas por CVE, muchas sobre componentes que usted no distribuye |
| Notificación según el CRA | Un plazo de 24 horas para las vulnerabilidades explotadas activamente |
| Menos enriquecimiento de la NVD | Más trabajo manual para relacionar una CVE con los productos a los que afecta |
Adónde se va el tiempo: el proceso de consultas tal como suele funcionar
Los equipos de seguridad de producto nos describen una y otra vez el mismo proceso. Un PSIRT de dos personas de un fabricante de hardware nos lo contó así: un cliente pregunta al servicio de soporte, soporte envía la pregunta al PSIRT a través del CRM, el caso llega al sistema de seguimiento del PSIRT, el PSIRT investiga los productos por los que más preguntan los clientes, después traslada la pregunta a ingeniería y espera.
Tomemos una consulta a modo de ejemplo. Un cliente reenvía un informe de escáner que enumera 40 CVE contra la versión X del firmware. Soporte abre un caso y adjunta el informe, pero no el build exacto que ejecuta el cliente. El PSIRT comprueba cuáles de las 40 ya ha evaluado, encuentra una docena que no, y pregunta al equipo de ingeniería responsable si esos componentes están en la versión X. Ingeniería tiene que encontrar el código fuente de la versión X, averiguar qué versiones de las dependencias entraron en ella y responder. Las cifras son inventadas; la forma no.
Rara vez es el análisis en sí lo que lleva tiempo. Hay dos costes ocultos:
- La misma CVE se vuelve a investigar por cada cliente que pregunta. Cuando la respuesta vive en un hilo de correo, el siguiente cliente hace empezar la investigación de cero.
- «Primero los productos por los que más se pregunta» deja sin respuesta la larga cola. Los productos antiguos que siguen en uso nunca se comprueban, y a menudo es ahí donde está el riesgo: componentes más antiguos, menos actualizaciones, menos gente que recuerde cómo se construyeron.
Entrada: separe las preguntas de los informes
El informe de vulnerabilidad de un investigador y el «¿estamos afectados?» de un cliente son trabajos distintos y necesitan vías distintas. El FIRST PSIRT Services Framework ya cuenta con una entrada desordenada: un PSIRT debe «esperar recibir vulnerabilidades por diversos canales y de calidad variable» (subfunción 2.1.1.1). Su área de servicio de triaje va más allá: «Cuando las organizaciones reciben un gran volumen de informes de vulnerabilidades, pueden plantearse realizar un triaje inicial para validar los informes antes de crear casos». Tómelo como permiso para no abrir un caso del PSIRT por cada consulta.
Divida las consultas en el servicio de soporte en tres vías:
| El cliente pregunta por | Vía | Quién responde |
|---|---|---|
| Una CVE publicada en un componente de terceros que ya ha evaluado | Respuesta a partir de la declaración VEX o el aviso de seguridad publicado; sin caso del PSIRT | Soporte |
| Una CVE publicada que aún no ha evaluado | Un caso del PSIRT por CVE, no por cliente; vincule a él cada consulta | El PSIRT, y después soporte responde a todos los vinculados |
| Una vulnerabilidad nueva en su propio código | Un informe de vulnerabilidad: el proceso completo de divulgación coordinada de vulnerabilidades | El PSIRT |
Soporte necesita dos cosas para trabajar la primera vía: una lista consultable de CVE evaluadas por producto y versión, y plantillas de respuesta. Cómo responder a los clientes tras un ataque a la cadena de suministro incluye plantillas que puede adaptar.
Recoja en la entrada el producto y la versión exacta que ejecuta el cliente. Sin la versión, cada respuesta es «depende», y el caso vuelve.
Priorice por exposición, no solo por popularidad
«Primero los productos por los que más se pregunta» es una heurística razonable. Necesita un segundo eje. Mantenga la popularidad (base instalada, ingresos, frecuencia con la que pregunta soporte) y añada la exposición: ¿el producto sigue teniendo soporte?, ¿suele estar expuesto a internet en los despliegues típicos?, ¿la CVE está en el catálogo KEV de CISA o tiene un valor alto en EPSS? La guía de priorización de vulnerabilidades trata estas señales en profundidad.
| Exposición baja | Exposición alta | |
|---|---|---|
| Base instalada grande | Responder desde el inventario; publicar VEX para las versiones no afectadas | Investigar primero; aviso de seguridad y corrección en el plazo más corto |
| Base instalada pequeña | Responder desde el inventario cuando se pida; sin trabajo proactivo | No lo omita: responder desde el inventario y después decidir una corrección o un aviso de mitigación |
Lo importante de la matriz es la columna izquierda y la fila inferior. La larga cola recibe una respuesta a partir de datos, no de una investigación para la que nadie tiene tiempo.
Con el CRA, el periodo de soporte que declaró para cada producto determina por qué productos antiguos sigue debiendo respuestas y actualizaciones de seguridad (qué exige el CRA).
El traspaso a ingeniería es el cuello de botella
Esta sección es para el responsable de ingeniería que recibe las escalaciones del PSIRT.
Los plazos del PSIRT son públicos: hay un cliente, un regulador o una fecha de divulgación esperando. Los de ingeniería normalmente no, así que el PSIRT absorbe la diferencia. Un problema crítico que se traspasa un lunes y sigue sin respuesta el martes deja dos días antes de que venza la respuesta pública.
El PSIRT envía a ingeniería dos preguntas distintas, y solo una de ellas debería necesitar a ingeniería:
- «¿Está el componente en el producto?» es una pregunta de datos. Debería responderse a partir de un registro, no con una persona leyendo archivos de build.
- «¿Puede corregirlo antes de la fecha X?» es una pregunta de trabajo. Esa sí corresponde a ingeniería.
El marco de FIRST explica cómo quitar la primera pregunta de la mesa de ingeniería. La función 2.3.5 pide a los PSIRT «establecer canales automatizados para distribuir las notificaciones de vulnerabilidades de terceros identificadas directamente a los equipos de desarrollo de los productos afectados», de modo que los avisos de terceros se procesen dentro del proceso de desarrollo y el PSIRT gestione menos a mano.
Acuerde tres cosas con ingeniería:
- Un responsable por producto. En los grandes fabricantes la corrección está repartida entre los equipos de producto; el modelo distribuido del marco existe porque permite que la misión del PSIRT escale a través de los ingenieros responsables de los productos.
- Objetivos de respuesta por gravedad, por escrito, para la corrección y no para la investigación.
- Qué pasa cuando no se cumple un objetivo. La función 4.2.4 pide «un proceso de aceptación formal del riesgo para cualquier vulnerabilidad no corregida dentro de los plazos de los SLA internos». Alguien con autoridad firma el riesgo; no se queda simplemente abierto.
El ritmo de corrección varía. Un equipo publica un parche de un día para otro, otro necesita una actualización de plataforma de seis meses. El aviso de seguridad tiene que decir cuál es el caso, para que los clientes puedan planificar.
Convierta «¿estamos afectados?» en una búsqueda: una SBOM por cada versión distribuida
Este es el cambio que más trabajo elimina. La función 2.3.1 de FIRST, el inventario de componentes de producto, lo califica de «esencial para identificar rápidamente los productos afectados por vulnerabilidades heredadas». Los niveles de madurez de un PSIRT sitúan un registro de productos con mapeo de dependencias en el nivel intermedio y la monitorización de vulnerabilidades de los componentes de producto en el avanzado.
Un inventario solo elimina trabajo si aguanta el volumen. Cada requisito de la lista tiene su motivo:
- Una SBOM por cada versión distribuida, no por repositorio ni de la rama por defecto. Los clientes ejecutan versiones, no ramas.
- Tomada del build que produjo la versión. Un build posterior, o un escaneo del repositorio actual, describe otro software (SBOM en tiempo de build).
- Con las dependencias transitivas y ocultas. El paquete vulnerable rara vez es uno que haya añadido usted (dependencias transitivas), y los scripts de instalación, las imágenes base y las cachés restauradas incorporan componentes que no figuran en ningún lockfile.
- Una señal de completitud. Un registro parcial tratado como completo produce respuestas «no afectado» seguras de sí mismas y equivocadas.
- Conservada mientras la versión tenga soporte. El registro de una versión de hace tres años es el que necesitará cuando nadie recuerde cómo se construyó.
- SBOM de proveedores para los componentes comprados, de modo que el software de terceros esté en el mismo inventario que el suyo.
- Cotejada de forma continua a medida que se publican CVE nuevas, en lugar de volver a escanear cuando alguien pregunta.
Un ejemplo práctico. Se publica una CVE nueva en una biblioteca de compresión muy utilizada. Sin el inventario, el PSIRT pregunta a todos los equipos de producto, las respuestas llegan a cuentagotas durante días y los productos más antiguos nunca se comprueban. Con él, una sola consulta devuelve los productos y versiones afectados, además del primer y el último build que contenían la versión vulnerable. Esa es la ventana de exposición por la que preguntan después los clientes; ¿estamos afectados por una CVE? muestra cómo establecerla en un caso concreto.
Lo más difícil lo tienen las carteras de sistemas embebidos y Yocto. Los escáneres que leen una imagen de firmware terminada tienen que adivinar qué se compiló en ella, y equipos con los que hablamos han visto fracasar pruebas de concepto de escáneres en productos basados en Yocto. Registrar el build mientras se ejecuta evita tener que adivinar (builds de Yocto en CRACI).
Cuando después un cliente pide la propia SBOM, en un formato concreto, consulte cómo responder a las solicitudes de SBOM de los clientes.
El lado de la salida: avisos de seguridad y VEX que responden antes de que nadie pregunte
La consulta más barata es la que nunca llega.
- Publique «no afectado» como VEX, para que los escáneres de los clientes dejen de señalar la CVE, y publique «afectado» y «corregido» como avisos de seguridad con las versiones exactas.
- Hágalo legible por máquina. La subfunción 5.3.2.3 de FIRST sugiere que los PSIRT «consideren publicar los avisos en un formato legible por máquina, como el Common Security Advisory Framework (CSAF)», para que los clientes puedan procesarlos con sus propias herramientas. La guía de CSAF explica cómo pasar de páginas web y feeds RSS a CSAF.
- Informe a soporte antes de publicar. Función 5.3.4: «Facilitar una notificación anticipada y confidencial y unas preguntas frecuentes sobre los próximos avisos prepara a quienes puedan recibir preguntas sobre ellos en el momento de su publicación». Así soporte puede responder el mismo día.
- Envíe, no se limite a publicar. La subfunción 5.4.1.3 señala que un número bajo de visitas a los avisos «puede llevar su estrategia hacia la notificación proactiva». Los feeds y las notificaciones llegan a clientes que nunca visitan una página de avisos.
El CRA convierte parte de esto en una obligación. El artículo 14, apartado 8, exige al fabricante, tras tener conocimiento de una vulnerabilidad explotada activamente o de un incidente grave, informar a los usuarios afectados «y, cuando proceda, a todos los usuarios», y hacerlo «cuando proceda, en un formato estructurado, legible por máquina y fácilmente tratable de forma automática». El reglamento no nombra ningún formato.
Qué automatizar, por orden
Cada paso elimina un tipo de trabajo; la métrica muestra si lo ha conseguido.
| Paso | Trabajo que elimina | Métrica que muestra que ha funcionado |
|---|---|---|
| 1. Un inventario por versión tomado del build | La pregunta «¿qué contiene?» a ingeniería | Bajan las solicitudes de investigación a ingeniería al mes |
| 2. Cotejo continuo de las CVE nuevas con todas las versiones con soporte | Volver a escanear cuando se pide | Tiempo desde la publicación de la CVE hasta la decisión afectado o no afectado |
| 3. Un caso por CVE, con las consultas vinculadas | Investigaciones duplicadas | Suben las consultas por caso; los casos por CVE se mantienen en uno |
| 4. Envío automático de los hallazgos afectados al equipo responsable (FIRST 2.3.5) | Traspasos manuales | Tiempo desde la decisión hasta que un responsable la confirma |
| 5. Una biblioteca consultable de declaraciones VEX y avisos de seguridad publicados | Intervención del PSIRT en preguntas repetidas | Proporción de consultas cerradas por soporte |
| 6. Publicación legible por máquina (CSAF) | Clientes que piden lo que sus herramientas podrían haber descargado | Bajan las consultas por aviso publicado |
| 7. Asistencia de IA para redactar avisos y respuestas | Tiempo de redacción | Tiempo desde la decisión hasta el aviso publicado |
La IA va al final por un motivo. Redacta bien a partir de datos registrados, y nunca debería ser la fuente de la decisión «afectado».
Hay cosas que no deberían automatizarse: el juicio «no afectado» y la valoración de la gravedad siguen en manos de una persona, con las pruebas adjuntas. La automatización decide lo rápido que esa persona recibe las pruebas.
Métricas que muestran que el PSIRT escala
- La proporción de consultas respondidas sin caso del PSIRT.
- El tiempo desde la publicación de la CVE hasta la decisión afectado o no afectado, por producto.
- Las solicitudes de investigación a ingeniería al mes. Deberían bajar.
- La tasa de corrección en plazo por gravedad; la subfunción 4.4.2.4 del marco la define como el grado en que los equipos de producto cumplen el plazo acordado entre el informe y la corrección.
- La cobertura de VEX y avisos de seguridad de las versiones que todavía tienen soporte.
No citamos referencias del sector para estas métricas. Ninguna fuente primaria de nuestra confianza publica ninguna.
Dónde encaja CRACI
CRACI cubre los pasos 1 y 2, y parte de los pasos 4 y 5, para el software que se construye en GitHub Actions. Sus builds se ejecutan en los runners de CRACI, y CRACI registra lo que cada job descargó realmente mientras se ejecutaba: dependencias directas y transitivas, paquetes instalados por scripts y paquetes restaurados desde cachés de CI. La SBOM de cada job lleva un estado de completitud, de modo que un registro parcial nunca se confunde con uno completo.
CRACI conserva el historial de builds, así que cuando se publica una CVE nueva ve qué builds contenían la dependencia vulnerable, y desde cuándo, hasta donde llegue su retención. Las SBOM monitorizadas se reevalúan de forma continua, los hallazgos se agregan entre builds y repositorios, y se pueden añadir SBOM de proveedores para que los componentes comprados se monitoricen junto con sus propios builds. CRACI notifica a las personas pertinentes una vulnerabilidad nueva y su gravedad. La vista de inventario muestra qué versiones de software están desplegadas en qué productos, y los equipos de seguridad hacen el triaje de cada hallazgo en CRACI y lo dirigen al equipo responsable de la corrección. CRACI es compatible con VEX. Consulte CRACI para PSIRT y el seguimiento de vulnerabilidades.
Vea cuáles de sus versiones distribuidas contienen una CVE.
Cuándo CRACI no es la respuesta
- Su cuello de botella es la entrada y la gestión de casos, la parte que va del CRM al sistema de seguimiento. CRACI no es una herramienta de gestión de casos ni de publicación de avisos de seguridad; para esa mitad necesita una herramienta de casos (comparativa de herramientas para PSIRT).
- Sus productos no se construyen en GitHub Actions con runners Linux. GitHub Actions es el CI compatible hoy; GitLab CI y Jenkins están en la hoja de ruta, sin fecha.
- Necesita análisis de binarios o de firmware de productos que no ha construido usted. Eso es lo que hacen las herramientas de análisis del producto final (comparativa de herramientas de seguridad para sistemas embebidos).
- Necesita análisis de alcanzabilidad para argumentar «no afectado». CRACI no lo ofrece.
Preguntas frecuentes
¿Cómo se escala un PSIRT sin contratar?
Deje de investigar una y otra vez la misma pregunta. Registre lo que contiene cada versión distribuida cuando se construye, coteje con ello las CVE nuevas de forma continua, decida una vez por CVE y publique la decisión como VEX o como un aviso de seguridad al que soporte pueda remitir. Así el PSIRT se ocupa de los casos realmente abiertos, y a ingeniería se le pide que corrija, no que investigue.
¿Cómo debe gestionar un PSIRT las consultas «¿estamos afectados?» de los clientes?
Trátelas como un flujo de entrada separado de los informes de vulnerabilidades. Soporte responde a partir del material publicado a las preguntas sobre CVE que ya ha evaluado. Una CVE que aún no ha evaluado recibe un caso del PSIRT, con todas las consultas de clientes vinculadas a él. Solo una vulnerabilidad nueva en su propio código pasa por el proceso completo de divulgación.
¿Qué dice el FIRST PSIRT Services Framework sobre el volumen y la automatización?
Cuenta con recibir informes «por diversos canales y de calidad variable», permite hacer un triaje antes de crear casos cuando el volumen es alto, califica un inventario de componentes de producto de «esencial para identificar rápidamente los productos afectados» y pide canales automatizados que envíen las notificaciones de vulnerabilidades de terceros directamente a los equipos de desarrollo de los productos afectados (función 2.3.5).
¿Qué debería automatizar primero un PSIRT?
El inventario por versión tomado del build y, después, el cotejo continuo de las CVE nuevas con todas las versiones con soporte. Esos dos eliminan la mayor parte del trabajo repetido: la pregunta «¿qué contiene?» a ingeniería y el nuevo escaneo cuando se pide. La deduplicación de casos, el envío a los responsables, una biblioteca consultable de VEX y avisos de seguridad y la publicación en CSAF vienen después.
¿Cómo se consigue que ingeniería responda a tiempo a las preguntas del PSIRT?
Haciéndole menos preguntas. Responda a «¿está el componente en el producto?» a partir del registro del build, y envíe a ingeniería solo «¿puede corregirlo antes de esta fecha?». Acuerde un responsable por producto, objetivos de respuesta por gravedad para la corrección y una aceptación formal del riesgo cuando no se cumpla un objetivo.
¿Por qué es importante para un PSIRT una SBOM por versión?
Los clientes ejecutan versiones concretas, a menudo antiguas. Una SBOM de la rama por defecto no dice nada de la versión X de hace dos años. Una SBOM por cada versión distribuida, registrada a partir del build que la produjo y conservada durante el periodo de soporte, es lo que permite a un PSIRT responder por cada versión que sigue en uso, incluida la ventana de exposición.
¿Los clientes quieren VEX o avisos de seguridad?
Ambos, para estados distintos. VEX indica a los escáneres de los clientes qué CVE no afectan a un producto, de modo que los hallazgos desaparecen. Los avisos de seguridad indican a las personas qué está afectado, qué está corregido y qué hacer. Publicar ambos, en formato legible por máquina cuando sea posible, responde a la mayoría de las preguntas antes de que se formulen.
