Alcanzabilidad en SCA: cuándo importa de verdad una dependencia vulnerable

Ejecuta un escáner de dependencias sobre casi cualquier aplicación real y obtendrás una larga lista de paquetes vulnerables. Muchos están enterrados varios niveles por debajo en el árbol de dependencias, en librerías que tu equipo ni conoce. Se pide a los desarrolladores que lo actualicen todo, las actualizaciones rompen builds y el equipo de seguridad no consigue explicar por qué esta CVE importa más que las demás.

La verdad incómoda es que tener un paquete vulnerable en el árbol de dependencias no equivale a tener una aplicación vulnerable. El análisis de alcanzabilidad (reachability) es la técnica que distingue ambas cosas, y una de las formas más eficaces de convertir el análisis de composición de software (SCA) de un generador de ruido en una herramienta de priorización.

Dependencias directas y transitivas

Una dependencia directa es un paquete que tu proyecto declara explícitamente en su manifiesto. Una dependencia transitiva es la que arrastran tus dependencias, y las dependencias de estas, y así sucesivamente. En la mayoría de los ecosistemas, el árbol transitivo es mucho mayor que la lista que escribiste tú.

Esto importa por dos motivos. Primero, la mayoría de los paquetes vulnerables suelen ser transitivos, así que no se arreglan cambiando una línea: puede que necesites que la librería intermedia publique una actualización o forzar la versión. Segundo, cuanto más lejos está un paquete de tu código, más probable es que solo uses una pequeña parte, o ninguna de la parte vulnerable.

Por qué un paquete vulnerable no siempre es explotable

Una CVE en una librería suele afectar a una función, clase o ruta de código concreta: un parser de un formato de fichero, una opción de configuración, una funcionalidad opcional. Para que sea explotable en tu aplicación, normalmente tienen que darse varias condiciones:

• El paquete vulnerable se carga realmente en ejecución, no solo está presente como dependencia de desarrollo o de test.
• Tu código, directamente o a través de otras librerías, invoca la función vulnerable.
• Los datos controlados por un atacante pueden llegar a esa llamada en las condiciones que el exploit necesita.

Si la función vulnerable nunca se invoca, el riesgo es mucho menor. No es cero, porque el código cambia y el siguiente commit podría empezar a usarla, pero la prioridad es distinta a la de una vulnerabilidad en una ruta de petición expuesta a Internet.

Niveles de alcanzabilidad

La alcanzabilidad no es un simple sí o no. Las herramientas trabajan a distintas profundidades:

• Nivel de paquete: ¿el paquete está instalado y lo usa el código de producción? Esto ya elimina dependencias de test y sin uso.
• Nivel de importación: ¿tu código importa el módulo afectado?
• Nivel de función: ¿un grafo de llamadas construido desde tu código alcanza la función vulnerable concreta, atravesando tu código y las librerías intermedias?

La alcanzabilidad a nivel de función es la más precisa. Requiere saber qué funciones afecta una CVE y construir un grafo de llamadas desde tus puntos de entrada a través del árbol de dependencias. Cuando funciona, permite afirmar con mucha más confianza "esta CVE está en nuestro árbol, pero nada de lo que ejecutamos puede llamar al código afectado".

Límites y advertencias

La alcanzabilidad es potente, pero es análisis estático, y el análisis estático tiene puntos ciegos. Conviene ser honesto con ellos:

• Código dinámico. Lenguajes y frameworks que cargan código por nombre en ejecución, abusan del despacho dinámico o evalúan cadenas como código pueden ocultar rutas de llamada a un grafo estático.
• Reflexión e inyección de dependencias. Las llamadas conectadas mediante configuración, anotaciones o reflexión pueden no aparecer como llamadas directas en el código fuente.
• Metadatos de vulnerabilidad incompletos. El análisis a nivel de función depende de saber qué funciones están afectadas. Cuando el aviso no lo especifica, las herramientas recurren al nivel de paquete o de importación.
• Cambios en el código. "No alcanzable" describe el código de hoy. Debe reevaluarse en cada cambio, no tratarse como una excepción permanente.

La regla práctica: usa la alcanzabilidad para ordenar el trabajo, no para ignorar hallazgos para siempre. Las vulnerabilidades no alcanzables siguen mereciendo una actualización en el calendario normal; las alcanzables merecen atención ya.

Los paquetes maliciosos son otro problema

Los paquetes vulnerables y los paquetes maliciosos suelen meterse en el mismo saco, pero son riesgos muy distintos:

• Un paquete vulnerable es software legítimo con un fallo. El riesgo depende de la alcanzabilidad, la explotabilidad y la exposición.
• Un paquete malicioso se publicó para hacer daño: nombres con typosquatting, cuentas de mantenedores secuestradas o scripts de instalación que roban credenciales o abren puertas traseras. Aquí la alcanzabilidad no importa, porque el código dañino puede ejecutarse al instalar, antes que tu aplicación.

Un paquete malicioso en tu árbol es un incidente, no un elemento del backlog. Exige retirarlo, investigar los sistemas que lo instalaron y rotar los secretos a los que esos sistemas tenían acceso.

Cómo alimenta la alcanzabilidad a la priorización

La alcanzabilidad es una señal entre varias. Funciona mejor combinada con:

• La probabilidad de explotación de EPSS y la explotación conocida de CISA KEV.
• Si la aplicación está expuesta a Internet y cuán crítica es para el negocio.
• Si el mismo componente aparece también en imágenes de contenedor o servidores, para que la corrección sea una sola acción.

Una vulnerabilidad alcanzable y explotada activamente en un servicio expuesto a Internet va arriba del todo. Una no alcanzable, con EPSS bajo, en una herramienta interna puede esperar a la próxima actualización planificada. Es la misma lógica de cómo priorizar vulnerabilidades, aplicada a tu cadena de suministro.

Preguntas frecuentes

¿Puedo marcar las vulnerabilidades no alcanzables como riesgo aceptado? Sí, con una decisión documentada y fecha de caducidad, para revisarlas cuando cambie el código. La supresión silenciosa es lo que genera sorpresas.

¿La alcanzabilidad sustituye al SBOM? No. Un SBOM es el inventario de lo que entregas; la alcanzabilidad analiza cómo se usa ese inventario.

¿La alcanzabilidad es solo cosa del SCA? Se asocia sobre todo a las dependencias, pero la misma idea sostiene el análisis de rutas de ataque en la infraestructura, como en las combinaciones tóxicas.

Cómo ayuda priorIQ.ai

CodeIQ realiza SCA con análisis de alcanzabilidad y detección de paquetes maliciosos, genera SBOM en CycloneDX y SPDX y puede abrir correcciones generadas por IA y verificadas como pull requests. Funciona junto al SAST, el escaneo de secretos, IaC y contenedores, que repasamos en SAST, SCA, secretos e IaC.

Esos resultados alimentan PriorIQ Core, que combina la alcanzabilidad con CVSS, EPSS, KEV, señales de exploit y contexto de negocio, deduplica el mismo componente entre código, contenedores y servidores y lo convierte en acciones de remediación priorizadas, con tickets y trazabilidad. Solicita una demo.