Se te está acabando el plazo del SLA para una vulnerabilidad crítica en una dependencia, pero no tienes margen en el sprint actual para realizar las pruebas manuales necesarias que garanticen que no se vea afectada la producción. El mero hecho de incumplir el plazo de corrección ya constituirá un hallazgo en tu próximo informe SOC 2 o ISO 27001, pero el riesgo de que se aproveche la vulnerabilidad también está aumentando a medida que avanzan los modelos de IA. Te quedas con dos malas opciones: ralentizar el desarrollo del producto para corregir esta vulnerabilidad o explicar a tu equipo de seguridad y al resto de partes interesadas por qué has incumplido un SLA importante.
Si la situación anterior te resulta familiar, no eres el único. Las organizaciones se están quedando cada vez más atrás en la carrera por subsanar las vulnerabilidades conocidas y cumplir sus acuerdos de nivel de servicio (SLA) en materia de seguridad. Un estudio de Verizon, publicado en 2026, revela que el aprovechamiento de vulnerabilidades es la causa número uno de las brechas de seguridad confirmadas, superando por primera vez al robo de credenciales en los casi 20 años de historia del informe.
La corrección de vulnerabilidades sigue perdiendo terreno debido al aumento vertiginoso de las vulnerabilidades identificadas. Según el mismo informe de Verizon: solo el 26 % de las vulnerabilidades conocidas y explotadas (KEV) se corrigieron por completo en 2025, frente al 38 % del año anterior, mientras que el tiempo medio de corrección aumentó a 43 días, frente a los 32 del año anterior. El informe de Verizon atribuye esta situación a que las organizaciones tienen un 50 % más de vulnerabilidades críticas que corregir.
¿Por qué sigue pasando esto?
No es descabellado esperar que, a medida que aumenta la importancia de las vulnerabilidades, se destinen más recursos a resolver el problema y las soluciones se mantengan al día. Sin embargo, si trabajas en este ámbito, sabes que no ha sido así. Hay dos razones principales por las que este problema está empeorando en lugar de mejorar:
- Una gran parte de las dependencias están, en esencia, sin mantenimiento, pero están tan arraigadas en los sistemas de producción que no es posible eliminarlas sin más ni migrarlas fácilmente a una versión principal más reciente. Piensa en
log4j. - Las políticas de SLA y los programas de cumplimiento normativo no tienen en cuenta si hay un responsable de mantenimiento activo.
Lo que hacen hoy en día los equipos: las fases del duelo según la teoría del aprendizaje de la lengua segunda (SLA)
Cuando se acaba el tiempo, 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 por esperar a que se publique un parche de origen, pero no hay garantía alguna de cuándo, o si alguna vez, el responsable del mantenimiento corregirá la vulnerabilidad. Algunos responsables la corrigen en cuestión de días o incluso antes, mientras que otros no lo hacen. Este problema se agrava en el caso de los paquetes muy utilizados, pero que en la práctica no reciben mantenimiento y carecen de un responsable claro. Esperar solo agota el plazo de tu SLA, sin que se solucione la vulnerabilidad.
Ira: Elimina y sustituye la dependencia problemática. Parece una solución de verdad, y probablemente lo sea por hoy. Pero cuando la nueva versión del paquete reciba un CVE el mes que viene y otro al mes siguiente, te verás atrapado en un ciclo de sustituciones que le costará a tu equipo tiempo real a la hora de desarrollar el producto. Rara vez es la acción de sustituir la versión del paquete en sí lo que realmente te cuesta, sino todo el trabajo adicional para cumplir con las auditorías de dependencias, verificar la compatibilidad de la API y ejecutar pruebas para asegurarte de que no se interrumpan funciones críticas de la aplicación en producción.
Negociación: A medida que se agota el plazo del SLA, decides solicitar una excepción. Esto te da más tiempo para encontrar una solución, pero no resuelve el problema subyacente. El ticket ya no aparece en tu panel de control por hoy, pero sabes que volverá a aparecer. Peor aún, se detectará como una irregularidad la próxima vez que un auditor o el equipo de seguridad de un cliente revise el registro de correcciones. Probablemente se pueda pasar por alto una sola vez, pero cuando se crea un patrón de excepciones, esto puede ser peor que un único incumplimiento del plazo del SLA.
Depresión: La última opción es adaptar tú mismo el parche de seguridad. Esta opción es una solución viable si puedes dedicar el tiempo necesario a comprender el CVE, aislar la corrección e incorporarla de forma selectiva al código fuente existente. La desventaja es que, a partir de ese momento, serás responsable de este parche y de todos los parches futuros de esta biblioteca. Se trata de un compromiso de recursos que probablemente te aleje de la misión principal de tu equipo.
La solución: Bibliotecas de Aikido
Si lleváramos la metáfora hasta el final, la etapa final sería la aceptación. Rendirse y asumir las consecuencias, o arriesgarse a una ruptura. No lo aceptes. Aikido Libraries rompe este ciclo.
Aikido Libraries proporciona versiones parcheadas de tus dependencias vulnerables. El nombre del paquete y la API pública no sufren cambios. El único cambio es un sufijo que indica el parche y una referencia al registro de Aikido.
Cada parche parte de la corrección realizada por el propio responsable del mantenimiento. Aikido toma el cambio de seguridad del código original y lo aplica a la versión que utilizas. Solo se realizan ajustes cuando el entorno de ejecución anterior lo requiere. Cada uno se prueba automáticamente, luego lo revisa una persona y se envía como un archivo «diff» que puedes leer íntegramente antes de fusionarlo.
La transparencia del parche es importante para generar confianza. No recibes la solución propia de Aikido para la vulnerabilidad, sino la solución del responsable del mantenimiento adaptada a tu versión, con el diff completo, por si quieres revisarla.
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 y adapta las correcciones de seguridad de jsonwebtoken 9.0.0 hacia 8.5.1. El cambio consiste en algunas incorporaciones: nuevos archivos de validación de claves, uno de los cuales incluye una capa de compatibilidad para el entorno de ejecución de Node más antiguo. Actualizar a 9.0.0 ya que esa misma corrección habría supuesto una versión importante que dejara de ser compatible con versiones anteriores de Node y modificara la forma en que verify() gestiona tokens sin firmar.
El catálogo de Aikido Libraries cuenta actualmente con más de 9.000 bibliotecas seguras en JavaScript, Python, Java, .NET, PHP, Go y Ruby. Además, publicamos entre 50 y 100 nuevos parches cada día. Para los repositorios inscritos, enviamos bibliotecas seguras parcheadas en un plazo de 48 horas en el caso de vulnerabilidades explotadas conocidas y en un plazo de 7 días para las CVE de nivel crítico y alto.
Enciéndelo una vez
Aikido Libraries funciona de dos maneras. En el caso de un paquete individual, es una opción del menú AutoFix ya existente: cerrar un CVE sin actualizar, una solicitud de incorporación de cambios (PR) cada vez. En el caso de un repositorio, al activarlo se fijan las dependencias y se envía una solicitud de incorporación de cambios (PR) diaria de AutoFix para los CVE revelados 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 obliga a quedarte con la versión segura. Actualiza cuando quieras para disponer de la API o las funciones más recientes, y seguirás recibiendo las correcciones de CVE que se incluyen en ella. Cerrar el CVE y cambiar la versión dejan de ser la misma decisión.
Cumple siempre con tus SLA
Apunta con Aikido a un repositorio y te mostrará en pocos minutos tu primera solicitud de incorporación de cambios (PR) lista para fusionarse relacionada con un CVE real. Explora el catálogo para ver cuáles de tus dependencias están cubiertas, o protege un repositorio para obtener tu primer parche.
