La corrección de vulnerabilidades es el proceso de solucionar fallos de seguridad, ya sea en el código que ha escrito tu equipo, en los paquetes de código abierto de los que dependes, en los contenedores que distribuyes o en las cuentas en la nube que utilizas. Las vulnerabilidades se han convertido en la vía de acceso más habitual para los atacantes. El Informe de Investigaciones sobre Fugas de Datos de Verizon de 2026 reveló que, por primera vez, el aprovechamiento de vulnerabilidades superó al robo de credenciales como principal vector de acceso inicial, representando el 31 % de las fugas de datos, frente al 20 % del año anterior.
La mayoría de los equipos ya conocen más vulnerabilidades en su código de las que pueden corregir. El mismo informe reveló que solo el 26 % de las vulnerabilidades del catálogo «Known Exploited Vuln» (KEV) de la CISA se habían corregido por completo en 2025, y que el tiempo medio necesario para aplicar un parche se había alargado hasta los 43 días.
Esta guía explica paso a paso el proceso de corrección de vulnerabilidades, cómo priorizar qué corregir primero y cómo solucionar cada tipo de vulnerabilidad, además de qué hacer cuando no es posible actualizar una dependencia. Si buscas herramientas que se encarguen de esta tarea, consulta nuestra recopilación de herramientas para la corrección de vulnerabilidades.
{{cta}}
Dónde se encuentran las vulnerabilidades
Tu propio código
Las vulnerabilidades en el código que ha escrito tu equipo se dividen en dos grupos que requieren dos segmentos distintos de la pila de seguridad. Los fallos basados en patrones son aquellos que SAST detecta de forma determinista en cada commit.
SAST Es un motor determinista basado en reglas que funciona mediante la comparación de patrones. Funciona bien para fallos con una forma reconocible, como «si la entrada del usuario llega a esta función sin pasar por un sanitizador, marcarla como inyección SQL». Los fallos lógicos no tienen esa forma. No existe un patrón para un punto final que deba comprobar si el usuario es propietario de un recurso y no lo es, por lo que detectar estos fallos implica razonar sobre lo que se supone que debe hacer el código. Esa es la labor de la revisión de código mediante IA, que lee el código con esa intención en mente, y de pentesting de IA, que analiza la aplicación en ejecución para comprobar si un fallo puede explotarse realmente.
Ambos tipos de corrección de vulnerabilidades requieren cambios en el código por parte de quien sea el responsable del mismo. Las correcciones basadas en patrones siguen procedimientos bien conocidos, como parametrizar una consulta o codificar la salida. Los fallos lógicos dependen de lo que se suponía que debía hacer el código, por lo que corregirlos requiere el mismo conocimiento de la aplicación que se necesitó para detectarlos. Cuando una herramienta de IA ya ha identificado cómo se puede aprovechar la falta de una comprobación de autorización, puede proponer una corrección basada en ese análisis, y el revisor recibe una explicación junto con el cambio.
Dependencias open source
La mayor parte del código de una aplicación moderna procede de paquetes de código abierto, y la mayoría de ellos son dependencias transitivas incorporadas por los paquetes que has elegido. Por lo tanto, la mayoría de las vulnerabilidades se encuentran en código que nadie de tu equipo ha escrito, ni siquiera ha seleccionado.
análisis de composición de software (SCA) lee tus archivos de bloqueo para construir el árbol completo de dependencias y, a continuación, compara la versión de cada paquete con una fuente de datos sobre vulnerabilidades. Esa fuente es la que determina qué vulnerabilidades detecta. Las herramientas que se basan únicamente en bases de datos públicas de CVE pasan por alto los fallos de código abierto que se corrigen en una versión sin que se les haya asignado nunca un CVE; por eso, algunas herramientas de SCA , incluida Aikido, recurren a fuentes deinteligencia de amenazas como Aikido Intel.
Un hallazgo no te indica si la vulnerabilidad te afecta. Un CVE en una función a la que tu código nunca recurre no es accesible y supone un riesgo real mínimo, mientras que el mismo CVE en una función que utilizas constantemente justifica dejar de lado otras tareas. Una puntuación CVSS no permite diferenciarlos, ya que evalúa la vulnerabilidad de forma abstracta, y no el grado de exposición de tu aplicación.
SCA Las comprobaciones deben seguir ejecutándose tras la fusión. Las versiones de los paquetes que figuran en tu archivo de bloqueo permanecen fijas, mientras que siguen revelándose nuevas vulnerabilidades relacionadas con ellas, por lo que un árbol de dependencias que superó las pruebas el mes pasado puede fallar hoy sin que nadie lo haya modificado. Cuando se detecta una vulnerabilidad, la solución habitual es actualizar a una versión que la corrija, y en la siguiente sección se explica por qué esa actualización suele acabar siendo una tarea más compleja de lo que parece.
Imágenes de contenedor
La mayor parte de las vulnerabilidades de una imagen de contenedor provienen de la imagen base sobre la que se ha creado. Una imagen base típica incluye docenas de bibliotecas y herramientas del sistema, como un shell y un gestor de paquetes, y es escaneo de imágenes de contenedores quien comprueba esos paquetes a nivel del sistema operativo. Además, las imágenes sufren desviaciones que pasan fácilmente desapercibidas. Un contenedor en ejecución conserva los paquetes con los que se creó hasta que alguien lo vuelve a compilar y lo vuelve a implementar, por lo que un contenedor que se ejecuta en producción puede tardar meses en recibir una corrección que ya existe en la versión original.
La corrección de una imagen depende de hasta qué punto estés dispuesto a modificar esa base. Eliminar los paquetes que tu entorno de ejecución nunca utiliza reduce el problema. En cuanto a todo lo que se mantiene, actualizar a una etiqueta base más reciente o migrar a una distribución reforzada de otro proveedor implica probar tu aplicación en una base diferente, mientras que una compilación parcheada de la misma versión base corrige las vulnerabilidades (CVE) y mantiene todo lo demás tal y como está.
Infraestructura como código (IaC)
IaC traslada la configuración de la nube a archivos como las plantillas de Terraform y CloudFormation, los gráficos de Helm y los manifiestos de Kubernetes, de modo que la mayor parte de la configuración de la nube se puede revisar como cualquier otro código. Entre las vulnerabilidades más habituales se incluyen:
- Un depósito de almacenamiento abierto a Internet
- Un grupo de seguridad que acepta tráfico procedente de cualquier lugar
- Un contenedor que se ejecuta como root
- Una instancia de EC2 que sigue utilizando IMDSv1, la versión anterior del servicio de metadatos de AWS en la que se basan los ataques SSRF para robar credenciales
IaC es el lugar más sencillo para corregir una configuración errónea en la nube, ya que aún no se ha aplicado nada. Las comprobaciones de IaC se ejecutan en tu proceso de CI/CD y las señalan en la solicitud de incorporación de cambios; la corrección consiste en una plantilla modificada —a menudo, un cambio de una sola línea— que nunca llega al entorno de producción. El inconveniente es que las comprobaciones de IaC solo detectan lo que está escrito en tus plantillas.
Configuración en la nube
En una organización de ingeniería madura, la mayor parte de la infraestructura en la nube se define mediante «IaC», por lo que muchos de los hallazgos relacionados con la nube son, en realidad, hallazgos de «IaC» que han llegado a implementarse. El resto proviene de cambios que nadie ha documentado. Alguien hace clic en la consola para abrir un puerto o ampliar un rol, y no hay ninguna plantilla ni solicitud de incorporación de cambios que lo registre.
seguridad en la nube La gestión de la postura (CSPM) lee directamente la cuenta en vivo, por lo que detecta esos cambios junto con cualquier otro que se haya pasado por alto en la revisión. La solución consiste en un cambio en la configuración o en una política más estricta, y debe incorporarse de nuevo a IaC. Si el recurso ya está gestionado por una plantilla, cualquier corrección realizada únicamente desde la consola se revertirá con la siguiente implementación. Si se creó manualmente, incorporarlo a IaC significa que el próximo cambio que se le realice pasará por el proceso de revisión.
Algunos de los hallazgos más graves abarcan varias capas, y la vulnerabilidad SSRF de MLflow (CVE-2026-64849) es un buen ejemplo de ello. A las pocas horas de que se le asignara un CVE en agosto de 2026, los atacantes ya la estaban aprovechando para hacer que los servidores de MLflow solicitaran al servicio de metadatos del proveedor de la nube sus propias credenciales. En AWS, IMDSv1 las facilita en respuesta a una simple solicitud. IMDSv2 requiere primero un token de sesión, un paso adicional que la mayoría de los errores de SSRF no pueden realizar, por lo que su aplicación probablemente habría impedido el robo.
Las credenciales que los atacantes consiguieran tendrían, como máximo, el mismo nivel de acceso que el rol de IAM asociado al servidor y, dado que esos roles suelen estar definidos también en Terraform o CloudFormation, las comprobaciones de IaC pueden detectar una política demasiado amplia antes de que se implemente. Ambas medidas de seguridad se encuentran en las mismas plantillas que las comprobaciones de IaC ya leen, lo que convierte a IaC en el lugar más económico para detener un ataque como este.
Secretos
Los secretos suelen acabar en el código por accidente. Una clave de API se codifica de forma estática en una prueba, o una contraseña de base de datos se cuela en un archivo de configuración que se integra junto con el resto. El código escrito por IA tiende a tener este problema en particular. detección de secretos comprueba las nuevas integraciones y todo el historial de Git en busca de estos elementos, y un hook de pre-commit puede bloquearlos antes incluso de que se integren. Las imágenes de contenedores necesitan la misma comprobación, ya que un secreto copiado en una capa permanece en la imagen aunque una capa posterior lo elimine.
Eliminar el secreto del código no soluciona el problema, ya que sigue estando en el historial de Git. La solución consiste en rotar la credencial y, a continuación, revisar los registros de acceso para comprobar si alguien utilizó la antigua antes de la rotación. Si los registros indican que otra persona la utilizó, debes averiguar a qué accedió el atacante y si los datos en cuestión dan lugar a algún requisito de notificación de violación de seguridad. Una vez que la credencial antigua ha dejado de ser válida, eliminarla del historial es una buena práctica de mantenimiento, pero ya no es urgente. Para evitar que vuelva a ocurrir, traslada el secreto a un gestor de secretos o a una variable de entorno que el código lea en tiempo de ejecución.
Cuando no es posible actualizar una dependencia
La mayoría de las herramientas de « SCA » y los avisos de seguridad ofrecen el mismo consejo para un paquete vulnerable: actualizar a la versión que incluye la corrección. En el caso de un simple aumento del número de parche, eso suele ser suficiente. El problema surge cuando la corrección no llega de forma tan sencilla, y en la práctica suele ser así.
El problema surge cuando la solución solo está disponible en una nueva versión principal con cambios en la API que rompen la compatibilidad, o cuando el paquete vulnerable es transitivo y la actualización depende de un responsable situado tres niveles por encima en el árbol de paquetes. Los paquetes abandonados y las versiones al final de su ciclo de vida nunca reciben una versión parcheada, y actualizar por inercia es precisamente cómo las versiones secuestradas de «chalk» y «debug» llegaron a los flujos de trabajo en cuestión de minutos. Por eso, los equipos posponen la actualización y el CVE pasa a una lista de ignorados que no deja de crecer.
El CVE-2026-48937 en Node.js ilustra cómo se desarrolla esto. La corrección se lanzó junto con una actualización de versión mayor según semver de nghttp2 que eliminó por completo la señalización de prioridad de HTTP/2, ya que el comportamiento vulnerable y la característica eliminada procedían del mismo código subyacente. Para un equipo que gestionara un servicio HTTP/2, un simple cambio de versión de una sola línea se convirtió en una búsqueda exhaustiva de todas las llamadas a setPriority y .priority(), tanto en su propio código como en cualquier dependencia que utilizara las mismas API, mientras el CVE permanecía abierto.
El «backporting» es la solución más directa: consiste en aplicar la corrección a la versión que ya estás utilizando. Puedes crear una bifurcación del paquete y hacerlo tú mismo, aunque en ese caso serás el responsable de esa bifurcación, o bien utilizar una versión parcheada de un proveedor que ofrezca «backports», como hace Aikido Security con paquetes de código abierto e imágenes de contenedores. Puedes cerrar el CVE y actualizar el sistema cuando tu equipo tenga tiempo para probarlo adecuadamente.
Prácticas recomendadas para la corrección de vulnerabilidades
Establecer los SLA en función del riesgo
Una vez que hayas clasificado los hallazgos según su explotabilidad y exposición, asigna a cada nivel de riesgo un plazo que tu equipo pueda cumplir. Un acuerdo de nivel de servicio (SLA), medido en días para una vulnerabilidad incluida en la lista KEV en un servicio expuesto a Internet, y en semanas para un medio accesible en una herramienta interna, ordena la cola. Realiza también un seguimiento de los incumplimientos respecto a esos SLA, ya que un patrón de incumplimientos en un equipo o en una capa suele indicar un problema de proceso que conviene solucionar.
Aplica las correcciones allí donde los desarrolladores ya trabajan
Un hallazgo que queda relegado a un panel de seguridad compite con todas las demás tareas que tiene entre manos un desarrollador, y normalmente sale perdiendo. Mostrarlo en el IDE mientras se escribe el código, o en la solicitud de incorporación de cambios antes de que se fusione, significa que el desarrollador lo ve mientras el cambio aún está fresco en su mente. Es entonces cuando tiene más contexto sobre lo que se pretende que haga el código, y cuando solucionarlo cuesta menos, antes de que se publique. Además, resuelve la cuestión de la responsabilidad, ya que quien haya abierto la solicitud de incorporación de cambios es, obviamente, la persona indicada para solucionarlo.
Automatizar las correcciones que no modifican el comportamiento
Los parches retrocompatibles y los cambios de nivel de parche que superen tus pruebas pueden fusionarse tras una revisión superficial, ya que cierran un CVE sin alterar el comportamiento de tu código. Las correcciones de fallos lógicos, como un IDOR o la falta de una comprobación de autorización, sí que modifican el comportamiento, por lo que resultan más útiles cuando van acompañadas de una explicación que muestre cómo podría explotarse el fallo y qué garantiza la corrección, lo que agiliza la revisión. Las actualizaciones que implican un cambio de versión principal son aquellas en las que la automatización resulta menos útil, y la sección anterior sobre «la trampa de las actualizaciones» aborda las mejores opciones para esos casos.
Vuelve a comprobarlo antes de cerrar
Vuelve a ejecutar la herramienta que detectó la vulnerabilidad en la versión corregida y cierra el informe solo cuando ya no aparezca. En el caso de los informes detectados en una aplicación en ejecución, esto implica volver a realizar pruebas en el entorno de producción, ya que una corrección que pasa las pruebas en una rama puede seguir fallando si hay un proxy mal configurado o una versión antigua que nunca se haya vuelto a implementar.
Cómo gestiona « Aikido Security » la corrección de vulnerabilidades
Aikido Security Abarca el proceso de corrección desde el primer indicio de una vulnerabilidad hasta la solicitud de incorporación de cambios (pull request) que la soluciona. Comienza con Aikido Intel, que realiza un seguimiento de las vulnerabilidades en paquetes de código abierto antes de que se les asigne un CVE, incluidas muchas que nunca lo tendrán, de modo que la corrección puede comenzar antes de que aparezcan en las bases de datos públicas.
A continuación, cada hallazgo pasa por dos fases de clasificación. análisis de alcanzabilidad comprueba si tu código tiene alguna ruta de ejecución hacia la función vulnerable, lo que elimina los CVE de los paquetes que incorporas pero que nunca utilizas. Lo que queda pasa a CVE análisis de explotabilidad, un agente que analiza cómo utiliza realmente tu código el paquete y, a continuación, actúa en función de cada hallazgo: eleva la gravedad cuando un CVE resulta más peligroso en tu entorno de lo que sugiere su puntuación base, la reduce cuando es menos peligroso, pospone los hallazgos para revisarlos más tarde o ignora aquellos que no son explotables en absoluto. Juntos reducen el ruido hasta en un 95 %.
Las correcciones llegan en forma de solicitudes de incorporación de cambios (pull requests) de AutoFix. En el caso de los hallazgos relacionados con el código y la infraestructura como código (IaC), AutoFix redacta el cambio por sí mismo. En cuanto a las dependencias y los contenedores, la corrección consiste en una adaptación a versiones anteriores. Aikido Libraries genera compilaciones parcheadas de las versiones de los paquetes que ya utilizas en npm, PyPI, Maven y Go, de modo que el CVE se cierra sin necesidad de aumentar la versión ni de modificar la API, incluso cuando no existe una versión parcheada en el proyecto original. Aikido Images hace lo mismo en el ámbito de los contenedores, con más de 2.000 imágenes de sustitución directa que eliminan los CVE de gravedad alta y crítica según un SLA definido para la versión del sistema operativo y la distribución que ya utilizas.
Ambos envían a diario solicitudes de incorporación de cambios (pull requests) de AutoFix en el flujo de trabajo que tu equipo ya utiliza. Una solicitud de incorporación de cambios aún debe someterse a pruebas e implementarse antes de que la vulnerabilidad desaparezca realmente, y ese es el paso del que se encarga AutoShip. Añade una etiqueta a una solicitud de incorporación de cambios de AutoFix y AutoShip la traslada desde la integración continua (CI) pasando por el entorno de prueba hasta la producción, ejecutando pruebas de smoke y vigilando posibles regresiones a lo largo del proceso, de modo que la corrección llegue a producción sin que ningún desarrollador tenga que interrumpir el trabajo en el que está inmerso.
Aikido también aporta de forma gratuita a la comunidad de código abierto las correcciones retroactivas para las vulnerabilidades incluidas en la lista KEV, de modo que las fallas que los atacantes están aprovechando activamente se subsanan para todos, sean o no clientes. Y, dado que todas las correcciones pasan por la misma plataforma, cada una de ellas se registra como prueba de cumplimiento de la norma SOC 2 y de las normas ISO que Aikido admite, incluidas la ISO 27001 y la ISO 42001.
{{walkthrough}}
