Remediación
Correcciones de código con IA y remediación automatizada, aprobadas por una persona
Las correcciones de código con IA son cambios que propone un modelo de IA para eliminar una vulnerabilidad, normalmente una actualización de dependencia o una pequeña edición del código. Pueden acortar el tiempo de corrección, pero una persona debería aprobar cada una, porque una corrección puede romper el comportamiento, introducir nuevos paquetes transitivos, cambiar una licencia o, simplemente, no resolver el problema.
Plan gratuito, sin tarjeta.
¿Qué son las correcciones de código con IA y la remediación automatizada de vulnerabilidades?
La remediación automatizada de vulnerabilidades abarca cualquier herramienta que convierte un hallazgo en un cambio propuesto. Para una dependencia vulnerable, suele ser una nueva versión en el manifiesto y un lockfile regenerado. Para un hallazgo del análisis de código fuente, es una edición del código, como sustituir una consulta construida con cadenas por una consulta parametrizada. Para una configuración incorrecta, es un ajuste modificado en un Dockerfile o en un archivo de Terraform. Hoy se usan modelos de IA tanto para escribir estos cambios como para explicarlos.
Los enfoques se diferencian sobre todo en cuánto ve una persona antes de que se aplique un cambio. En un extremo, una herramienta sugiere una corrección junto a un hallazgo y un desarrollador la aplica a mano. En el medio, una herramienta prepara un cambio que alguien revisa. En el otro extremo, los cambios se fusionan automáticamente cuando pasan las pruebas. Cuanto más se acerca un proceso a la fusión automática, más depende de pruebas capaces de detectar una corrección rota o incompleta.
Por qué una persona debería aprobar cada corrección
Una corrección propuesta es un cambio en el código de producción, escrito por algo que no puede ejecutar tu producto en los entornos de tus clientes. El modelo puede mostrarse seguro y equivocarse, y un diff limpio puede esconder un cambio de comportamiento. Aprobar no significa rehacer el trabajo; significa que una persona con nombre y apellidos ha comprobado los puntos siguientes y acepta el cambio. Ese registro también sirve después como evidencia, cuando tengas que demostrar cómo se gestionó una vulnerabilidad.
- Cambios incompatibles: una actualización de versión mayor puede eliminar o modificar las API a las que llama tu código.
- Actualizaciones transitivas: una nueva versión puede arrastrar paquetes nuevos, cada uno con sus propias vulnerabilidades y sus propios mantenedores.
- Cambios de licencia: una nueva versión puede pasar a una licencia que tu organización no acepta.
- Riesgo de regresión: el comportamiento que tus pruebas no cubren puede cambiar sin que nadie lo note.
- Correcciones incompletas: el cambio puede pasar por alto una ruta de código afectada o apuntar a un rango de versiones equivocado.
- Detalles inventados: una versión o un paquete propuesto que no existe.
Cómo evaluar una actualización de dependencia propuesta
Empieza por el aviso, no por la propuesta. En el formato OSV, los rangos afectados de un aviso registran dónde se introdujo una vulnerabilidad y en qué versión se corrigió. El movimiento seguro más pequeño suele ser la primera versión corregida de la línea de versiones que ya usas, porque es la que menos cambia. Saltar a la versión mayor más reciente puede corregir más cosas, pero además de un parche de seguridad es una actualización de funcionalidades y merece su propia revisión.
Si el paquete vulnerable no es uno que declaras tú, llega a través de una dependencia directa. Actualizar el paquete transitivo por separado puede entrar en conflicto con lo que espera su paquete padre, así que la corrección más limpia suele ser actualizar el padre a una versión que resuelva el paquete vulnerable a una versión corregida. Las sobrescrituras del gestor de paquetes (overrides) son un último recurso cuando todavía no existe esa versión; déjalas registradas para quitarlas cuando el padre se ponga al día.
| Comprobación | Qué mirar |
|---|---|
| Versión corregida | El aviso indica como corregida la versión propuesta, o una anterior de la misma línea. |
| Directa o transitiva | En un paquete transitivo, está identificada la dependencia directa que hay que actualizar. |
| Diff del lockfile | Solo cambian los paquetes esperados y no aparece ningún paquete nuevo inesperado. |
| Notas de la versión | Sin cambios incompatibles, funcionalidades eliminadas ni cambio de licencia. |
| Pruebas | La batería de pruebas pasa y cubre el código que usa el paquete. |
| Origen | La versión se publicó en el registro oficial y la publicaron los mantenedores habituales del paquete. |
Qué dice el Reglamento de Ciberresiliencia sobre la corrección de vulnerabilidades
El anexo I, parte II, del Reglamento de Ciberresiliencia (Cyber Resilience Act), Reglamento (UE) 2024/2847, fija los requisitos de gestión de las vulnerabilidades para los fabricantes. El punto 2 les exige, en relación con los riesgos para el producto, abordar y subsanar las vulnerabilidades sin demora, también mediante la provisión de actualizaciones de seguridad, y, cuando sea técnicamente viable, facilitar las nuevas actualizaciones de seguridad por separado de las actualizaciones de funcionalidad. Esto importa cuando una corrección llega dentro de un gran salto de versión.
El punto 8 exige que, cuando haya actualizaciones de seguridad disponibles para hacer frente a los problemas de seguridad detectados, se difundan sin demora y, salvo que se acuerde otra cosa con un usuario profesional para un producto a medida, de forma gratuita, acompañadas de mensajes de aviso que indiquen a los usuarios lo que necesitan saber, incluidas las medidas que deban adoptar. El CRA no prescribe cómo se escribe una corrección, si la hace una persona o se hace con IA. Estos requisitos se aplican a partir del 11 de diciembre de 2027.
Cuándo no corregir: dejar constancia de que una vulnerabilidad no te afecta
No todo hallazgo requiere un cambio en el código. Puede que nunca se llame a una función vulnerable o que la funcionalidad afectada esté desactivada en tu build. En ese caso, una decisión documentada es mejor que una actualización que añade sus propios riesgos. Un documento VEX (Vulnerability Exploitability eXchange) registra, para cada vulnerabilidad, si un producto está afectado y por qué, en un formato legible por máquina que pueden leer clientes y autoridades. Conserva la evidencia que respalda cada declaración de «no afectado» y revísala cuando cambie el código.
Disponible hoy en KROMSE
KROMSE te dice qué cambiar y por qué; una persona de tu equipo decide y hace el cambio.
- Orientación de actualización a partir de los datos de los avisos: la versión corregida del paquete vulnerable y, en un paquete transitivo, la dependencia directa que lo introduce, cuando el lockfile lo demuestra. No se inventa ninguna versión para ese padre.
- Un veredicto de IA por hallazgo, dentro del uso incluido en tu plan, junto a una explicación en lenguaje claro.
- Acciones de respuesta propuestas por el asistente de IA, cada una de las cuales una persona aprueba o rechaza.
- Paquetes maliciosos marcados como críticos, con la eliminación como única solución.
- En proyectos Go, un análisis de llamadas que puede mostrar si tu código llama a la función vulnerable.
- Exportación VEX en CycloneDX 1.6 VEX y OpenVEX 0.2.0, y casos de respuesta CRA con plazos y decisiones humanas registradas.
- Nada modifica el código: la aplicación de GitHub es de solo lectura y KROMSE no puede abrir pull requests.
Próximamente
En la hoja de ruta, todavía no disponible. Las fechas son objetivos, no promesas; esta página cambia el mismo día en que una funcionalidad está operativa.
- Próximamente · T4 2026 (noviembre)Propuestas de corrección con IA, aprobadas por una persona. KROMSE propondrá correcciones para los hallazgos, redactadas con IA y aplicadas solo después de que una persona de tu equipo las apruebe.
- Próximamente · T4 2026 (noviembre)Plugin para agentes de programación. Un plugin para agentes de programación con IA comprobará cada paquete que proponga el agente antes de que entre en el código, incluidos los paquetes que no existen o que se publicaron hace solo unos días.
- Próximamente · T4 2026 (diciembre)Monitorización según tu calendario, con agentes de IA. Los reanálisis se ejecutarán con la periodicidad que tú fijes, con agentes de IA que vigilarán los nuevos avisos, clasificarán lo que te afecta, propondrán correcciones y redactarán el informe para tu revisión.
Preguntas frecuentes
¿Es seguro fusionar automáticamente las correcciones de código con IA?
Solo donde las pruebas y la revisión detectarían una corrección rota, e incluso entonces con cuidado. Un cambio propuesto por IA puede romper una API, arrastrar nuevos paquetes transitivos, cambiar una licencia o dejar sin resolver parte de la vulnerabilidad. Que una persona con nombre y apellidos apruebe cada corrección, con el diff del lockfile y las notas de la versión delante, es la opción por defecto más segura para el código de producción.
¿Cuál es la versión mínima segura en una actualización de dependencia?
Suele ser la primera versión que el aviso indica como corregida en la línea de versiones que ya usas. Elimina la vulnerabilidad con el menor cambio de comportamiento. Un salto mayor, sobre todo entre versiones mayores, puede merecer la pena, pero también es una actualización de funcionalidades que necesita su propia revisión y sus propias pruebas.
¿Cómo corrijo una vulnerabilidad en una dependencia transitiva?
Localiza la dependencia directa que introduce el paquete vulnerable y actualízala a una versión que resuelva el paquete a una versión corregida. Si no existe esa versión, una sobrescritura del gestor de paquetes puede forzar la versión corregida, pero déjala registrada y quítala cuando el padre se ponga al día, porque una sobrescritura puede romper el paquete padre.
¿El Reglamento de Ciberresiliencia exige una remediación automatizada?
No. El anexo I, parte II, exige a los fabricantes abordar y subsanar las vulnerabilidades sin demora en relación con los riesgos, también mediante actualizaciones de seguridad, y difundir sin demora las actualizaciones de seguridad disponibles y, por regla general, de forma gratuita. No dice cómo se producen las correcciones. La automatización ayuda con la velocidad; las decisiones documentadas, con la evidencia.
¿KROMSE aplica correcciones a mi código?
No. KROMSE explica cada hallazgo, da orientación de actualización a partir de los datos de los avisos y puede proponer acciones de respuesta que una persona aprueba o rechaza. No edita código ni abre pull requests. Las propuestas de corrección con IA que solo se aplican después de que una persona las apruebe están en la hoja de ruta.