El escáner abre decenas o cientos de alertas. Todos parecen urgentes: severidad alta, paquete conocido y versión afectada. El equipo actualiza dependencias y descubre que algunas solo aparecen en pruebas, otras no llaman a la función vulnerable y una tercera está en una ruta crítica expuesta a internet.
Tratar todo en la misma cola retrasa las correcciones importantes. El análisis de alcanzabilidad añade contexto: construye un grafo de llamadas y busca una ruta desde el código de la aplicación hasta la función vulnerable de una dependencia.
El 28 de octubre de 2026, GitHub anunció reachability analysis para alertas de Dependabot en JavaScript y TypeScript. Utiliza CodeQL y datos curados sobre funciones afectadas para mostrar evidencias de la ruta. No sustituye el aviso ni declara que un paquete sea seguro; ayuda a priorizar.
Por qué no basta con la severidad
CVSS describe características técnicas e impacto potencial. No sabe si la empresa usa el paquete, si llama a la función afectada, si el servicio está expuesto, qué controles existen o qué activo soporta una operación crítica.
Dos sistemas con el mismo CVE pueden tener riesgos distintos. Una biblioteca alcanzable desde un endpoint público de pagos debe subir en la cola. La misma biblioteca instalada por una herramienta de desarrollo y nunca cargada en producción puede seguir un ciclo normal de actualización.
Cómo funciona
- identifica dependencia y funciones asociadas al aviso;
- analiza código, imports, módulos y relaciones de llamada;
- construye un grafo entre aplicación y dependencias;
- busca una ruta hasta la función afectada;
- presenta veredicto y, cuando es posible, ejemplos de la ruta.
El grafo convierte una alerta abstracta en una pregunta concreta: ¿qué entrada de la aplicación puede llegar al código vulnerable?
Interpretar los veredictos
Alcanzable
Existe al menos una ruta. Prioriza la corrección y analiza la evidencia para comprender la exposición.
Potencialmente alcanzable
La herramienta no pudo descartar la ruta. Trátala con prioridad parecida hasta resolver la incertidumbre.
No alcanzable
No se encontró ruta en ese momento. Reduce la prioridad relativa, pero no cierres el aviso solo por ese resultado: el código puede cambiar.
No disponible
El ecosistema, tamaño o un fallo impidieron el análisis. Utiliza los demás indicadores de riesgo.
Ejemplo: API de comercio electrónico
Una API Node.js usa una librería de fechas. Un aviso identifica un fallo en una función de parsing. La dependencia está en producción y la severidad es alta. El análisis encuentra una ruta desde la importación de pedidos hasta la función afectada a través de un módulo interno.
La ruta no demuestra explotación, pero indica que el código puede invocar la función y señala el flujo. El equipo desactiva temporalmente la importación, valida entradas, actualiza el paquete y crea una prueba de regresión específica.
Otro servicio posee la misma versión, pero solo formatea fechas y no alcanza el parsing. El aviso continúa abierto, aunque se procesa en una ventana normal en lugar de interrumpir una entrega crítica.
Alcanzabilidad no significa explotabilidad
Una función alcanzable puede requerir una entrada imposible para el atacante, estar detrás de autenticación o disponer de mitigaciones. A la inversa, el análisis estático puede no ver reflexión, código generado, carga dinámica o relaciones distribuidas.
GitHub recomienda combinar alcanzabilidad con severidad, EPSS, contexto de producción y conocimiento de la aplicación. Es una evidencia, no una sentencia.
Un modelo de prioridad completo
- Alcanzabilidad: ¿existe una ruta hasta la función?
- Exposición: ¿parte de internet, de un usuario interno o de un proceso aislado?
- EPSS: ¿qué probabilidad de explotación estima para los próximos 30 días?
- CISA KEV: ¿hay explotación confirmada?
- Impacto: ¿qué datos, privilegios y operaciones pueden verse afectados?
- Criticidad: ¿el servicio soporta ingresos, seguridad o continuidad?
- Controles: ¿autenticación, WAF o segmentación reducen el riesgo?
EPSS se actualiza a diario y estima probabilidad, pero no conoce tu entorno. KEV confirma explotación observada. La alcanzabilidad aporta contexto del código. La combinación orienta mejor que una puntuación aislada.
Integrarlo en el desarrollo
- mantén lockfiles e inventario de dependencias actualizados;
- asocia repositorio, servicio, entorno y responsable;
- ejecuta análisis periódicos y tras cambios relevantes;
- envía alertas alcanzables al equipo con la evidencia;
- define SLA por riesgo, no solo por severidad;
- registra mitigación, actualización, prueba y validación;
- vuelve a analizar después de corregir.
El artículo sobre lockfiles en CI/CD explica cómo hacer reproducibles las dependencias ejecutadas. La alcanzabilidad responde a cómo la aplicación utiliza la dependencia vulnerable.
Limitaciones
- el soporte de lenguajes y ecosistemas puede ser parcial;
- monorepos grandes pueden superar límites;
- rutas dinámicas generan incertidumbre;
- el veredicto refleja un momento concreto;
- “no alcanzable” no permite posponer indefinidamente;
- una ruta no demuestra éxito de ataque.
En la vista previa de GitHub, el recurso admite JavaScript y TypeScript con npm, Yarn o pnpm y requiere lockfile. Estas condiciones deben figurar en cualquier política empresarial.
Qué hacer cuando no puedes actualizar de inmediato
Una nueva versión puede romper compatibilidad o no estar disponible para un sistema heredado. En ese caso, documenta una mitigación temporal: desactivar la función expuesta, validar entradas, aislar el servicio, reducir privilegios o aplicar una regla de protección. Asigna responsable y fecha de caducidad; una excepción sin vencimiento se convierte en deuda invisible.
La evidencia de la ruta ayuda a diseñar el control compensatorio en el punto correcto. Después de la actualización, elimina la mitigación provisional, ejecuta pruebas de regresión y confirma que el grafo ya no alcanza la función afectada.
Gobernanza en varios repositorios
En una organización, el mismo paquete puede aparecer en decenas de servicios. Centraliza veredictos mediante API, vincula cada repositorio con su propietario y agrupa alertas por activo, no solo por CVE. Los equipos reciben contexto de su aplicación mientras seguridad mantiene una vista común de exposición, excepciones y plazos.
Métricas útiles
Mide tiempo para corregir vulnerabilidades alcanzables, porcentaje de alertas analizadas, edad por criticidad, cobertura de repositorios, reincidencia y excepciones caducadas. El objetivo no es cerrar más avisos, sino reducir el tiempo hasta mitigar rutas capaces de afectar a producción.
Seguridad con contexto
La alcanzabilidad acerca seguridad e ingeniería. La conversación deja de girar solo alrededor del CVE y pasa a la ruta real, el activo, la exposición y la consecuencia.
ProativaIA desarrolla software a medida, aplicaciones y pipelines seguros. Podemos integrar inventario, análisis de dependencias, clasificación contextual y automatización de remediación en tu ciclo de desarrollo.