La explotabilidad no es la respuesta. La capacidad de romperse, sí.

La paradoja de AppSec: ¿por qué no corregimos más vulnerabilidades?

¿Por qué los desarrolladores no corrigen todas las vulnerabilidades de AppSec cada vez que las encuentran? ¿La respuesta más común? El tiempo. Las herramientas de seguridad modernas pueden detectar miles de vulnerabilidades en una base de código. Corregirlas todas consumiría toda la capacidad de un equipo de desarrollo y competiría con frecuencia con el desarrollo de funciones y otras prioridades.

Pero el tiempo necesario para corregir vulnerabilidades ha cambiado en los últimos años. Antes, investigar un hallazgo, aprender a corregirlo y cambiar el código manualmente solían ser tareas que tomaban todo el día. Hoy, la automatización y las herramientas con asistencia de IA se encargan de gran parte de ese trabajo y preparan cambios de código para fusionarlos en lo que tardas en preparar una taza de café. En particular, corregir vulnerabilidades de SCA suele consistir simplemente en actualizar paquetes de versiones que se sabe que son vulnerables a otras más recientes que corrigen las CVE.

Entonces, si el tiempo ya no es el cuello de botella, ¿qué lo es? La confianza. Los desarrolladores no ignoran las correcciones porque no quieran resolver los problemas de seguridad. Más a menudo, dudan porque temen que el código deje de funcionar.

Presentamos Breakability, el eslabón que faltaba para priorizar

Para ayudar a los equipos a priorizar con más confianza, presentamos una nueva capacidad para Snyk Open Source: Breakability Risk.

La primera etapa de Breakability se centró en la pregunta que los desarrolladores se hacen todos los días: Si aplico la corrección que recomienda Snyk, ¿romperá mi aplicación? Toda actualización de dependencias conlleva cierto nivel de riesgo. Una actualización «sencilla» de la referencia de un paquete podría introducir cambios en la API que hagan que tu código no compile. O, peor aún, las firmas de los métodos de la API podrían mantenerse, pero introducir cambios sutiles de comportamiento que permitan compilar el código, pero provoquen errores en tiempo de ejecución.

A menudo, dos o más dependencias directas comparten una dependencia transitiva. Cuando varias dependencias directas dependen del mismo paquete subyacente, actualizar una parte del grafo de dependencias para corregir una CVE podría generar un nuevo problema de incompatibilidad con otro conjunto de dependencias. Este es el temido problema del «infierno de dependencias».

Breakability Risk identifica qué actualizaciones son seguras para aplicar ahora y cuáles requieren un análisis más profundo.

La confianza impulsa la seguridad

Hemos realizado experimentos de análisis de breakability y los patrones son consistentes. Cuando los desarrolladores entienden que el riesgo de que sus aplicaciones dejen de funcionar es bajo, es mucho más probable que fusionen una corrección. En nuestros experimentos, las actualizaciones con baja breakability se fusionaron a un ritmo cuatro veces mayor que los cambios de mayor riesgo.

Nuestro análisis muestra que alrededor de un tercio de todas las correcciones se clasifican como de baja breakability. Para el cliente promedio de Snyk, priorizar estas actualizaciones de menor riesgo podría permitir corregir miles de vulnerabilidades adicionales cada año.

Breakability en acción: riesgo bajo frente a riesgo alto

Ahora Snyk incluye una etiqueta de riesgo de fusión directamente en tu pull request para orientarte al priorizar y acelerar las correcciones. Snyk Open Source proporciona detalles, puntuaciones de riesgo contextualizadas y recursos educativos a través de Snyk Learn para ayudar a los desarrolladores a desarrollar sus habilidades.

Escenario 1: «Una victoria fácil».

En este escenario, Snyk Open Source creó un pull request para que un equipo actualice a una versión más reciente de [libxmljs2] y corrija varias vulnerabilidades de denegación de servicio por expresiones regulares (ReDoS).

• Análisis: La actualización elimina principalmente la compatibilidad con las versiones de Node.js que llegaron al fin de su vida útil

• Breakability Risk: Snyk lo marca como Merge Risk: Low, ya que no hay cambios de comportamiento importantes

• Veredicto: Presiona el botón. Protege el código. Sigue adelante.

Escenario 2: «Procede con cautela».

En este caso, una actualización de [i18n] corrige la contaminación de prototipos, pero introduce un cambio arquitectónico: pasa de un singleton global a una configuración basada en instancias.

• Análisis: El patrón de uso fundamental de la biblioteca ha cambiado.

• Breakability Risk: Snyk lo marca como Merge Risk: High debido a los cambios arquitectónicos incompatibles en la biblioteca.

• Veredicto: No lo fusiones hasta que hayas revisado tu propio código y realizado los cambios necesarios.

Una nueva jerarquía de correcciones

Creemos que la primera pregunta de cualquier flujo de trabajo de corrección debería ser sencilla: ¿Puedo resolver este problema con el mínimo esfuerzo y riesgo?

Si la respuesta es sí, aplica la corrección. Breakability permite a los equipos abordar primero las actualizaciones de bajo riesgo, lo que abre la posibilidad de resolver con un solo clic un tercio —o incluso hasta la mitad— de las CVE pendientes. Al eliminar el temor a «romper algo», los equipos pueden reducir con confianza una parte importante de sus pendientes y resolver la deuda de seguridad que ha afectado a los equipos de desarrollo durante años, disminuyendo el riesgo de seguridad sin aumentar la carga de trabajo de ingeniería.

Snyk no está abandonando Reachability ni Risk Score.

Por valioso que sea reachability como criterio para priorizar, hay una gran diferencia entre decir «Es absolutamente seguro que no se puede acceder a esta vulnerabilidad» y «No se ha encontrado una ruta accesible para esta vulnerabilidad». La segunda situación es mucho más común que la primera. No es seguro asumir que «no se encontró una ruta accesible» significa que no existe tal ruta, sobre todo en el mundo actual, donde los atacantes usan herramientas de hacking con IA para encontrar debilidades y explotarlas más rápido que nunca. En lugar de aceptar el riesgo de los paquetes con vulnerabilidades potencialmente inaccesibles, te facilitamos simplemente corregirlas, una vez más, sin riesgo de efectos secundarios negativos.

Breakability y AI Security Fabric de Snyk

Este nuevo paradigma de corrección es clave para impulsar AI Security Fabric. Como se describe en La ruta prescriptiva para poner en práctica la seguridad de la IA, breakability te ayuda a optimizar la reducción del riesgo al generar confianza en las correcciones sugeridas, ir más allá de los criterios de priorización y crear un proceso predecible basado en la confianza, que permite a los equipos fusionar más correcciones en menos tiempo y con menos temor a introducir cambios incompatibles.

Comienza a usar Breakability

La primera etapa de Breakability ya está disponible como función de Snyk Preview para todos los clientes de Snyk Open Source. Actívala para empezar a ver evaluaciones del riesgo de cambios incompatibles en los pull requests que genera Snyk. ¡Nos encantaría que la probaras y nos contaras qué te parece!

¿Quieres replantear cómo priorizar y corregir vulnerabilidades con más confianza? Descubre cómo los insights basados en IA ayudan a los equipos a ir más allá de la detección y avanzar hacia una reducción del riesgo predecible y escalable. Descarga hoy nuestro ebook De Shift Left a Secure at Inception.