Dependencias
Análisis de alcanzabilidad
El análisis de alcanzabilidad comprueba si su código puede invocar realmente la función vulnerable de una dependencia. Un paquete puede contener un fallo que su aplicación nunca toca, y la alcanzabilidad baja esos hallazgos en la lista para que los equipos puedan trabajar en los que se pueden explotar.
Actualizado el
Por qué existe
Un escaneo SCA coteja las versiones de los paquetes con los avisos. Sabe que una versión contiene un fallo, pero no si su aplicación utiliza la parte que lo tiene. Una biblioteca con cientos de funciones y un analizador vulnerable se notifica igual tanto si usted invoca ese analizador como si no, y en un gran árbol de dependencias eso se convierte en una lista de tareas pendientes que nadie puede terminar.
Cómo funciona el análisis de alcanzabilidad
- Localiza el código vulnerable. La herramienta necesita saber en qué función está una vulnerabilidad. Los avisos a menudo no lo dicen, así que los proveedores mantienen sus propios datos.
- Construye un grafo de llamadas. Traza qué funciones invocan a cuáles, desde su código hacia abajo a través de las dependencias.
- Busca una ruta. Si una cadena de llamadas conduce desde su código hasta la función vulnerable, el hallazgo es alcanzable. Si no, se marca como no alcanzable y se le asigna menor prioridad.
Niveles de alcanzabilidad
| Nivel | Pregunta que responde | Contrapartida |
|---|---|---|
| Dependencia | ¿Llega a importarse el paquete? | Barato, y solo elimina dependencias sin usar |
| Función | ¿Puede una ruta de llamadas llegar a la función vulnerable? | El objetivo habitual; necesita un grafo de llamadas y datos de vulnerabilidades por función |
| Tiempo de ejecución | ¿Se cargó o se ejecutó este código en producción? | Evidencia de tráfico real, pero solo de lo que se ejecutó durante la observación |
Un exploit real necesita algo más que una ruta. La entrada tiene que llegar a la función de una forma que active el fallo, y pocas herramientas pueden determinarlo.
Dónde se queda corto el análisis de alcanzabilidad
- No alcanzable no significa seguro. Significa que la herramienta no encontró ninguna ruta. La reflexión, las importaciones dinámicas y la carga de plugins pueden crear rutas que el análisis estático no ve.
- La cobertura de lenguajes varía. Los lenguajes compilados estáticamente son más fáciles de rastrear que los dinámicos, y las herramientas difieren en qué ecosistemas reciben análisis a nivel de función.
- Los datos de vulnerabilidades son incompletos. Si nadie ha asociado un aviso a una función, la herramienta no tiene nada que buscar.
- Cambia con su código. El hallazgo no alcanzable de hoy puede ser alcanzable tras la siguiente versión, así que la respuesta debe volver a comprobarse.
- Solo ordena lo que se ha identificado. Un componente que el escáner nunca encontró no se puede analizar. Sin un inventario completo, la alcanzabilidad ordena solo una parte del panorama.
Cómo usarlo con seguridad
- Úselo para ordenar el trabajo, no para descartarlo. Corrija primero los hallazgos alcanzables y planifique los demás, en lugar de cerrarlos.
- No deje que prevalezca sobre la explotación activa. Un hallazgo en el catálogo KEV de CISA o con una puntuación EPSS alta merece una decisión humana aunque esté marcado como no alcanzable.
- Tenga cuidado con los servicios expuestos a internet. El coste de una respuesta errónea es mayor donde los atacantes pueden llegar a usted directamente.
- Registre el razonamiento. Si decide que un hallazgo no se aplica, una declaración VEX conserva la decisión e indica a sus clientes el motivo.
Para ver cómo encaja la alcanzabilidad con la gravedad, los datos de explotación y el contexto de negocio, consulte cómo priorizar vulnerabilidades.
¿Qué herramientas ofrecen análisis de alcanzabilidad?
Muchas herramientas comerciales de SCA lo ofrecen, entre ellas Snyk, Endor Labs, Mend, Checkmarx, Semgrep y Aikido, y
la profundidad varía según el lenguaje. govulncheck de Go es un ejemplo gratuito para un ecosistema.
Consulte la comparativa de las mejores herramientas de SCA para ver qué cubre cada una.
Dónde encaja CRACI
CRACI no ofrece análisis de alcanzabilidad. Trabaja en el paso anterior: saber qué hay en el build. Es un runner de GitHub Actions que registra cada paquete que descarga cada job, incluidas las dependencias ocultas que se les escapan a los escáneres de lockfiles, y sigue reevaluando las SBOM de lo distribuido a medida que se publican nuevas vulnerabilidades. Si la alcanzabilidad es su máxima prioridad, utilice junto a CRACI una herramienta creada para ello. Consulte dónde encaja CRACI junto a sus herramientas de SCA.
Análisis de alcanzabilidad: preguntas frecuentes
¿Qué es el análisis de alcanzabilidad en SCA?
Comprueba si su código puede invocar realmente la función vulnerable de una dependencia, de modo que los hallazgos sin ruta desde su código puedan recibir menor prioridad.
¿Es preciso el análisis de alcanzabilidad?
Es útil, pero no es una prueba. Un hallazgo alcanzable tiene una ruta real, mientras que uno no alcanzable solo significa que la herramienta no encontró ninguna. La reflexión, la carga dinámica y las lagunas en los datos de vulnerabilidades pueden ocultar una ruta.
¿Se pueden ignorar las vulnerabilidades no alcanzables?
No las ignore sin más. Planifíquelas después de los hallazgos alcanzables, vuelva a comprobarlas tras los cambios de código y preste especial atención a todo lo que se esté explotando activamente o se ejecute en un servicio expuesto a internet.
¿Cuál es la diferencia entre alcanzabilidad y explotabilidad?
La alcanzabilidad pregunta si el código puede llegar a la función vulnerable. La explotabilidad pregunta si un atacante puede usar esa ruta para causar daño. Un fallo puede ser alcanzable y aun así no ser explotable en su configuración.
¿El análisis de alcanzabilidad reduce las alertas?
Sí, ese es su principal propósito. Cuánto las reduce depende del lenguaje, de la herramienta y de qué parte de cada dependencia utiliza su código.
Parta de una visión completa del build
Vea cada paquete que descargó realmente un job de GitHub Actions antes de decidir qué merece la pena corregir.
Reservar una demo