Más allá de reachability: prioriza lo que más importa

La mayoría de las aplicaciones modernas contienen una cantidad considerable de paquetes, bibliotecas y frameworks de código abierto. De hecho, se estima que al menos el 80 % del código fuente de las aplicaciones modernas proviene del código abierto. Además de depender en gran medida de componentes de uso común para crear aplicaciones, los equipos de desarrollo suelen implementar estas aplicaciones y servicios mediante imágenes base de contenedores proporcionadas por la comunidad. También recurren a recursos de terceros como asistentes de programación con IA para generar código propio, lo que acelera aún más la cadena de suministro de software. 

Este uso cada vez mayor de bibliotecas de código abierto, IA generativa y contenedores plantea nuevos problemas de licencias y seguridad. Solo en 2023 se descubrieron casi 29K vulnerabilidades nuevas (y en 2024 ya se descubrieron más de 28K). Si la historia se repite, más de la mitad de esas vulnerabilidades recién descubiertas tendrán una gravedad alta o crítica. En otras palabras, algunos de los mayores riesgos para tus aplicaciones —y potencialmente para toda tu organización— provienen de componentes que están fuera de tu control.

Los desafíos actuales de la seguridad del código abierto

Encontrar, priorizar y corregir todas las vulnerabilidades de código abierto en tus aplicaciones no es realista. Incluso intentar corregir solo las vulnerabilidades de gravedad alta en tus dependencias de terceros puede ser todo un desafío. Al fin y al cabo, no solo debes abordar las vulnerabilidades recién descubiertas, sino también todo el acumulado de vulnerabilidades en tu base de código. Este acumulado proviene de distintos lugares: quizá las heredaste o quizá están en un proyecto implementado mucho antes de que empezaras a buscar vulnerabilidades de código abierto.

Incluso los proyectos pequeños pueden tener cientos de vulnerabilidades en decenas de dependencias directas (es decir, las que se definen explícitamente en los manifiestos de dependencias). Es probable que tengan aún más dependencias indirectas o «transitivas»: las bibliotecas que necesitan las dependencias directas para funcionar. Si multiplicas todo lo anterior por la cantidad de proyectos de tu organización, la lista se vuelve abrumadoramente larga. 

Las técnicas estáticas de priorización no son suficientes

Muchas empresas se basan en factores de riesgo estáticos, como la gravedad NVD/CVSS, para empezar a clasificar esta larga lista de vulnerabilidades y decidir cuáles corregir primero. Sin embargo, estas instantáneas del riesgo pasan por alto muchos factores importantes para lograr una priorización precisa y eficaz. 

Los factores de riesgo más recientes, como EPSS (sistema de puntuación de predicción de exploits), intentan incorporar más información sobre la vulnerabilidad, pero aun así excluyen detalles clave, como el contexto general de la aplicación o del negocio. Al igual que otros factores de riesgo estáticos, EPSS mantiene un enfoque limitado y aislado en problemas individuales, no en tus aplicaciones. Cada problema que evalúa EPSS corresponde a una CVE específica, en lugar de centrarse en lo que más afecta a toda tu organización. 

Muchas empresas han recurrido a reachability para mejorar sus técnicas estáticas de priorización y comprender mejor qué vulnerabilidades deben corregir primero. La reachability estática analiza la definición de la vulnerabilidad, obtiene información sobre dónde existe en una versión determinada de una biblioteca y luego intenta determinar si hay una ruta de llamadas desde tu código propio hasta la función donde probablemente se encuentra la vulnerabilidad. Después, los equipos pueden combinar distintas señales estáticas, como los datos de reachability y una puntuación CVSS o EPSS alta, para decidir qué correcciones abordar primero.

Aunque la reachability estática puede ayudar con el proceso de priorización, también puede dejar vacíos. Por ejemplo, puede ayudar a identificar rutas de código que llaman a funciones vulnerables, pero no funciona a la inversa: no puede decirte con certeza cuándo algo no es alcanzable. Además, no todas las vulnerabilidades incluyen la información necesaria para el análisis de reachability estática. Sin embargo, existen técnicas para determinar qué funciones son vulnerables en los paquetes de código abierto. Por ejemplo, Snyk aprovecha una solución basada en IA que evalúa los commits de corrección para calcularlo. 

En definitiva, combinar reachability estática con CVSS/EPSS mejora las técnicas de priorización, pero es posible mejorarlas aún más si se incorpora un contexto crucial: la importancia de cada artefacto para el negocio. Por eso, los equipos deben considerar factores contextuales además de reachability estática para priorizar las vulnerabilidades con precisión según el riesgo real para el negocio.

Las organizaciones necesitan un enfoque integral para priorizar los riesgos

Ten en cuenta que la gravedad crítica y la reachability de una vulnerabilidad no equivalen a que sea explotable. 

Veamos un ejemplo: tienes dos vulnerabilidades: una de gravedad crítica y «alcanzable» que se ejecuta en el entorno aislado de desarrollo interno, y otra de gravedad media, sin datos de reachability, que se ejecuta en producción. ¿Cuál deberías corregir primero? ¿Y si la vulnerabilidad de gravedad media en producción tiene un exploit conocido y fácil de usar, y está en un contenedor expuesto a Internet en el perímetro? Aunque la vulnerabilidad de gravedad media parezca una elección obvia, ¡es posible que las señales estáticas por sí solas le den mayor prioridad a la vulnerabilidad del entorno aislado!

Con este ejemplo en mente, vemos que la reachability estática a menudo no ofrece una visión completa. Aunque la reachability estática proporciona información para priorizar vulnerabilidades, no permite a los equipos gestionar el riesgo general. Corregir una gran cantidad de vulnerabilidades de gravedad crítica puede verse bien en el papel, pero el verdadero impacto está en remediar las vulnerabilidades que representan el mayor daño potencial para tu negocio y sus resultados.

Estas son algunas señales adicionales que pueden llenar los vacíos que deja la reachability estática: 

• ¿La vulnerabilidad es aplicable al sistema operativo en el que se ejecuta el servicio?

• ¿La aplicación es crítica para el negocio? ¿Qué función específica cumple y cómo se relaciona con las funciones clave del negocio?

• ¿Está implementada? De ser así, ¿dónde está implementada?, ¿está expuesta al público o es accesible desde Internet?, ¿se cargan los paquetes?

• ¿El servicio en el que se encuentra la vulnerabilidad tiene acceso a datos confidenciales?

Priorización contextual del riesgo con Snyk

Como las empresas no pueden resolver todas las vulnerabilidades de código abierto —ni siquiera todas las de gravedad alta o crítica—, es fundamental priorizar correctamente los problemas de seguridad. En Snyk, no solo ayudamos a las organizaciones a encontrar y corregir vulnerabilidades de software, sino también a priorizar las acciones de remediación según el riesgo real para la empresa. Nuestras soluciones fortalecen los procesos de seguridad de aplicaciones de las organizaciones con lo siguiente: 

• La priorización basada en riesgos permite a las organizaciones comprender con claridad la probabilidad de que ocurra un exploit y el impacto que tendría.

• Reachability del código a la nube, que incluye tanto la reachability estática, que analiza el código y las funciones vulnerables, como la reachability dinámica, que analiza el entorno de implementación y ejecución de la aplicación. Nuestra solución funciona con IA y cuenta con la validación de expertos en seguridad, lo que mejora su precisión y cobertura.

• Contexto de la aplicación proveniente de sistemas de control de código fuente, portales para desarrolladores, CMDB y más. Este contexto detallado permite a las empresas acotar aún más las vulnerabilidades que deben abordar según la titularidad del código, la antigüedad del repositorio y otros factores.

• Flexibilidad para empresas, con la posibilidad de integrar directamente en la solución de Snyk lineamientos propios de seguridad y cumplimiento.

• Una puntuación integral de riesgo que facilita su uso en tus iniciativas de seguridad de aplicaciones. Estas puntuaciones permiten a los usuarios priorizar problemas de SCA en todo el entorno o profundizar para comprender el impacto de factores de riesgo específicos, incluida la reachability estática.

Descubre cómo funciona Snyk AppRisk viendo nuestra demostración a pedido.