La inteligencia artificial (IA) ha transformado casi todos los aspectos del desarrollo de software y la ciberseguridad, pero uno de los cambios más significativos ocurre en una esfera que hasta ahora había recibido menos atención estratégica: la gestión de vulnerabilidades de software.
El modelo básico para gestionar vulnerabilidades ha permanecido relativamente inalterado durante años: escanear el software, identificar las vulnerabilidades conocidas como CVE (Common Vulnerabilities and Exposures), asignarles una puntuación según su gravedad, priorizar estos hallazgos y enviarlos a los desarrolladores para que los solucionen. Aunque este método nunca ha representado fielmente el riesgo real, ahora, en la era de la IA, sus limitaciones se hacen cada vez más evidentes.
El problema no reside únicamente en la cantidad creciente de vulnerabilidades que las organizaciones deben abordar. La producción de software crece a un ritmo vertiginoso, el descubrimiento de fallos aumenta, y el tiempo que lleva desarrollar exploits se reduce de manera drástica. Además, los ataques potenciados por IA pueden combinar distintas vulnerabilidades creando rutas de ataque imprevisibles de forma manual. 
Esta situación genera una brecha creciente entre el número de vulnerabilidades que los equipos de seguridad pueden detectar y aquellas que pueden analizar y resolver eficazmente. Para cerrar esa brecha, es fundamental cambiar el enfoque: en lugar de preguntar “¿Cuántos CVE tenemos?”, la cuestión debe ser “¿Qué vulnerabilidades representan un riesgo real en nuestro entorno?”.
La gravedad no es sinónimo de riesgo
Un CVE indica la existencia pública de una vulnerabilidad, pero por sí solo no revela la probabilidad de que esa vulnerabilidad sea explotada en una organización concreta. Esta diferencia es esencial para comprender la gestión del riesgo.
El Common Vulnerability Scoring System (CVSS) se utiliza para comunicar la severidad técnica y el impacto potencial en caso de explotación exitosa. Sin embargo, esta puntuación no informa si ya existe un exploit, si la vulnerabilidad está siendo activamente explotada, si el componente afectado es accesible externamente, o si el código vulnerable se ejecuta realmente en un entorno determinado.
Por ejemplo, dos empresas pueden contar con el mismo CVE en sus sistemas y sin embargo enfrentarse a niveles de riesgo radicalmente distintos. Una puede tener ese componente vulnerado protegido tras múltiples capas, sin exposición externa ni caminos relevantes de ejecución. Otra puede usar ese mismo componente en una aplicación visible desde internet que respalda procesos críticos del negocio.
El CVE es idéntico. El riesgo no lo es.
Este fenómeno demuestra que los programas de gestión basados en puntajes estáticos pueden generar una falsa sensación de avance, ya que equipos pueden gastar tiempo cerrando muchas vulnerabilidades sin reducir realmente las exposiciones más peligrosas. Esto es lo que algunos llaman “teatro CVE”: medir actividad en lugar de gestionar riesgo real.
La IA cambia la economía de la explotación
La velocidad y el volumen de desarrollo de software han crecido enormemente, impulsados en parte por la IA y la dependencia de componentes de código abierto. Aunque la densidad de vulnerabilidades puede disminuir por línea de código, la cantidad total de software crece y con ella la exposición general.
Los atacantes se benefician de la automatización para acelerar tareas que antes exigían mucho esfuerzo manual. Esto, combinado con un menor tiempo para explotar vulnerabilidades, transforma radicalmente el escenario de seguridad.
Por ello, los procesos de gestión de vulnerabilidades no pueden depender de soluciones manuales largas y secuenciales. Deben ser más contextuales, constantes y automatizados.
Mitigar el riesgo desde el origen
La mejora más efectiva en la gestión de vulnerabilidades consiste en reducir la entrada de fallos al entorno desde el principio, no solo remediarlos tras su aparición.
Esto comienza con la base del software: usar imágenes fortalecidas o librerías seleccionadas, emplear análisis de seguridad de código estático (SAST) asistido por IA para el código propio y detectar configuraciones débiles mediante marcos de referencia como los Security Technical Implementation Guides (STIGs).
Las vulnerabilidades son solo una dimensión de la seguridad del software. Sistemas con pocas CVE pueden estar peligrosamente configurados, con privilegios excesivos o autenticaciones débiles, brindando a los atacantes vías para acceder o moverse lateralmente.
El escaneo con STIG evalúa configuraciones contra requerimientos de seguridad y puede automatizar la identificación y corrección de estos fallos, con el objetivo de entregar un software lo más seguro posible antes de que se convierta en un problema de remediación de terceros.
Escanear lo que realmente está en producción
Otro cambio clave es entender que el entorno de producción es la verdad definitiva.
Muchas organizaciones escanean registros o repositorios antes del despliegue, pero esa información refleja el riesgo percibido, no el real. Producción cambia, las imágenes y configuraciones evolucionan, y nuevas vulnerabilidades surgen tras el lanzamiento.
Por eso, es imprescindible mantener visibilidad y auditoría continuas de lo que efectivamente se está ejecutando, usando análisis de alcance (reachability) y contexto ambiental.
El análisis de accesibilidad en red determina si un sistema es accesible externamente, mientras que la evaluación a nivel de software revela si el camino vulnerable realmente se ejecuta. Estas preguntas alteran de manera crucial la prioridad en la remediación.
Modelo de remediación basado en el riesgo real
Conociendo qué hay en producción, el siguiente paso es evaluar las vulnerabilidades en función del contexto que realmente importa, y eso implica ir más allá del CVSS.
Inteligencia sobre amenazas aporta señales claves: el catálogo Known Exploited Vulnerabilities (KEV) de CISA identifica fallos ya explotados y el Exploit Prediction Scoring System (EPSS) estima la probabilidad de que una vulnerabilidad sea aprovechada en un periodo próximo.
Estas señales se combinan con información sobre exposición en producción, alcance, configuración, impacto de negocio y tiempo de exposición, para formular preguntas útiles para los equipos de ingeniería: ¿qué vulnerabilidad arreglamos primero, en este entorno y por qué?
Este enfoque contrasta radicalmente con entregar a los desarrolladores hojas de cálculo con miles de CVEs ordenados solo por gravedad.
La gestión continua del riesgo como objetivo final
El objetivo no es alcanzar un panel de vulnerabilidades vacío, algo irreal y tampoco necesariamente el mejor indicador de seguridad en entornos modernos. La meta debe ser una comprensión progresiva y continua del riesgo real, mediante un enfoque en capas.
Esto implica partir de bases de software seguras, escanear el código propio, reforzar configuraciones, monitorizar la producción, determinar la accesibilidad, integrar inteligencia sobre amenazas y priorizar la remediación según exposición e impacto real. También es necesario adaptar los tiempos de corrección a diferentes tipos de vulnerabilidades.
Necesitamos saber qué puertas están abiertas, cuáles puede alcanzar un atacante, cuáles llevan a lugares críticos y cuáles suponen el mayor riesgo ahora mismo.
La IA complica sostener el modelo tradicional, pero también brinda la oportunidad de repensar la gestión de vulnerabilidades con objetivos mucho más significativos. No basta con contar cuántas puertas tiene el software; hay que identificar cuáles están abiertas y representan un peligro prioritario.
Gestionar el riesgo real en la era de la inteligencia artificial resulta ya imprescindible para garantizar la seguridad efectiva de las organizaciones.
