1Password bajo fuego: críticas al paper FLAWED sobre IA

Un paper con problemas graves de rigor

El estudio "Frontier Models' Vulnerability Patches are Often F.L.A.W.E.D", publicado por Off-by-1 Labs, el equipo de investigación de 1Password, está en el centro de una tormenta metodológica. Una investigadora de seguridad conocida como suhacker publicó un extenso hilo y un blog detallado denunciando lo que califica como "slop" (trabajo descuidado disfrazado de investigación seria) en el paper, sumándose a las críticas previas de Trail of Bits y de Davi Ottenheimer.

El paper original afirmaba que los modelos de IA generaron parches útiles solo el 26% de las veces sobre seis vulnerabilidades reales en software open source, incluyendo fallos en Linux, ActiveMQ, Chrome y SpringAI, según reportó ZDNET. Los investigadores sometieron los modelos a 6.080 intentos de parche en total. Sin embargo, el número exacto de intentos y la metodología detrás de ese 26% son precisamente lo que está bajo cuestionamiento.

Los errores concretos que se le señalan

La crítica de suhacker identifica varios problemas que van más allá de los errores de evaluación ya mencionados por Trail of Bits. Los principales señalamientos son:

• Errores aritméticos verificables dentro del propio paper, con cifras que no cuadran al releer (por ejemplo, se mencionan 2.8 y "aproximadamente 4" como equivalentes).
• Diagramas incorrectos donde las referencias visuales no coinciden con el texto que las describe.
• Inconsistencias internas detectables con una lectura superficial.
• Y sobre todo: problemas graves de citación, lo que en la jerga académica se conoce como "plagio por omisión".

El paper solo cita 19 fuentes, en su mayoría entradas de blogs corporativos y una tira de XKCD, a pesar de afirmar que existe "muy poco trabajo previo" en el área. Mientras tanto, el paper concurrente PatchBench (publicado como arXiv:2609.04075) acumula 73 citas con literatura académica real, incluyendo el trabajo AutoPatchBench de Meta, que el paper de 1Password omite por completo. Tampoco cita un paper de NDSS sobre las trampas de la investigación en seguridad con LLMs, trabajo que habría expuesto muchas de las debilidades metodológicas que se le critican.

Además, sobre el programa "Patch the Planet" de OpenAI, el paper atribuye el trabajo a ingenieros de Trail of Bits, cuando según OpenAI también participaron equipos de Calif y HackerOne en tareas de triage y divulgación coordinada, un detalle factual verificable y erróneo.

Distinguir un paper riguroso de un post de marketing

El meollo del asunto no es solo 1Password, sino un problema estructural: ¿cómo debe evaluarse el trabajo de investigación cuando sale de un laboratorio corporativo con músculo de distribución?

La crítica señala que FLAWED adopta "la forma y la retórica de investigación rigurosa" pero no cumple con sus obligaciones básicas. Por ejemplo, el paper usa la frase "peer review" para describir la revisión de tres colegas de la industria, no el proceso de revisión por pares académicos. Tampoco se publicó en ningún repositorio científico o foro de revisión pública, por lo que no existe un registro versionado que permita rastrear correcciones.

Este punto es crítico para cualquier founder que contrate investigación o la use para tomar decisiones técnicas: el canal de distribución de un paper (comunicado de prensa, blog post, repo público) determina el nivel de exigencia que debe aplicarse al evaluarlo.

Qué dice la prensa y qué dice la comunidad técnica

ZDNET cubrió el paper cuando fue lanzado, destacando el titular de que "la IA no está lista para parchear tu software: falla el 74% de las veces", basado en el 26% de parches útiles reportado por Off-by-1 Labs. La cobertura periodística amplificó el mensaje a equipos de seguridad y CISO. Sin embargo, según suhacker, académicos e investigadores senior que leyeron el trabajo detectaron los problemas de inmediato; muchos no alzaron la voz por "falta de foro o miedo a represalias".

La autora del blog argumenta que esta dinámica tiene costos de segundo orden especialmente graves para académicos: agendas de investigación distorsionadas, trabajo de reproducción desperdiciado, financiamiento desviado hacia líneas que parecen "ya resueltas" cuando no lo están, y atención acaparada que invisibiliza investigación más rigurosa pero con menos recursos.

El lado incómodo: ¿la IA realmente no puede parchear?

Más allá del paper específico, la pregunta de fondo sobre si la IA puede o no generar parches seguros sigue abierta. La crítica no niega que la IA tenga problemas serios al parchear vulnerabilidades; más bien cuestiona que FLAWED sea la evidencia adecuada para afirmarlo.

La autora pide explícitamente que se financie y dé visibilidad a trabajos rigurosos que ya existen en este frente, mencionando a EleutherAI, al AI Now Institute, y a grupos académicos como CISPA, UMD y Drexel, que han publicado investigaciones críticas sobre LLMs en seguridad, con menos prensa pero más rigor.

¿Qué significa esto para tu startup?

Si construyes producto de seguridad, usas IA en tu pipeline, o simplemente consumes investigación técnica de proveedores, este caso deja lecciones claras y accionables.

Acciones concretas que puedes tomar esta semana:

• No cites papers de proveedores como si fueran literatura revisada por pares. Cuando reportes resultados en tu blog, deck para inversores o documentación técnica, distingue explícitamente entre "paper académico revisado", "white paper corporativo" y "comunicado de marketing". Tu credibilidad técnica depende de esa distinción.
• Audita las fuentes antes de amplificar. Si un informe de seguridad de un proveedor tiene menos de 30 citas y no enlaza literatura académica previa clave en el área, trátalo como una hipótesis inicial, no como un hallazgo establecido. Pasa 15 minutos verificando las referencias y buscando papers independientes sobre el mismo tema.
• Diseña tu propia evaluación interna de IA para parches antes de adoptarla. Si usas o vendes tooling con generación de parches asistida por IA, somételo a tus propios benchmarks con CVEs reales de tu stack, mide no solo si el parche "compila" sino si cierra la vulnerabilidad sin introducir regresiones. No delegues esa evaluación al proveedor.
• Pregunta por la cadena de revisión cuando contrates research. Si pagas por un informe técnico o comprás una herramienta basada en investigación, exigí ver quién revisó el trabajo, qué literatura se citó y qué se omitió. Es una pregunta legítima y un diferenciador de calidad.

El caso FLAWED no significa que la IA no sirva para seguridad. Significa que, como ecosistema, todavía estamos aprendiendo a separar investigación seria de contenido corporativo con branding de paper, y que los founders con criterio técnico tienen una ventaja competitiva real al hacerlo bien.

Fuentes

• FLAWED's Flaws and What This Means for Industry Research
• AI failed to properly patch software flaws 74% of the time, 1Password's study warns - ZDNET