Te estás quedando sin tiempo en un SLA para una vulnerabilidad crítica de una dependencia, pero no tienes margen en el sprint actual para realizar las pruebas manuales necesarias y asegurarte de no romper producción. No cumplir con el plazo de corrección ya es un hallazgo en tu próximo informe SOC 2 o ISO 27001, pero el riesgo de explotación también crece con el avance de los modelos de IA. Te quedan dos malas opciones: ralentizar el desarrollo de productos para parchear esta vulnerabilidad o explicar a tu equipo de seguridad y a otras partes interesadas por qué has incumplido un SLA importante.
Si el escenario anterior te resulta familiar, no estás solo. Las organizaciones se están quedando aún más atrás en la carrera por cerrar vulnerabilidades conocidas y cumplir con sus SLA de seguridad. Un estudio de Verizon, publicado en 2026, muestra que la explotación de vulnerabilidades es la causa número 1 de brechas confirmadas, superando a las credenciales robadas por primera vez en los casi 20 años de historia del informe.
La corrección sigue perdiendo terreno debido a una explosión de vulnerabilidades identificadas. Del mismo informe de Verizon: solo el 26 % de las vulnerabilidades conocidas explotadas (KEV) se corrigieron por completo en 2025, por debajo del 38 % del año anterior, mientras que el tiempo medio de reparación aumentó a 43 días, frente a los 32 del año anterior. El informe de Verizon atribuye esto a que las organizaciones tienen un 50 % más de vulnerabilidades críticas que parchear.
Por qué sigue pasando esto
No es una locura esperar que, a medida que aumenta la importancia de las vulnerabilidades, se destinen más recursos al problema y las correcciones sigan el ritmo. Pero, si trabajas en este sector, sabes que no ha sido así. Hay dos razones principales por las que este problema empeora en lugar de mejorar:
- Una gran parte de las dependencias prácticamente no recibe mantenimiento, pero están tan arraigadas en los sistemas de producción que resulta imposible eliminarlas por completo o actualizar sin problemas a una versión principal más reciente. Piensa en
log4j. - A las políticas de SLA y a los programas de cumplimiento no les importa si hay un mantenedor activo.
Lo que hacen los equipos hoy en día: las etapas del duelo por los SLA
Cuando el tiempo se agota, la mayoría de los equipos de ingeniería pasan por un ciclo predecible de malas opciones. Se parece mucho al clásico modelo de duelo de Kübler-Ross.
Negación: La mayoría de los equipos empiezan esperando un parche del upstream, pero no hay garantías de cuándo, o si acaso, el mantenedor solucionará la vulnerabilidad. Algunos solucionan los problemas en cuestión de días o menos, mientras que otros no. Este problema se agrava en paquetes muy utilizados pero que carecen de mantenimiento efectivo y no tienen un propietario claro. Esperar solo consume el tiempo de tu SLA sin solucionar la vulnerabilidad.
Ira: Eliminar y reemplazar la dependencia problemática. Parece una solución real, y probablemente lo sea por hoy. Pero cuando la nueva versión del paquete reciba un CVE el próximo mes y otro el mes siguiente, te verás atrapado en un ciclo de reemplazo que le roba a tu equipo tiempo valioso para desarrollar el producto. Rara vez es el acto de reemplazar la versión del paquete lo que realmente cuesta, sino todo el trabajo adyacente para cumplir con las auditorías de dependencias, verificar la compatibilidad de la API y ejecutar pruebas para asegurarse de no romper funciones críticas de la aplicación en producción.
Negociación: A medida que se agota el tiempo del SLA, decides solicitar una excepción. Esto te compra más tiempo para encontrar una solución, pero no resuelve el problema subyacente. El ticket desaparece de tu panel por hoy, pero sabes que volverá a aparecer. Peor aún, resurgirá como un hallazgo la próxima vez que un auditor o el equipo de seguridad de un cliente revise el registro de remediación. Es probable que una sola vez se pueda superar, pero cuando creas un patrón de excepciones, esto puede ser peor que incumplir una fecha límite de SLA.
Depresión: La última opción es aplicar tú mismo el parche de seguridad. Esta opción es una solución real, si puedes dedicar el tiempo necesario para comprender el CVE, aislar la corrección e integrarla (cherry-pick) en el código base existente. La desventaja es que ahora tú eres el responsable de este parche y de todos los parches futuros de esta biblioteca a partir de ahora. Es un compromiso de recursos que probablemente desvíe a tu equipo de su misión principal.
La solución: Aikido Libraries
Si siguiéramos la metáfora hasta el final, la última etapa sería la aceptación. Rendirse y asumir el impacto en el cumplimiento, o arriesgarse a una ruptura. No lo aceptes. Aikido Libraries rompe este ciclo.
Aikido Libraries ofrece versiones parcheadas de tus dependencias vulnerables. El nombre del paquete y la API pública se mantienen intactos. El único cambio es un sufijo que marca el parche y una fijación (pin) al registro de Aikido.
Cada parche parte de la solución propia del mantenedor. Aikido toma el cambio de seguridad del upstream y lo aplica a la versión que ejecutas. Solo se realizan ajustes cuando el runtime anterior lo requiere. Cada uno se prueba de forma automática, luego es revisado por una persona y se publica como un diff que puedes leer por completo antes de fusionarlo.
La transparencia del parche es fundamental para la confianza. No estás recibiendo la solución propietaria de Aikido para la vulnerabilidad, sino la solución del mantenedor adaptada a tu versión, con el diff completo por si deseas inspeccionarlo.
Veamos un ejemplo concreto. La versión de la biblioteca jsonwebtoken 8.5.1 tiene una CVE-2022-23529 calificada como Alta. La versión de Aikido Libraries pasa a ser jsonwebtoken 8.5.1-aikido.5 e integra los parches de seguridad de jsonwebtoken 9.0.0 sobre 8.5.1. El cambio consiste en adiciones: nuevos archivos de validación de claves, uno de los cuales incluye un shim de compatibilidad para el runtime de Node más antiguo. Actualizar a 9.0.0 para obtener la misma solución habría implicado un lanzamiento importante (major release) que eliminaba el soporte para versiones anteriores de Node y modificaba la forma en que verify() gestiona los tokens sin firmar.
El catálogo de Aikido Libraries cuenta actualmente con más de 9.000 librerías seguras para JavaScript, Python, Java, .NET, PHP, Go y Ruby. Además, lanzamos entre 50 y 100 nuevos parches cada día. Para los repositorios inscritos, proporcionamos librerías seguras y parcheadas en un plazo de 48 horas en el caso de vulnerabilidades con explotación conocida, y en un plazo de 7 días para CVEs Críticas y Altas.
Actívalo una vez
Aikido Libraries funciona de dos formas. Para un único paquete, es una opción disponible en el menú de AutoFix existente: soluciona una CVE sin necesidad de actualizar y procesando un PR a la vez. En el caso de un repositorio, la activación fija tus dependencias y genera un PR diario de AutoFix para las CVEs divulgadas después de haberlo activado. Puedes activarlo para un único repositorio importante o para toda tu base de código desde la interfaz de usuario de Aikido.
Nada de esto te ata a la compilación segura. Actualiza siempre que quieras una API o funcionalidades más recientes, y seguirás recibiendo las correcciones de CVE que vienen con ellas. Solucionar la CVE y cambiar de versión dejan de ser la misma decisión.
Cumple con tus SLA en todo momento
Apunta Aikido a un repositorio y te devolverá tu primera PR lista para fusionar contra un CVE real en pocos minutos. Explora el catálogo para ver qué dependencias están cubiertas, o protege un repositorio para obtener tu primer parche.
