El reachability analysis —o análisis de alcanzabilidad— es una técnica de seguridad de software que determina si una aplicación llama realmente al código vulnerable de un componente de terceros. Trabaja sobre la ruta de ejecución, no sobre el inventario: una dependencia puede declararse, instalarse y desplegarse sin que una línea de su código defectuoso se ejecute. El reachability analysis no produce otra puntuación de severidad, sino la respuesta a una sola pregunta: ¿puede ejecutarse este código aquí?
Menos de 1.200 de las cerca de 350.000 vulnerabilidades de código abierto que rastrea la base de datos de Fluid Attacks tienen reglas de alcanzabilidad a nivel de función. Esa proporción mide hasta dónde llega hoy la técnica, y explica por qué el reachability analysis sirve para priorizar, no para silenciar un hallazgo.
Esta página cubre qué es el reachability analysis, en qué se diferencian el enfoque estático y el dinámico, cómo Fluid Attacks reporta tres niveles en vez de un binario alcanzable/no alcanzable, qué dicen CISA y OWASP sobre las rutas de ejecución, y dónde la técnica deja de ser confiable.
¿Qué es el reachability analysis o análisis de alcanzabilidad?
El reachability analysis rastrea las rutas de ejecución de una aplicación para establecer si la función, clase o módulo afectado por una vulnerabilidad conocida se invoca desde el código evaluado. Es la pregunta que el reachability analysis existe para responder. Un paquete suele traer varias vulnerabilidades y la aplicación usa solo algunas de sus funciones. El reachability analysis separa lo que una aplicación contiene de lo que ejercita, la distinción que todo reporte de dependencias aplana.
El alcance puede ir más allá de las dependencias directas. Casi todo el código vulnerable llega por dependencias transitivas: librerías que arrastran otras librerías, que los desarrolladores rara vez eligen y a veces ni pueden nombrar. El reachability analysis sigue esas cadenas y reporta qué eslabón conduce a una función vulnerable.
Lo que no hace es probar explotabilidad. Llegar al código vulnerable es condición necesaria para la explotación, no suficiente: el atacante todavía necesita una entrada que pueda controlar, un despliegue que coincida y ningún control compensatorio. El reachability analysis tampoco reemplaza al análisis de composición de software: es la capa que le da contexto de aplicación a los hallazgos de SCA, y se lee junto a ellos.
Por qué importa el reachability analysis
El escaneo de dependencias produce más hallazgos de los que un equipo puede atender, y la severidad no los ordena bien. El análisis de alcanzabilidad aporta la única variable que cambia la priorización de vulnerabilidades: si ese código se ejecuta o no en esta aplicación.
Los inventarios reportan presencia, no riesgo
Una lista de materiales de software responde "qué hay aquí dentro", no "qué hace esto aquí". La documentación de Fluid Attacks sobre SCA señala que combinar el escaneo de dependencias con pruebas estáticas de seguridad es lo que permite identificar vulnerabilidades alcanzables: casos donde el producto evaluado sí usa el elemento inseguro de la dependencia.
Sin un reachability analysis, cada paquete declarado con un advisory pesa igual que el resto. El reachability analysis convierte ese inventario plano en una cola ordenada de vulnerabilidades alcanzables.
La brecha es grande. Una estimación reportada por Dark Reading sitúa el uso típico en el 10 % a 20 % del código importado: la cifra de un experto, no una constante medida, pero la dirección se sostiene.
La severidad hereda supuestos de aguas arriba
Los sistemas de puntuación hechos para el caso general trasladan su conservadurismo hacia abajo. El análisis de Fluid Attacks sobre severidad halló que las herramientas suelen heredar las puntuaciones base de la NVD o de los advisories del proveedor y mostrarlas sin ajustarlas por alcanzabilidad, explotabilidad ni contexto del cliente, así que esos supuestos pasan sin cuestionarse (argumento completo aquí).
Hay un caso concreto en su base de datos. CVE-2022-23848, una inyección de comandos en un componente Maven de Alluxio, trae una puntuación CVSS original de 9,8, crítica, en la versión 3.1. La puntuación CVSS v4.0 ajustada por Fluid Attacks para la misma entrada es 4,4, media, con un EPSS de 1,21 %. La misma vulnerabilidad, dos colas de remediación muy distintas. El análisis de alcanzabilidad es la corrección local, contra el código que de verdad va a ejecutarse.
CVE-2022-23848 en la base de datos de Fluid Attacks: crítica con CVSS v3.1 (9,8), media con el CVSS v4.0 ajustado (4,4).
Cambia lo que se corrige primero
Priorizar solo sirve si mueve la remediación. El reachability analysis es la variable que lo logra. En el Reporte de ataques 2026 de Fluid Attacks, sobre 1.119.396 vulnerabilidades reportadas en sistemas de clientes durante 2025, los sistemas con CI Gate alcanzaron una remediación del 72,2 % frente al 58 % de los que no lo usaban. El reachability analysis le da a esa compuerta su criterio: una compilación debería romperse por código que se ejecuta, no por una entrada en un lockfile.
Alcanzabilidad, presencia y explotabilidad no son lo mismo
Casi todo reporte de dependencias colapsa en una sola tres afirmaciones que exigen evidencia distinta. El reachability analysis responde una de las tres. Separarlas es lo que hace útil al reachability analysis en vez de convertirlo en otra etiqueta, y lo que evita que su resultado se lea como certificado de buena salud.
Afirmación | Qué sostiene | Evidencia que exige | Qué no puede decirte |
Presencia | Un componente con advisory conocido forma parte de la compilación | Entrada en el manifiesto o el lockfile, versión resuelta, registro en el SBOM | Si algo de su código se importa o se ejecuta |
Alcanzabilidad | El código de la aplicación llama, o conduce, a la función vulnerable | Grafo de llamadas o traza en ejecución, con ruta de archivo y línea de código | Si un atacante puede controlar la entrada que llega hasta ahí |
Explotabilidad | Un atacante puede activar la falla en este despliegue | Ruta alcanzable, entrada controlada por el atacante, runtime y configuración coincidentes, sin mitigación | Cuánto debería importarle a la organización, que es una pregunta de riesgo |
Las tres afirmaciones detrás de un hallazgo de dependencia, y la evidencia que exige cada una.
El CVSS describe la segunda y la tercera columna para un producto genérico, no para el tuyo. El EPSS estima la actividad de explotación real, otra vez para la vulnerabilidad y no para tu despliegue. El reachability analysis es la única de las tres señales que sale de tu código fuente, y por eso merece la misma vista que las otras dos.
La alcanzabilidad y el EPSS miden cosas distintas: una vulnerabilidad puede ser alcanzable, tener EPSS alto, ambas cosas o ninguna.
Leer la columna del medio como si fuera la de la derecha es el mal uso más común del reachability analysis, y el que produce confianza injustificada.
Reachability analysis en Fluid Attacks
Fluid Attacks ejecuta reachability analysis estático dentro de sus escaneos de SCA y reporta el resultado como atributo de priorización en su plataforma de ASPM, nunca como hallazgo propio. La decisión de diseño de su análisis de alcanzabilidad es deliberada: sube la prioridad de lo que puede confirmar y nunca baja la de lo que no puede.
Tres niveles, y ningún "no alcanzable"
Fluid Attacks reporta tres niveles en vez de un veredicto binario, y separa lo que se declaró, lo que se importó y lo que se llamó.
Nivel | Condición en el código | Cobertura | Efecto en el puntaje de prioridad |
Latent | La dependencia vulnerable está declarada en el gestor de paquetes, pero ningún archivo la importa | Todos los CVE y advisories de las fuentes, lenguajes y gestores soportados | Reducción máxima |
Potential | La dependencia está declarada e importada, pero la función afectada no se llama | Igual que Latent | Reducción menor |
Reachable | La dependencia está declarada, importada, y esa función se llama desde el código | Solo los CVE y advisories con regla de alcanzabilidad publicada | Sin reducción |
Los tres niveles que reporta Fluid Attacks, y lo que cada uno le hace a la prioridad de un hallazgo.
La cuarta etiqueta ausente es el punto. No existe el estado "no alcanzable": una ruta que no se encontró es un límite del análisis, no una propiedad de la aplicación. Llamar no alcanzable a un hallazgo convierte un desconocido en una tranquilidad, y los equipos actúan sobre las tranquilidades.
Cómo se ve en la práctica
La técnica solo es accionable si le entrega al desarrollador una ubicación en vez de un veredicto.
En la sección Packages, las dependencias con advisories aparecen como Vulnerable y, con confirmación, llevan la etiqueta "Reachable". Al expandir la fila y seguir la vulnerabilidad relacionada se identifica la ruta del archivo y la línea de código que llama o conduce a la función afectada. El hallazgo aparece también en Vulnerabilities, con origen Inherited y una captura del código en contexto.
En la sección Packages, una dependencia vulnerable cuya llamada se confirmó lleva la etiqueta Reachable (CVE-2020-28500 en lodash).
El hallazgo señala el archivo y la línea de código que llaman a la función afectada: index.js, línea 24.
Esa es la diferencia entre "actualiza lodash" y "la línea 24 de index.js llama a la función afectada". Uno es un tiquete; el otro es un arreglo.
Reglas deterministas en vez de inferencia probabilística
Los investigadores de Fluid Attacks revisan los advisories de terceros y escriben reglas que identifican el uso de cada función afectada en el código del cliente. Se publican por ecosistema y el changelog registra cada tanda: el Release 41, de octubre de 2026, sumó 32 reglas. La documentación comparativa registra el reachability analysis resultante como determinista, frente a los enfoques probabilísticos que infieren la probabilidad de uso.
La contrapartida es explícita. Una regla determinista solo se dispara para una vulnerabilidad que alguien modeló, así que la cobertura crece de a un CVE. Lo que compra es que una etiqueta Reachable significa que se encontró una llamada, no que se estimó.
Dónde se detiene la técnica: cerca del 0,3 % de cobertura
El filtro de la base de datos pública muestra la cobertura real del análisis de alcanzabilidad a nivel de función. En octubre de 2026 devolvió 1.154 soportadas, 344.698 no soportadas y 3.664 imposibles, sobre 349.516 vulnerabilidades rastreadas en 15 ecosistemas: cerca del 0,3 % de cobertura a nivel de función, con Latent y Potential cargando el resto.
Filtro de Reachability en la base de datos de Fluid Attacks, octubre de 2026: 1.154 soportadas, 344.698 no soportadas y 3.664 imposibles, de 349.516.
Un segundo límite se publicó en vez de absorberse en silencio. En el Release 32, Fluid Attacks acotó la detección de CVE en runtime para .NET, Node.js, Bun y Python tras concluir que los campos de manifiesto en que se apoyaba declaran compatibilidad, no lo que se despliega, así que un CVE levantado desde ahí podía no aplicar. Retirar una fuente de detección es la corrección que esta técnica exige: su valor descansa en que sus positivos signifiquen algo.
La práctica que decide el resto
Los resultados del reachability analysis caducan. Una actualización de dependencia o una funcionalidad nueva convierten un hallazgo Potential en Reachable entre dos commits, lo que vuelve engañoso por diseño cualquier análisis de un solo momento.
Fluid Attacks reejecuta el reachability analysis cuando el código cambia y actualiza su base de datos cada cuatro horas. Desde octubre de 2026, la alcanzabilidad es el séptimo criterio de prioridad de la plataforma, junto al CVSSF y las demás entradas de puntuación.
"Figure out the attack surface and make sure the tainted input can never reach what you are trying to protect."
— Rafael Ballestas, analista de seguridad en Fluid Attacks, en Tainted love
▶️ Video: explicamos qué es el análisis de alcanzabilidad, cómo determina si las vulnerabilidades de las dependencias son realmente explotables y qué cambia en la priorización de vulnerabilidades.
Para profundizar: la guía de Fluid Attacks sobre benchmark de herramientas de AppSec explica por qué las comparaciones de SCA deberían normalizar los hallazgos por vulnerabilidades únicas y accionables, no por referencias duplicadas a dependencias.
Cómo se hace el reachability analysis
Dos enfoques producen evidencia para el análisis de alcanzabilidad y fallan en direcciones opuestas. Uno lee el código; el otro lo observa ejecutarse. La mayoría de los programas maduros construye su reachability analysis sobre el primero y confirma de forma selectiva con el segundo.
Análisis estático de alcanzabilidad
El reachability analysis estático examina el código sin ejecutarlo: resuelve importaciones y puntos de llamada para construir un grafo de llamadas que conecta las entradas de la aplicación con funciones de las dependencias. Corre en cada commit y no necesita entorno desplegado, lo que lo sitúa en el SDLC a tiempo para frenar una llamada vulnerable antes de producción.
Sus puntos ciegos son las partes del programa que solo existen en ejecución: reflexión, despacho dinámico, carga de plugins y rutas elegidas por configuración o datos externos. El modelo es una aproximación, y las aproximaciones omiten cosas.
Análisis dinámico de alcanzabilidad
El análisis dinámico instrumenta la aplicación en ejecución y registra qué código de dependencias se carga y se ejecuta bajo condiciones reales. Este reachability analysis resuelve lo que el análisis estático aproxima, recorta falsos positivos y revela anomalías como accesos a archivos o conexiones salientes inesperadas desde una librería.
El costo es la cobertura. Una ejecución solo prueba las rutas ejercitadas; una ruta no ejercitada no devuelve evidencia en ningún sentido. Súmale la sobrecarga de instrumentación, el volumen de datos y la dificultad de forzar cada combinación de entradas, y el análisis dinámico queda como herramienta de verificación más que como una continua.
Combinar análisis estático y dinámico
Dimensión | Estático | Dinámico |
Cuándo corre | En cada commit, antes del despliegue | Sobre una compilación en ejecución e instrumentada |
Evidencia que produce | Grafo de llamadas, ruta de archivo y línea de código | Registros de llamadas ejecutadas en condiciones reales |
Punto ciego principal | Comportamiento solo en ejecución: reflexión, carga dinámica, rutas por configuración | Rutas no ejercitadas durante la ejecución |
Costo principal | La aproximación de un modelo | Sobrecarga de instrumentación y volumen de datos |
Mejor uso | Priorización continua en todo el código | Confirmar o escalar un hallazgo puntual |
Lo que cada enfoque del reachability analysis puede y no puede establecer.
La combinación funciona como secuencia, no como mezcla: el reachability analysis estático arma la cola y las ejecuciones dinámicas resuelven los casos discutidos.
Qué dicen ya los estándares sobre las rutas de ejecución
El reachability analysis no es un concepto de proveedor: la pregunta que responde está escrita en la forma en que agencias y organismos de estándares esperan que se comunique el riesgo de dependencias.
Los Requisitos mínimos para el Vulnerability Exploitability eXchange (VEX) de CISA, de 2023, definen un documento VEX como la vía para que un proveedor declare que un producto no está afectado por una vulnerabilidad de uno de sus componentes. Esa declaración se sostiene en un reachability analysis.
Una de las cinco justificaciones permitidas para ese estado es Vulnerable_code_not_in_execute_path, definida como el caso en que "the vulnerable code (likely in [subcomponent_id]) cannot be executed due to the way it is used by [product_id]". Eso es reachability analysis escrito como obligación de divulgación, y por eso sus resultados pertenecen a la comunicación con el proveedor y no solo a un tablero.
El complemento es la lista de materiales de software, el inventario que esos documentos anotan. El OWASP Top 10:2025 ubica las fallas de la cadena de suministro como A03 y reporta la tasa de incidencia promedio más alta de cualquier categoría, 5,19 % en sus datos aportados, sobre 215.248 ocurrencias registradas.
OWASP pide rastrear las dependencias directas y las transitivas, y reducir la superficie de ataque eliminando componentes sin uso. El reachability analysis es como una organización averigua cuáles son.
Leídos juntos, los dos estándares describen un flujo: inventariar, decidir con reachability analysis y divulgar con VEX.
Dos casos que muestran para qué sirve el reachability analysis
Los dos casos son fallas de triaje, no de detección, y los dos son el argumento práctico del reachability analysis. En ambos el componente vulnerable se identificó rápido, y la pregunta que responde el reachability analysis —¿esta aplicación ejecuta ese código?— fue la que nadie pudo responder a tiempo.
Log4Shell (CVE-2021-44228). OWASP todavía lista la ejecución remota de código de Apache Log4j entre sus ejemplos de componentes explotables, y 2021 es el caso de referencia del pánico por dependencias: la librería estaba enterrada en artefactos de compilación, casi siempre arrastrada de forma indirecta, y pocas organizaciones pudieron establecer rápido dónde estaba.
El reachability analysis a nivel de función no habría salvado cada instancia —Log4Shell se explotó ampliamente—, pero es exactamente la técnica para la pregunta que esos equipos respondieron a mano durante semanas (Log4Shell explicado).
El compromiso de npm de 2025. En septiembre de 2025, 18 paquetes de npm muy usados, con cerca de 2.600 millones de descargas semanales, se publicaron con versiones maliciosas tras un phishing a una cuenta de mantenedor.
Como reportó Fluid Attacks entonces, no todas las aplicaciones que usaban los paquetes comprometidos resultaron afectadas: la exposición exigía una instalación limpia, o un package-lock.json creado con las versiones maliciosas activas (análisis completo). Presencia y exposición eran, otra vez, preguntas distintas, y el reachability analysis las separa antes de que lo obligue un incidente.
Retos y límites del reachability analysis
La escala es la primera restricción. Construir grafos de llamadas sobre un código grande y políglota consume cómputo y tiempo, y la exactitud se negocia contra la velocidad: un análisis más barato eleva falsos positivos y negativos, lo que anula el propósito del reachability analysis.
El código ofuscado, minificado o propietario dentro de dependencias de terceros resiste el rastreo. También lo resiste lo que el lenguaje resuelve en ejecución, y por eso la cobertura del análisis de alcanzabilidad varía por ecosistema.
El resultado además se degrada: cada actualización de dependencia puede mover una función afectada dentro o fuera de la ruta de llamadas, así que el reachability analysis necesita reejecutarse cuando cambian el código y los advisories.
El límite que más pesa es el que da más tentación ignorar: un resultado negativo no es prueba de seguridad. Significa que este reachability analysis, con sus brechas de cobertura conocidas, no encontró una ruta en este momento.
La detección automatizada sola tampoco cierra la brecha que deja el análisis de alcanzabilidad. En el benchmark de Fluid Attacks sobre 36 herramientas de AppSec de terceros contra 1.201 vulnerabilidades en 105 categorías CWE, el escáner automatizado de mejor desempeño —el propio de Fluid Attacks— detectó el 22,7 % con 99 % de precisión, y un pentester halló el 89,6 % con 100 % de precisión. El reachability analysis ordena el trabajo; no lo termina.
Conclusiones
El reachability analysis responde una pregunta más estrecha de la que finge responder casi toda herramienta de dependencias, y esa estrechez es su valor. Te dice si tu código llama al código afectado: la diferencia entre una entrada de inventario y un defecto que puedes entregarle a un desarrollador con ruta de archivo y línea. Eso es priorización de vulnerabilidades con evidencia adjunta, y es lo que un reachability analysis bien usado entrega.
Como atributo de priorización, el reachability analysis funciona. Como filtro, el análisis de alcanzabilidad convierte en silencio una brecha de cobertura en una afirmación de seguridad. El diseño de reachability analysis que vale la pena copiar es el que solo habla cuando tiene evidencia: tres niveles en lugar de dos, ninguna etiqueta "no alcanzable", reglas deterministas con cobertura publicada y reejecución continua: la respuesta cambia con cada commit.
Preguntas frecuentes
¿Es el reachability analysis lo mismo que el análisis de composición de software?
No. El SCA identifica los componentes de terceros que incluye una aplicación y los cruza contra bases de datos de vulnerabilidades. El análisis de alcanzabilidad es una capa encima: determina si el código de la aplicación llama a la función vulnerable dentro de esos componentes. El SCA te dice qué tienes; el reachability analysis te dice qué usas.
¿Es lo mismo que el análisis de accesibilidad?
Es el mismo concepto con otra traducción. Algunos proveedores y documentaciones localizadas traducen reachability analysis como análisis de accesibilidad; la documentación de Microsoft en portugués usa "SCA baseada em acessibilidade" y "vulnerabilidades alcançáveis" en la misma página. No debe confundirse con la accesibilidad web, que es otra disciplina.
¿Un resultado "no alcanzable" significa que la vulnerabilidad no se puede explotar?
No, y tratarlo así es el modo de falla principal. Un resultado negativo significa que ese reachability analysis no encontró una ruta de ejecución, dentro de su cobertura y en ese momento. La reflexión, la carga dinámica, el comportamiento por configuración y los CVE sin modelar producen falsos negativos. Fluid Attacks evita por eso la etiqueta "no alcanzable" y clasifica los hallazgos como Latent o Potential.
¿El reachability analysis reemplaza al CVSS y al EPSS?
No, los complementa. El CVSS describe la severidad para un despliegue genérico y el EPSS estima la actividad de explotación real; ninguno mira tu código fuente. En la plataforma de Fluid Attacks, la alcanzabilidad pasó a ser el séptimo criterio de prioridad en octubre de 2026, usada junto a esas puntuaciones y no en su lugar.
¿El reachability analysis cubre dependencias transitivas?
Depende del nivel. En Fluid Attacks, la clasificación Latent y Potential cubre todo advisory de sus fuentes soportadas, dependencias transitivas incluidas. La detección Reachable a nivel de función rastrea hoy dependencias directas, y extenderla está en la hoja de ruta publicada. El OWASP Top 10:2025 plantea el argumento de gobierno para rastrear ambas.
¿Fluid Attacks usa reachability analysis y cuánto cubre?
Sí, dentro de sus escaneos de SCA y con cobertura publicada. De las cerca de 350.000 vulnerabilidades de código abierto que rastrea su base de datos en 15 ecosistemas, unas 1.150 tienen reglas de alcanzabilidad a nivel de función. Latent y Potential aplican a todos los advisories soportados, y cada release trae reglas nuevas.
Haz de la alcanzabilidad el desempate, no la etiqueta
Nuestros escáneres y pentesters trabajan desde tu código fuente, así que un hallazgo de dependencia le llega a tu equipo con la línea que lo invoca, no con una severidad prestada del despliegue de otro: esa es la base de nuestra seguridad de la cadena de suministro de software. Prueba gratuita · Contáctanos
Empieza ya con la solución de SSCS de Fluid Attacks
