Que el CVE de tu proveedor no pare de crecer ya no es una alarma: es un aval
La IA ha abaratado la búsqueda de fallos de software hasta casi nada, así que un recuento de vulnerabilidades ya no mide lo mal construido que está un código: mide con qué intensidad se le está buscando. Cualquier scorecard que penalice las cifras altas está leyendo el indicador al revés.
Hay una cifra en todo cuestionario de seguridad que ha dejado de significar, en silencio, lo que significaba antes. El recuento de CVE de un proveedor, el total acumulado de vulnerabilidades reveladas públicamente, se ha leído durante dos décadas como un indicador de la calidad de construcción: más fallos, peor software. Esa lectura acaba de invertirse. Los proveedores cuyo recuento sube más deprisa son, cada vez más, los que más invierten en encontrar sus propios fallos, y los que presentan un historial impecable son, cada vez más, los que nadie ha revisado a fondo.
Sigamos el mecanismo. Un recuento de disclosures no mide una sola cosa. Es el producto de dos variables: cuántos fallos existen en el código y cuánto esfuerzo se dedica a buscarlos. Durante casi toda la historia del sector, la segunda variable se mantuvo prácticamente constante, porque encontrar fallos era mano de obra cara. Los investigadores cualificados escaseaban, mantener granjas de fuzzing costaba dinero de verdad y el triaje se comía horas de ingeniería aparte. Con el esfuerzo de búsqueda más o menos igual entre proveedores, contar disclosures decía algo, imperfecto pero algo, sobre el propio código.
El hallazgo de vulnerabilidades impulsado por IA rompe esa premisa. Cuando una máquina puede leer un código a escala, generar fallos candidatos y reproducirlos sin intervención humana, el esfuerzo de búsqueda deja de ser constante y pasa a ser la variable dominante. El recuento ya no mide el objetivo. Mide el foco que lo ilumina.
¿Un recuento alto de CVE es señal de mal software?
Nunca fue un indicador limpio, y ahora está cerca de ser justo lo contrario. Observa las notas de versión de cualquier proveedor que activa la búsqueda de fallos a escala de máquina y verás siempre la misma forma: una línea base larga y plana, luego un precipicio, con más parches de seguridad en un par de versiones que en años de actualizaciones anteriores. Nada en el código empeoró en ese momento. Lo que cambió es que saber salió barato.
El cambio de fondo es que se está automatizando toda la cadena, no solo la búsqueda. Encontrar el fallo, reproducirlo, clasificar su gravedad, asignarlo al desarrollador correcto, redactar el parche, escribir la prueba de regresión: cada fase que antes necesitaba a una persona se está delegando en una máquina. Y eso importa porque el verdadero límite de velocidad en la gestión de vulnerabilidades nunca fue cuántos fallos se podían encontrar, sino cuántos se podía permitir conocer una organización. Un equipo de triaje humano puede absorber unas pocas docenas de reportes fiables a la semana antes de que la propia cola se convierta en la vulnerabilidad. Automatiza la cadena de punta a punta y esa cantidad asumible se dispara, y el recuento de disclosures se dispara con ella.
Aquí es donde el scorecard ingenuo se equivoca del todo: un cuestionario que resta puntos por volumen alto de CVE está restando puntos justo por la inversión que debería premiar.
¿Quién gana cuando encontrar fallos sale casi gratis?
Casi gratis no es gratis para todos por igual. La capacidad está concentrada: ejecutar búsqueda con modelos de frontera sobre una base de código grande exige cómputo serio y acceso a los modelos más potentes. Un proveedor que pueda tomar prestada esa capacidad de sus propios equipos de IA puede escanear de forma continua. Un proyecto de código abierto sin financiación, o un proveedor mediano sin división de IA, no puede. El resultado probable es una brecha de seguridad entre los que tienen IA de frontera y los que no: no una diferencia en cuántos fallos tiene el código, sino en quién sabe dónde están.
El código público agudiza la carrera. Cuando el código fuente es abierto, un atacante no paga ningún peaje de ingeniería inversa; la misma automatización que permite a un defensor sacar a la luz mil fallos está disponible para el adversario en cuanto tiene acceso a esa capacidad. Eso no es un argumento contra el código abierto. Es un argumento de que el indicador que importa se ha desplazado de cuántos fallos tienes a quién ejecuta primero la pasada de búsqueda y con qué rapidez llegan los parches. La cadencia de búsqueda y la latencia de parcheo llevan ahora la señal que antes llevaba el recuento de CVE.
El efecto de segundo orden es peor. Si los compradores siguen penalizando la revelación de fallos, hacen algo más que leer mal el mercado: lo empujan en la dirección equivocada. Un proveedor que ve cómo sus clientes puntúan el recuento en bruto tiene un incentivo racional para buscar menos y revelar más despacio. Los indicadores mal diseñados no se limitan a no medir el rigor. Lo penalizan con un impuesto.
¿Qué deben hacer ahora los consejos y los equipos de compras?
Recalibrar, de forma deliberada, antes del próximo ciclo de contratación. Repasa todos los sitios donde un recuento bruto de vulnerabilidades tiene peso real: la puntuación del cuestionario, los umbrales del registro de riesgos, las cláusulas contractuales que se activan por volumen de disclosures, la diapositiva trimestral que ve el consejo. Cada uno de esos puntos castiga hoy al riguroso y favorece al que nadie ha revisado. Sustitúyelos por preguntas que sobrevivan a la inversión: ¿el proveedor mantiene un programa de búsqueda continua, asistido por IA o no?; ¿cuál es el tiempo medio entre el hallazgo y el parche publicado?; ¿existe una política de divulgación publicada con fechas auditables? Un proveedor que responda bien a eso mientras publica un recuento de CVE al alza te está enseñando sus deberes. Uno con historial impoluto y sin relato de búsqueda te está enseñando una habitación a oscuras.
Esa recalibración es, antes que un ejercicio técnico, un ejercicio de estrategia: decidir qué evidencia aporta realmente una cifra antes de que alguien cobre o sea penalizado por ella, el tipo de trabajo que abordamos en estrategia técnica. Y si el plan es apuntar agentes de búsqueda hacia tu propio parque tecnológico, entran en juego dos disciplinas antes del primer escaneo. La maquinaria necesita el contenimiento que planteamos en sistemas agénticos seguros, y las decisiones que de verdad importan (gravedad, explotabilidad, cuándo revelar) necesitan a una persona detrás, por las razones que argumentamos en IA práctica con control humano. Automatizar la búsqueda no es lo mismo que automatizar el juicio.
El recuento de fallos dejó de medir el código el día en que las máquinas empezaron a leerlo a escala. Ahora mide el foco. Los compradores que lo sigan puntuando a la vieja usanza no están eligiendo al proveedor más seguro del catálogo: están eligiendo la habitación más oscura.
Preguntas frecuentes
¿Un recuento alto de CVE es malo a la hora de elegir un proveedor de software?
No por sí solo. Un recuento de CVE es el producto de los fallos presentes y el esfuerzo dedicado a encontrarlos, y la búsqueda impulsada por IA ha convertido el esfuerzo en la variable dominante. Valora a los proveedores por su cadencia de búsqueda, el tiempo medio entre hallazgo y parche, y la transparencia de su política de divulgación, no por la cifra en bruto.
¿Cómo deben cambiar los cuestionarios de seguridad ahora que la IA encuentra vulnerabilidades?
Elimina la puntuación y las cláusulas contractuales que se activan por volumen de disclosures, porque penalizan a quien más busca. Pregunta en su lugar si el proveedor mantiene búsqueda continua, con qué rapidez los fallos confirmados se convierten en parches publicados, y si su historial de divulgación es auditable con fechas.
¿La búsqueda de fallos con IA ayuda tanto a los atacantes como a los defensores?
La capacidad es simétrica, y el código publicado en abierto elimina cualquier barrera de ingeniería inversa, así que la ventaja va para quien ejecute primero la pasada de búsqueda. Los defensores solo mantienen la delantera escaneando de forma continua y publicando parches más rápido de lo que los adversarios pueden convertir los hallazgos en armas.
Relacionado
- En Ubuntu 26.04 LTS, el coreutils del que depende tu build ya no es de GNU
- La prima de la soberanía: por qué las soluciones de IA soberana para empresas ganan por acceso, no por velocidad
- Los pleitos por secretos comerciales se ganan años antes de que nadie dimita. Que se lo pregunten a Faccenda Chicken.
- Security & Trust
Escrito por una persona editorial de IA del sistema editorial propietario de Abyshire y revisado por nuestro equipo.