Sabes que tus aplicaciones no viven en una burbuja. Están compuestas por paquetes de código abierto, contenedores, recursos gestionados en la nube, máquinas virtuales, API y mucho más. Cada parte tiene su propia superficie de seguridad y su propio escáner: análisis estático de código (SAST) buscan vulnerabilidades en el código fuente, las herramientasanálisis de composición de software SCA) buscan dependencias, seguridad en la nube supervisan las configuraciones y los escáneres de contenedores buscan exploits conocidos en las imágenes.
Así que, una vez que tienes todos estos escáneres instalados... estás seguro, ¿verdad?
Más o menos. Definitivamente estás escaneando cada capa.
Pero, ¿a qué precio?
¿Por qué los escáneres de seguridad te abruman con falsos positivos?
Un escáner podría alertarle de una función vulnerable en su código, sin saber que está protegida por una API ascendente. O podría detectar un peligro relacionado con un CVE en una capa base de contenedor, sin tener en cuenta el hecho de que su aplicación real nunca llega a esa ruta de código. Del mismo modo, un escáner en la nube podría señalar una función IAM que excede sus permisos, sin darse cuenta de que solo está vinculada a una carga de trabajo de ensayo que no puede acceder a los datos de producción.
¿El resultado? Tus equipos se ven inundados con un montón de hallazgos aislados. Sí, todos son técnicamente precisos, pero vienen con poco contexto para determinar si el problema es realmente peligroso.
O como dijo recientemente un ingeniero de seguridad de una gran empresa:«¿Puedes decirme si una vulnerabilidad afecta a mis joyas de la corona o al menú virtual del almuerzo?».
Si bien los falsos positivos y los falsos negativos por sí solos suponen un riesgo, el mayor riesgo es pasar por alto las cadenas de dependencia que determinan si problemas aparentemente inofensivos se combinan para formar vías de explotación reales, o si muchos problemas aparentemente perjudiciales no suponen ningún problema en absoluto.
Y lo escuchamos constantemente de los equipos:
«No controlamos nuestras dependencias».
¿El motivo? Gestionar la cadena de suministro es demasiado complicado; los paquetes de código abierto traen consigo dependencias indirectas. Incluso con herramientas de análisis de contenedores o nativas de la nube, la mayoría de las organizaciones no pueden determinar con certeza qué es lo importante. Como resultado, acaban persiguiendo las vulnerabilidades de forma reactiva.
Por qué el contexto de vulnerabilidad es importante en la seguridad de las aplicaciones y seguridad en la nube
El típico SAST o SCA tienen una visión muy simplista y literal.
Por ejemplo, cuando detecta que un paquete aparece en una CVE, lo marca como crítico.
En teoría, parece la mejor práctica; después de todo, es mejor evitar riesgos, se podría pensar. Pero en realidad, solo provoca falsas alarmas porque:
- A menudo, tu aplicación ni siquiera llama a la función vulnerable.
- La función podría estar oculta dentro de una dependencia transitiva que nunca has tocado directamente.
- O está detrás de una importación que solo está destinada a los desarrolladores, que nunca llega a la producción.
Así que los equipos reciben una lista excesivamente exhaustiva de problemas «críticos» y tienen que pasar horas investigándolos, solo para darse cuenta de que ni siquiera son críticos.
Al mismo tiempo, las rutas reales que podrían explotarse pueden pasar desapercibidas.
Creación de un gráfico de dependencias completo entre código, contenedores y la nube
La razón por la que muchos escáneres ofrecen resultados ruidosos o incompletos es que carecen del contexto adicional necesario para proporcionar claridad. Las herramientas tradicionales tratan cada capa (código fuente, paquetes de código abierto, contenedores, recursos en la nube) como problemas independientes, que a menudo se gestionan con productos distintos.
Eso significa que carecen de un único gráfico de dependencias que los una a todos. No hay visibilidad de las dependencias cruzadas, lo que significa que se le notificarán los problemas no críticos y es posible que se pierda los problemas que realmente importan.
Pero la visibilidad no solo tiene que ver con el contexto, sino también con la coherencia. Todos los gestores de paquetes gestionan las vulnerabilidades transitivas de forma diferente.
Por ejemplo:
- npm/yarn en JavaScript ofrecen árboles de dependencias y permiten anular/fijar paquetes anidados.
- Maven en Java puede incorporar versiones inesperadas de bibliotecas, lo que requiere configuraciones adicionales para mantener fuera los paquetes transitivos que suponen un riesgo.
Sin un gráfico unificado, los equipos acaban añadiendo más herramientas solo para controlar lo que han enviado.
Algunos ingenieros piensan: «si no lo hemos instalado directamente, no puede hacernos daño», lo que agrava el problema. Las vulnerabilidades se encuentran en varias capas de profundidad.
Entonces, ¿qué deberían hacer los equipos?
Utilice análisis de alcanzabilidad eliminar falsas alarmas en las dependencias.
análisis de alcanzabilidad verdadero análisis de alcanzabilidad significar que, en lugar de limitarse a señalar «tienes un paquete vulnerable en el gráfico», tu plataforma puede determinar si tu código es:
- Llamar realmente a la función vulnerable, o
- Implicado en un fallo expuesto a la entrada del usuario, o
- Ejecutarse en un contenedor accesible desde Internet.
Si la respuesta a todas estas preguntas es no, entonces lo ignora. Si es sí, lo escala.
También es importante filtrar las vulnerabilidades transitivas detrás de las dependencias de los desarrolladores o los paquetes de prueba que nunca se envían a producción. Esto puede reducir mucho el ruido, lo que significa menos falsos positivos y más tiempo para que los desarrolladores se centren en crear software.
La mayoría de los escáneres pueden comprobar si un paquete aparece en una lista CVE. Sin embargo, muy pocos pueden rastrear si su código real llama a la función vulnerable, si está incluido en un contenedor expuesto a Internet y si se ejecuta en un recurso en la nube con IAM arriesgado, todo en una sola vista.
Correlación de vulnerabilidades entre código, contenedores y configuraciones en la nube
Esto es muy importante. Comprender lo que está sucediendo en todas partes es clave para ahorrarle mucho tiempo a su equipo y reducir las posibilidades de verse sorprendido.
Esto significa ampliar este gráfico de dependencia más allá del nivel del paquete a contenedores,infraestructura como código, configuraciones en la nube, y superponer la accesibilidad entre todos ellos.
Por ejemplo, podría preguntar:
- ¿Afecta esta vulnerabilidad a tus dependencias? Sí.
- ¿Lo llama realmente tu aplicación? No.
- ¿Está incluido en un contenedor implementado con ingreso público? No
→ Ignorar - ¿Esta vulnerabilidad requiere que se abra un puerto específico? Sí.
- ¿Existe la vulnerabilidad en una máquina virtual en la nube? Sí.
- ¿Está abierto el puerto requerido en la máquina virtual? No
→ Ignorar
remediación automatizada: Solucionar vulnerabilidades reales más rápidamente
Una vez confirmada como una vulnerabilidad real y accesible, el escenario ideal es determinar la actualización mínima segura y corregirla automáticamente.
Algunas herramientas pueden:
- Calcular automáticamente la actualización mínima segura.
- Comprueba que no rompa tus restricciones semver.
- Arréglalo automáticamente sin introducir regresiones.
Eso significa que no hay que perseguir manualmente las dependencias y se reducen considerablemente las noches de insomnio.
Gestionar las dependencias como parte de una estrategia de seguridad unificada
Al vincular su código, contenedores y configuraciones en la nube en un solo gráfico, se reduce el ruido y se ve lo que realmente está expuesto. No hay que perseguir falsas alarmas.
Y cuando hay un problema real, no solo se señala, sino que se soluciona. Así, tu equipo dedica menos tiempo a investigar alertas inútiles y más tiempo a trabajar.
Descubre cómo Aikido analiza las dependencias de desarrollo en busca de CVE en nuestra documentación. Echa un vistazo a nuestra gestión de vulnerabilidades todo en uno aquí.
Protege tu software ahora.
.avif)
