Sabes que tus aplicaciones no viven en una burbuja. Se construyen a partir de paquetes de código abierto, contenedores, recursos gestionados en la nube, máquinas virtuales (VM), API y mucho más. Cada parte tiene su propia superficie de seguridad y su propio escáner: las herramientas de análisis estático de código (SAST) buscan vulnerabilidades en el código fuente, las herramientas de análisis de composición de software (SCA) buscan dependencias, las herramientas de seguridad en la nube monitorizan 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 en su lugar... estás seguro, ¿verdad?
Más o menos. Definitivamente estás escaneando cada capa.
¿Pero a qué coste?
Por qué los Escáneres de Seguridad te Abruman con Falsos Positivos
Un escáner podría alertarte sobre una función vulnerable en tu código, sin saber que está protegida por una API ascendente. O podría detectar peligro sobre una CVE en una capa base de un contenedor, ignorando el hecho de que tu aplicación real nunca alcanza esa ruta de código. De manera similar, un escáner de la nube podría señalar un rol de IAM que excede sus permisos, sin darse cuenta de que solo está vinculado a una carga de trabajo de staging que no puede acceder a datos de producción.
¿El resultado? Tus equipos se ven inundados con una gran cantidad 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 activos más críticos o al menú virtual del almuerzo?”
Si bien los falsos positivos y los falsos negativos de forma aislada son un riesgo, el riesgo mayor es la falta de cadenas de dependencia que determinen si problemas aparentemente inofensivos se combinan en rutas de explotación reales, o si muchos problemas aparentemente dañinos no son un problema en absoluto.
Y lo escuchamos de los equipos constantemente:
“No controlamos nuestras dependencias.”
¿La razón? Es demasiado desafiante gestionar la cadena de suministro; los paquetes de código abierto traen consigo dependencias indirectas. Incluso con el escaneo de contenedores o las herramientas nativas de la nube, la mayoría de las organizaciones no pueden determinar con confianza qué es lo importante. Como resultado, terminan persiguiendo vulnerabilidades de forma reactiva.
Por qué el Contexto de la Vulnerabilidad Importa en la Seguridad de Aplicaciones y la Seguridad en la Nube
Las herramientas SAST o SCA típicas adoptan una visión muy simplista y literal.
Por ejemplo, cuando ve que un paquete está listado en una CVE, lo marcará como crítico.
Eso suena a buena práctica sobre el papel; es mejor ser reacio al riesgo, después de todo, uno pensaría. Pero en realidad, solo activa falsas alarmas porque:
- A menudo tu aplicación ni siquiera está llamando a la función vulnerable
- La función podría estar enterrada dentro de una dependencia transitiva que nunca tocaste directamente
- O está detrás de una importación que es solo para desarrolladores y que nunca llega a producción.
Así, los equipos obtienen una lista excesivamente exhaustiva de problemas «críticos» y tienen que dedicar horas a investigarlos, solo para darse cuenta de que ni siquiera son críticos.
Al mismo tiempo, las rutas reales que podrían ser explotadas pueden pasar desapercibidas.
Creación de un Grafo 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 separados, a menudo gestionados por productos distintos.
Esto significa que carecen de un grafo de dependencias único que los una a todos. No hay visibilidad de dependencias cruzadas, lo que implica que recibirás notificaciones de problemas no críticos y podrías pasar por alto los problemas que realmente importan.
Pero la visibilidad no se trata solo del contexto; se trata de 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 de librerías inesperadas, lo que requiere configuraciones adicionales para mantener fuera los paquetes transitivos de riesgo.
Sin un grafo unificado, los equipos terminan añadiendo más herramientas solo para tener control sobre lo que han desplegado.
Algunos ingenieros piensan: «si no lo instalamos directamente, no puede hacernos daño»; lo que agrava el problema. Las vulnerabilidades residen en varias capas de profundidad.
¿Entonces qué deberían hacer los equipos?
Utilizar análisis de alcanzabilidad para eliminar falsas alarmas en dependencias
Un verdadero análisis de alcanzabilidad debería significar que, en lugar de solo señalar «tienes un paquete vulnerable en el grafo», tu plataforma puede determinar si tu código está:
- Realmente llamando a la función vulnerable, o
- Involucrado en una vulnerabilidad expuesta a la entrada del usuario, o
- Ejecutándose 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 que se encuentran detrás de dependencias de desarrollo o paquetes de prueba que nunca llegan 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 la creación de software.
La mayoría de los escáneres pueden verificar si un paquete está listado en un CVE. Pero muy pocos pueden rastrear si tu 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 de riesgo, todo en una sola vista.
Correlacionando Vulnerabilidades entre Código, Contenedores y Configuraciones de la Nube
Este es el punto clave. Comprender lo que sucede en todas partes es fundamental para ahorrar a tu equipo una gran cantidad de tiempo y reducir las posibilidades de ser sorprendido.
Esto significa extender este grafo de dependencias más allá del nivel de paquete hacia contenedores, infraestructura como código, configuraciones de la nube, y superponer la alcanzabilidad a través de estos.
Por ejemplo, podría preguntar:
- ¿Afecta esta vulnerabilidad a tus dependencias? Sí
- ¿Es realmente llamada por tu aplicación? No
- ¿Está empaquetado en un contenedor desplegado con entrada pública? No
→ Ignorar - ¿Esta vulnerabilidad requiere que un puerto específico esté abierto? Sí
- ¿La vulnerabilidad está presente en una máquina virtual en la nube? Sí
- ¿Está el puerto requerido abierto en la VM? No
→ Ignorar
Remediación automatizada: Solucionando vulnerabilidades reales más rápido
Una vez confirmada como una vulnerabilidad real y alcanzable, el escenario ideal es determinar la actualización segura mínima y solucionarla automáticamente.
Algunas herramientas pueden:
- Determinar automáticamente la actualización segura mínima
- Comprobar que no romperá tus restricciones semver
- Corregirlo automáticamente sin introducir regresiones
Esto significa que no hay que perseguir dependencias manualmente y muchas menos noches sin dormir.
Gestionar dependencias como parte de una estrategia de seguridad unificada
Al vincular tu código, contenedores y configuraciones de la nube en un solo gráfico, reduces el ruido y ves lo que realmente está expuesto. Sin perseguir falsas alarmas.
Y cuando hay un problema real, no solo se marca, sino que se soluciona. Así, tu equipo dedica menos tiempo a revisar alertas inútiles y más tiempo a entregar.
Descubre cómo Aikido escanea las dependencias de desarrollo en busca de CVEs en nuestra documentación. Consulta nuestra gestión de vulnerabilidades todo en uno, aquí.
