Cómo reducir el ruido en la gestión de vulnerabilidades

De dónde viene el ruido de vulnerabilidades

Tome un backlog y ordénelo según el origen de cada hallazgo. Las cifras siguientes son ilustrativas, no un benchmark, pero las categorías son las que encuentran los equipos cuando analizan una muestra de su propio backlog.

Origen del hallazgo	De 1.000 hallazgos (ilustrativo)	Paso que lo elimina
Componentes que no distribuye: entradas de lockfiles y manifiestos, capas de compilación, herramientas de desarrollo y pruebas	300	1. Corrija el inventario
La misma CVE notificada por varias herramientas, o una vez por repositorio	250	2. Cuente cada hallazgo una vez
Coincidencias erróneas: colisiones de nombres CPE, backports de las distribuciones	80	1. Corrija el inventario
Hallazgos reales que no se pueden explotar en su producto	150	4. Añada contexto de explotabilidad
Hallazgos reales que aún no tienen corrección	70	5. Una decisión de política con caducidad
Hallazgos sin responsable	50	5. Asígnelos a un responsable
Lo que queda por clasificar y corregir	100	Priorización

Una distinción facilita el resto de la página. Algunos de estos hallazgos son falsos positivos: el hallazgo es erróneo, porque el componente no está o la versión no está afectada. Otros son ruido: el hallazgo es correcto, pero no cambia lo que usted hace esta semana. Requieren soluciones distintas, y confundirlos es lo que lleva a los equipos a suprimir hallazgos reales o a discutir sobre hallazgos erróneos.

Falso positivo: el hallazgo es erróneo	Ruido: correcto, pero no urgente
El componente no está en lo que usted distribuye	El código vulnerable no se puede alcanzar ni activar en su producto
La coincidencia es errónea: una colisión de CPE, o una corrección con backport que el número de versión oculta	Aún no existe corrección, o el producto es interno y no está expuesto
Se resuelve corrigiendo el inventario y el cotejo	Se resuelve con contexto, una decisión registrada y un responsable

Paso 1. Haga que el inventario coincida con lo que distribuye

Es la palanca individual más importante, porque cada paso posterior multiplica los errores del inventario. Un componente que figura en la lista pero nunca se distribuye genera un hallazgo en cada escáner, cada repositorio y cada versión.

• Registre a partir del build. Elabore el inventario a partir de lo que usó realmente el build de la versión, no de los manifiestos ni de un escaneo del artefacto terminado. Una SBOM generada durante el build contiene lo que descargó el job, incluido lo que no figura en ningún lockfile.
• Identifique los componentes con PURL. Un package URL como pkg:npm/[email protected] nombra con exactitud el ecosistema, el paquete y la versión. Cotejar con avisos indexados por PURL, como los avisos de ecosistema de OSV, elimina las coincidencias erróneas que surgen al deducir un CPE a partir del nombre de un producto.
• Use un cotejo que tenga en cuenta la distribución para los paquetes del sistema operativo. Debian y otras distribuciones aplican backports de correcciones de seguridad a la versión que distribuyeron en lugar de actualizarla, así que el número de versión puede parecer anterior a la corrección original. Coteje con el propio rastreador de seguridad de la distribución, no con los rangos de versiones originales.
• Controle la completitud. Sepa cuándo el inventario no pudo ver algo, en lugar de dar por hecho que está completo. Un componente que falta es peor que uno ruidoso: no genera ningún hallazgo.

Ejemplo práctico. El lockfile de un servicio Node.js incluye [email protected], una biblioteca de coincidencia de patrones glob de la que dependen herramientas de pruebas y de compilación. Un escaneo del lockfile notifica CVE-2024-4067, una denegación de servicio por expresión regular corregida en 4.0.8. El job de la versión instala solo las dependencias de producción, con npm ci --omit=dev, así que micromatch nunca entra en el build que se distribuye. Un registro de ese build no la contiene, y el hallazgo nunca llega al backlog. La CVE es real; para este producto, el hallazgo es un falso positivo.

Paso 2. Cuente cada hallazgo una sola vez

La misma CVE llega de la herramienta de SCA, del escáner de contenedores y de la plataforma de SBOM, y otra vez por cada repositorio que usa la biblioteca. Deduplique con una sola clave: package URL, versión y CVE. Por ejemplo, pkg:npm/[email protected] con CVE-2024-45296 es un solo hallazgo, lo notifiquen las herramientas que lo notifiquen.

• Cuente un hallazgo por artefacto distribuido, no uno por escáner.
• Agregue entre builds y repositorios, para que la CVE de una biblioteca compartida sea una sola decisión aplicada en todas partes, no cuarenta tickets.
• Consolide los escáneres que se solapan. Una regla sencilla: los hallazgos de dependencias vienen de una sola fuente de SCA o SBOM, los de imágenes de un solo escáner de contenedores y los de su propio código de una sola herramienta SAST. Si dos herramientas notifican la misma señal, quédese con la más cercana a lo que se distribuye (SAST vs SCA).

Paso 3. Distribuya menos

Cada dependencia que no distribuye es una fuente de hallazgos que nunca tendrá que gestionar.

• Elimine las dependencias que no se usan. La mayoría de los proyectos arrastran algunos paquetes que ya nada importa.
• Actualice el paquete que arrastra los vulnerables. Express 4.19.2 fija [email protected] y [email protected], que tienen CVE-2024-45590 y CVE-2024-45296. No puede actualizarlos por separado sin overrides. Express 4.20.0, publicado en septiembre de 2024, depende de las versiones corregidas, así que una sola actualización resuelve ambas (dependencias transitivas).
• Use imágenes base mínimas. Las imágenes slim y distroless contienen menos paquetes del sistema operativo, así que se aplican menos avisos. El escaneo de contenedores cubre las palancas propias de las imágenes.
• Fije versiones y actualice de forma deliberada. Los lockfiles y los digests mantienen el inventario estable entre builds.
• Bloquee los builds que contengan una versión con vulnerabilidades conocidas. Un control de política que detiene el build mantiene fuera una biblioteca vulnerable antes de que se convierta en un hallazgo que alguien tenga que clasificar.

example-service
└─ [email protected]          → upgrade to 4.20.0
   ├─ [email protected]    CVE-2024-45590
   └─ [email protected]  CVE-2024-45296

Paso 4. Añada contexto de explotabilidad

Lo que queda tras los pasos 1 a 3 es real. El contexto decide qué parte es urgente.

• VEX. Registre «no afectado» una sola vez, con una justificación, como declaración VEX, y reutilícela en todas las versiones y con todos los clientes. Cuando los clientes le reenvían sus propios análisis de su producto, esos mismos registros les responden: consulte cómo escalar un PSIRT y, para plantillas de respuesta, cómo responder a los clientes tras un ataque a la cadena de suministro.
• La alcanzabilidad, si sus herramientas la ofrecen, muestra si su código puede llamar a la función vulnerable. Ayuda, dentro de unos límites (análisis de alcanzabilidad).
• Señales de explotación. CISA KEV indica que una vulnerabilidad se está explotando en entornos reales; EPSS estima la probabilidad de explotación en los próximos 30 días.
• Exposición. Un producto expuesto a internet va por delante de una herramienta interna en una red privada.

Paso 5. Asigne los hallazgos a un responsable, con una política

• Escriba los umbrales como política. Fije umbrales de gravedad y explotabilidad por producto o repositorio en una política, no como un filtro de panel que aplicó una persona.
• Asigne responsables por repositorio o equipo, para que cada hallazgo tenga a alguien que decida.
• Decida de forma explícita sobre «no hay corrección disponible»: acepte con una fecha de caducidad, mitigue o sustituya el componente. Un hallazgo sin corrección no debería quedarse abierto sin una decisión.

Los desarrolladores ignoran los hallazgos por cuatro motivos: no hay responsable, no hay contexto, no hay plazo o el canal es el equivocado. Los equipos con los que hablamos describen cómo ingeniería desactivó escáneres porque el resultado tenía demasiado ruido para leerlo. Resuelva cada motivo: un responsable por repositorio, el contexto del paso 4 adjunto, una fecha límite según la política y la entrega donde el equipo ya trabaja.

Reducir el ruido frente a ocultar el riesgo

Un backlog más pequeño solo es mejor si se ha reducido por los motivos correctos.

• Suprimir sin un motivo y una caducidad es deuda oculta. Vuelve en una auditoría o en un incidente, cuando ya no queda nadie que recuerde por qué.
• Los umbrales mínimos de gravedad ocultan los hallazgos erróneos en lugar de eliminarlos. «Nada por debajo de CVSS 7» hace desaparecer un falso positivo con CVSS 6 y deja en su sitio uno con CVSS 9.
• Cada decisión de no corregir necesita un registro. Los clientes lo piden, y también normativas como el Cyber Resilience Act de la UE, que espera que los fabricantes gestionen las vulnerabilidades durante todo el periodo de soporte de un producto.

Cómo medirlo

• Hallazgos por versión distribuida, no por escaneo.
• La proporción de hallazgos sobre los que se actúa: corregidos, mitigados o decididos.
• Cerrados como no afectados con un registro VEX, frente a suprimidos sin él.
• El tiempo desde el build hasta el responsable: cuánto espera un hallazgo nuevo hasta que alguien se hace cargo.
• La tasa de duplicados entre herramientas.

Una muestra de 50 hallazgos que puede analizar en una tarde. Elija al azar 50 hallazgos abiertos. Para cada uno, anote si el componente se distribuye en la versión, si otra herramienta u otro repositorio notifica el mismo hallazgo, si la coincidencia es correcta, si es explotable en su producto, si existe una corrección y quién es el responsable. Los recuentos le dicen por qué paso empezar. Repita la misma muestra un trimestre después. No citamos benchmarks del sector para estas cifras, porque ninguna fuente primaria respalda ninguno.

Dónde encaja CRACI

CRACI trabaja en los pasos 1 y 2, en el control del build del paso 3 y en parte de los pasos 4 y 5, para el software que se compila en GitHub Actions.

• El inventario. CRACI sustituye sus runners alojados en GitHub y registra los paquetes que cada job descargó realmente, con un PURL por componente y un estado de completitud por SBOM. Cada componente de una SBOM de CRACI estaba en el build. Esa precisión se refiere a los componentes de la SBOM; una CVE que coincide puede aun así no afectar a su producto. Para eso existe VEX, y CRACI es compatible con VEX.
• Un hallazgo, muchos builds. Los hallazgos se agregan entre builds y repositorios, y las SBOM monitorizadas se reevalúan de forma continua a medida que se publican nuevas vulnerabilidades.
• Controles. Los controles de política pueden detener un build en tiempo real según los hallazgos, 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.
• Notificaciones. CRACI notifica a las personas pertinentes una vulnerabilidad y su gravedad.

CRACI no ofrece análisis de alcanzabilidad, SAST ni paneles de MTTR. Consulte el seguimiento de vulnerabilidades para ver la funcionalidad completa, o vea lo que contienen realmente sus builds.

Cuándo CRACI no es la respuesta

• La mayor parte de su ruido son hallazgos de SAST en su propio código. Eso es un problema de ajuste del SAST.
• Su backlog son sobre todo hallazgos reales y explotables en código distribuido. Eso es un problema de capacidad de corrección, no de ruido.
• Necesita contexto de ejecución de cargas de trabajo en producción. Eso lo resuelve una CNAPP o una herramienta de seguridad en tiempo de ejecución.

Para el plan general, consulte qué automatizar cuando no dejan de crecer las CVE, y las cifras en directo de tendencias de publicación de CVE.

Reducir el ruido de vulnerabilidades: preguntas frecuentes

¿Cómo reduzco el número de alertas de vulnerabilidades?

Elimínelas en el origen, en este orden: haga que el inventario coincida con lo que distribuye, deduplique los hallazgos por package URL, versión y CVE, distribuya menos dependencias, añada contexto de explotabilidad como VEX, KEV y EPSS, y asigne lo que queda a un responsable según una política escrita. Después, priorice.

¿Por qué nuestro escáner notifica miles de vulnerabilidades, y cuáles importan?

Normalmente porque notifica componentes que usted no distribuye, notifica la misma CVE una vez por herramienta y por repositorio, y deduce mal algunas coincidencias. Las que importan están en componentes que su versión contiene realmente, son explotables en su producto y se sabe o es probable que se exploten.

¿Cómo deduplico los hallazgos de varias herramientas de seguridad?

Identifique cada hallazgo por el package URL, la versión y la CVE, y cuente un hallazgo por artefacto distribuido. Agregue entre repositorios para que una biblioteca compartida sea una sola decisión. Después, asigne cada tipo de señal a una sola herramienta, para que dos escáneres dejen de notificar lo mismo.

¿Debemos suprimir las vulnerabilidades que no tienen corrección?

No en silencio. Tome una decisión explícita: acepte el riesgo con un motivo por escrito y una fecha de caducidad, mitíguelo o sustituya el componente. Después, revíselo cuando aparezca una corrección. Una supresión sin motivo ni caducidad es deuda oculta.

¿Una vulnerabilidad que nadie ha corregido en un año sigue siendo ruido?

No necesariamente. La antigüedad no dice nada del riesgo. Si se distribuye y es explotable, necesita una decisión y un responsable. Si no afecta a su producto, regístrelo como declaración VEX para que deje de volver. En cualquier caso, no debería quedarse abierta sin una decisión.

¿Cómo consigo que los desarrolladores dejen de ignorar los hallazgos de seguridad?

Dé a cada hallazgo un responsable, el contexto para actuar, un plazo según una política escrita, y entréguelo donde el equipo ya trabaja. Elimine antes el ruido: los desarrolladores dejan de leer un canal en el que la mayoría de los hallazgos no importan.

¿Cuál es un buen número de vulnerabilidades abiertas?

No hay un benchmark fiable, y el recuento bruto es la medida equivocada. Mida los hallazgos por versión distribuida, la proporción sobre la que se actúa, la proporción cerrada con un motivo registrado y cuánto tiempo siguen abiertas en el software distribuido las vulnerabilidades explotadas conocidas.