Apache escanea 230 repositorios con Project Glasswing y convierte la detección de vulnerabilidades por IA en un proceso de remediación
Fecha efectiva / observada:
Qué ha cambiado
La Apache Software Foundation (ASF) ha utilizado Project Glasswing y Claude Mythos 5 para ejecutar escaneos completos de seguridad sobre 230 repositorios y, más importante, ha documentado cómo convertir los hallazgos de una IA en un proceso real de revisión, divulgación responsable y remediación. QUÉ HA CAMBIADO El 3 de septiembre de 2026, ASF publicó los resultados operativos de un trabajo realizado durante una ventana de tres días en agosto. Los escaneos fueron coordinados por ASF Security y ASF Tooling dentro de la Responsible AI Initiative de la fundación. Se utilizaron: - Project Glasswing de Anthropic; - Claude Mythos 5; - sesiones paralelas de Claude Code; - modelos de amenazas revisados por personas; - el proceso oficial de divulgación de vulnerabilidades de Apache. El dato de “230 repositorios” es importante, pero no es lo más valioso. Lo relevante es que ASF ha descrito un flujo completo: CONTEXTO DEL PROYECTO → modelo de amenazas ANÁLISIS AUTOMATIZADO → escaneo con IA REVISIÓN → filtrado y priorización DIVULGACIÓN → canal oficial de seguridad REMEDIACIÓN → decisión y corrección por cada proyecto SEGUIMIENTO → futuros escaneos incrementales POR QUÉ APACHE NO QUISO SIMPLEMENTE “ESCANEAR TODO” ASF explica que estaba recibiendo un volumen creciente de informes de vulnerabilidades generados por IA. Algunos eran útiles. Otros consumían tiempo de mantenedores porque: - incluían falsos positivos; - ignoraban decisiones arquitectónicas conocidas; - analizaban componentes fuera de alcance; - repetían supuestos ya resueltos; - exigían revisar resultados que no tenían suficiente contexto. El problema, por tanto, no era únicamente encontrar más vulnerabilidades. Era conseguir que los resultados fueran suficientemente buenos para que los mantenedores pudieran actuar sobre ellos. MODELOS DE AMENAZAS ANTES DEL ESCANEO ASF Security pidió a los proyectos interesados que documentaran primero su postura de seguridad. Participaron 75 Project Management Committees (PMCs), que prepararon modelos de amenazas para más de 180 repositorios. Esos modelos describían: - qué componentes eran relevantes; - qué límites de seguridad debían mantenerse; - qué partes se consideraban confiables por diseño; - qué responsabilidades pertenecían al operador; - qué elementos quedaban expresamente fuera de alcance. ASF Security revisó cada modelo antes de utilizarlo en el análisis. Esto es importante porque la IA no recibió únicamente código. Recibió contexto sobre cómo se supone que funciona el sistema. EL CONTEXTO REDUJO EL COSTE ASF afirma que ejecutar los escaneos contra modelos de amenazas previamente revisados redujo el coste aproximadamente una quinta parte frente a hacerlo sin ese contexto. La razón es sencilla: sin contexto → el modelo tiene que redescubrir decisiones de arquitectura y puede investigar rutas irrelevantes con contexto → puede concentrar el análisis en los límites y componentes que el propio proyecto considera importantes ASF añade que este enfoque también evitó que hallazgos fuera del modelo de amenazas llegaran a los informes finales. Esto aporta una lección útil más allá de Apache: más potencia de IA no sustituye a proporcionar buen contexto. CÓMO SE EJECUTARON LOS ESCANEOS Cada análisis se ancló en el modelo de amenazas del proyecto. ASF ejecutó el harness de Glasswing en sesiones paralelas de Claude Code utilizando Mythos 5. La fundación afirma que no necesitó personalizar el harness y que utilizó una serie de prompts sencillos para iniciar el trabajo. Según ASF, después de una iteración mínima obtuvieron el conjunto completo de resultados en dos lotes. CALIDAD DE LOS HALLAZGOS ASF afirma que los resultados tuvieron un nivel bajo de falsos positivos. También informa de vulnerabilidades críticas acompañadas de borradores de parches. Esos parches no se aceptaron automáticamente. La fundación indica que fueron revisados por separado. Esta distinción es importante: IA ENCUENTRA ≠ IA DECIDE QUE ES VERDAD IA PROPONE UN PARCHE ≠ EL PARCHE SE APLICA AUTOMÁTICAMENTE Los resultados siguen pasando por personas y por los procesos de seguridad de cada proyecto. DIVULGACIÓN RESPONSABLE Todos los hallazgos pasan por el canal oficial de divulgación de Apache. Los resultados sensibles llegan primero: - al equipo de seguridad correspondiente; - o a la lista privada del proyecto afectado. Después, el PMC responsable: - evalúa el hallazgo; - decide su impacto real; - determina la prioridad; - corrige según su propio calendario; - publica la información cuando corresponde. ASF describe explícitamente esta fase como trabajo en curso: la remediación estaba todavía en marcha cuando publicó el informe. PRIORIDAD SEGÚN EXPLOTABILIDAD REAL, NO SOLO SEVERIDAD Otro punto interesante es cómo Apache ordena los resultados. No basta con una etiqueta como “High” o “Critical”. ASF prioriza según: - cómo se despliega realmente el software; - qué rutas son alcanzables; - qué controles existen; - cuánto esfuerzo debe dedicar un mantenedor. Un hallazgo de severidad alta en una ruta que nadie puede alcanzar puede tener menos prioridad operativa que otro de severidad menor pero fácilmente explotable en una configuración habitual. Esta diferencia entre “severidad teórica” y “prioridad real” es importante para evitar que el mantenimiento de seguridad se convierta en una lista sin contexto. QUÉ HABÍA CONSTRUIDO APACHE ANTES ASF Tooling ya estaba desarrollando desde principios de 2026 un pipeline automatizado de auditoría contra OWASP Application Security Verification Standard (ASVS). Ese pipeline funciona sobre Gofannon, una plataforma de agentes desarrollada por el propio equipo. ASF describe tres niveles de modelos: - ligero, para filtrado de gran volumen; - medio, para construir inventarios; - pesado, para análisis que necesita razonamiento. La arquitectura permite cambiar los modelos utilizados sin modificar el pipeline. ASF menciona configuraciones con: - Opus, Sonnet y Haiku; - o Mythos, Gemma y Qwen. Esto muestra que el valor del sistema no depende únicamente de un único modelo. La infraestructura está pensada para combinar calidad, velocidad, coste y modelos autoalojados cuando tenga sentido. PROJECT GLASSWING YA HABÍA CRECIDO ANTES Anthropic anunció Project Glasswing el 7 de abril de 2026. El programa comenzó con grandes organizaciones y más de 40 participantes adicionales vinculados a software e infraestructura crítica. El 2 de junio, Anthropic anunció una expansión aproximada de 150 organizaciones nuevas en más de 15 países. La empresa afirmó además que los participantes iniciales habían encontrado más de 10.000 vulnerabilidades clasificadas como de severidad alta o crítica. Ese dato procede de Anthropic. RA no debe interpretarlo automáticamente como: - 10.000 vulnerabilidades independientes confirmadas públicamente; - 10.000 CVE; - 10.000 fallos explotables en configuraciones reales. Es una afirmación del promotor del programa y necesita seguirse con evidencia pública de correcciones y divulgaciones. APACHE APORTA UNA EVIDENCIA MÁS ÚTIL El caso de ASF es especialmente relevante porque aporta algo distinto a una cifra promocional. Documenta: - cuántos repositorios se escanearon; - cómo se prepararon; - cómo se revisaron los modelos de amenazas; - cómo se ejecutó el análisis; - cómo se priorizaron los resultados; - cómo entran en el canal de divulgación; - quién decide la remediación; - qué quieren automatizar después. Eso convierte el caso de Apache en una evidencia operativa sobre cómo integrar una IA potente en un programa de seguridad sin entregar a la IA la decisión final. ESCANEO INCREMENTAL: EL SIGUIENTE PASO ASF quiere que los futuros escaneos no empiecen desde cero. Su objetivo es que el sistema recuerde: - resultados anteriores; - cambios en el modelo de amenazas; - vulnerabilidades ya corregidas; - publicaciones de CVE; - nuevas zonas del código. Este enfoque es importante porque un repositorio vivo cambia continuamente. Un escaneo puntual puede decir: “esto es lo que encontramos hoy”. Un escaneo incremental puede responder: “qué cambió desde la última revisión y qué sigue pendiente”. Eso acerca el sistema a una vigilancia continua. REVISAR INFORMES GENERADOS POR TERCEROS ASF también quiere aplicar su infraestructura a un problema que ya está recibiendo: informes de vulnerabilidades generados por IA por personas externas. Una futura función podría ayudar a: - analizar esos informes; - contrastarlos con el modelo de amenazas; - detectar duplicados; - distinguir hallazgos plausibles de ruido; - reducir el tiempo que los mantenedores dedican a triage. Esto será cada vez más importante a medida que cualquiera pueda lanzar modelos sobre repositorios públicos. AUTOSERVICIO Otro objetivo es convertir el escaneo en una función de autoservicio. En lugar de esperar a que un pequeño equipo ejecute manualmente los análisis, cada proyecto podría elegir qué escaneos necesita y lanzarlos contra un presupuesto de tokens gestionado por la fundación. Eso permitiría pasar de: - campaña puntual; a: - infraestructura disponible bajo demanda. Pero ASF todavía lo presenta como trabajo futuro. No debe confundirse con una capacidad ya desplegada a escala completa. LA DONACIÓN DE ANTHROPIC Cuando Anthropic lanzó Project Glasswing anunció, entre otros compromisos: - hasta 100 millones de dólares en créditos de uso del modelo para el programa y participantes; - 1,5 millones de dólares de donación directa a Apache Software Foundation; - financiación adicional para Alpha-Omega y OpenSSF. La colaboración actual de Apache se apoya en capacidad donada por Anthropic. Esto debe quedar visible porque afecta al contexto económico del experimento. Una pregunta importante para RA será qué ocurre cuando termine el acceso subvencionado o cambie el precio de los modelos. QUÉ NO DEMUESTRA ESTE CASO Los resultados de Apache NO demuestran que: - una IA pueda sustituir a un equipo de seguridad; - todos los hallazgos de Mythos sean correctos; - cada parche generado sea seguro; - todos los repositorios open source puedan reproducir el proceso sin coste; - un escaneo puntual garantice que no quedan vulnerabilidades; - un modelo de amenazas elimine falsos positivos; - Glasswing sea mejor que cualquier otra herramienta en todos los escenarios. Lo que sí demuestra el caso es que una organización grande puede integrar análisis con IA dentro de un proceso de seguridad existente sin saltarse gobernanza, revisión humana y divulgación responsable. LA LECCIÓN PARA RADARABIERTO Este caso encaja directamente con un principio que RA también necesita aplicar internamente: DETECTAR → no es suficiente ANALIZAR → no es suficiente HAY QUE: - aportar contexto; - contrastar; - conservar evidencia; - priorizar; - revisar; - documentar; - corregir; - seguir la evolución. Automatizar una detección sin todo lo demás puede aumentar el ruido en lugar de reducirlo. A QUIÉN PUEDE INTERESAR Si mantienes un proyecto open source: el caso muestra cómo preparar contexto antes de usar IA para buscar vulnerabilidades. Si trabajas en seguridad: interesa la combinación de threat modeling, análisis automatizado, triage y disclosure. Si desarrollas herramientas de IA: demuestra que la calidad final depende también de la información de contexto y del proceso que rodea al modelo. Si administras una fundación o comunidad: ofrece un ejemplo de cómo centralizar capacidades costosas sin quitar a cada proyecto la decisión sobre sus hallazgos. Si trabajas en cumplimiento o gobernanza: muestra una separación clara entre detección automática y responsabilidad humana. Si eres usuario de software Apache: el efecto será indirecto, pero el objetivo es encontrar y corregir fallos antes de que se conviertan en problemas explotados. QUÉ PUEDES HACER AHORA Si quieres aplicar una estrategia similar: 1. No empieces escaneando todo sin contexto. 2. Define primero el modelo de amenazas de cada sistema. 3. Documenta qué está dentro y fuera de alcance. 4. Separa detección, validación y decisión. 5. Exige evidencia reproducible para los hallazgos importantes. 6. No apliques automáticamente parches generados por IA. 7. Prioriza según exposición real y no solo por una etiqueta de severidad. 8. Conserva el histórico de hallazgos, falsos positivos, correcciones y CVE. 9. Diseña el siguiente escaneo como incremental. 10. Define cómo sostendrás el coste cuando termine cualquier financiación o crédito promocional. RECURSOS Informe de Apache: https://news.apache.org/foundation/entry/security-scanning-at-foundation-scale Project Glasswing: https://www.anthropic.com/glasswing Expansión de Project Glasswing: https://www.anthropic.com/news/expanding-project-glasswing Evaluación de Claude Mythos Preview: https://www.anthropic.com/research/mythos-preview Canal de vulnerabilidades de Apache: https://www.apache.org/security/ QUÉ VIGILARÁ RADARABIERTO RA debe seguir: - cuántos hallazgos de los 230 repositorios terminan confirmándose; - cuántos producen CVE; - cuántos se descartan como falsos positivos; - tiempos reales de remediación; - calidad de los parches propuestos por IA; - evolución de los threat models; - llegada del escaneo incremental; - herramientas de autoservicio; - análisis de informes externos generados por IA; - costes reales por repositorio; - qué ocurre cuando termina la capacidad donada; - comparación entre Glasswing y el pipeline propio de ASF; - publicación de métricas independientes; - efectos sobre la carga de trabajo de mantenedores; - problemas de seguridad del propio pipeline; - casos donde el contexto proporcionado al modelo sea incorrecto o incompleto; - nuevos incidentes que permitan medir si el sistema detectó o no vulnerabilidades relevantes. Esta señal debe mantenerse como historia viva. El punto importante ya no es que una IA pueda encontrar vulnerabilidades, sino si una organización puede convertir ese hallazgo en evidencia revisada, una corrección real y un aprendizaje que mejore el siguiente análisis.
Por qué puede importarte
Apache aporta evidencia de cómo pasar de una capacidad de IA para detectar vulnerabilidades a un proceso gobernado: contexto previo, revisión humana, priorización por exposición real, divulgación responsable, remediación y seguimiento. El caso permite evaluar qué parte del valor viene del modelo y qué parte depende de la ingeniería y gobernanza que lo rodean.
Cómo ha evolucionado
Estado actual: actual. Añadiremos los cambios posteriores sin borrar este registro.
Qué todavía no sabemos
ASF afirma bajos falsos positivos y vulnerabilidades críticas con borradores de parches revisados, pero no publica todavía el inventario completo de hallazgos ni cuántos acabarán en CVE. La cifra de más de 10.000 vulnerabilidades altas/críticas procede de Anthropic y no equivale a 10.000 CVE confirmados. La remediación sigue en curso y varias mejoras descritas por ASF son planes futuros.
Seguir el contexto
La señal conserva procedencia y relaciones internas para que puedas comprobar el origen y explorar cambios relacionados.
Esta ficha verificable es igual para todos. Puedes indicar si te afecta, si no se entiende, si quieres seguirla o si no te interesa. Para que seguir u ocultar cambie solo tu selección, crea Mi Radar.