La revisión de código adversarial consiste en leer código fuente con la pregunta de un atacante en mente (cómo podría hacerse que esto haga algo que no debe) en lugar de con la pregunta de un mantenedor sobre si el código es correcto y está ordenado. Lo que entregamos bajo ese nombre es un expediente de hallazgos firmado: cada hallazgo confirmado graduado por la evidencia que realmente alcanzó, cada superficie examinada y hallada sólida anotada junto con el método que la examinó, producido por revisores independientes del autor de su código, dictaminado por una persona con nombre que su adquirente, su aseguradora o su cliente puede citar, y retirado por escrito si no resiste. Esta página dice qué añade eso a los demás sentidos que la expresión ha tomado, y cuánto cuesta.
Qué significa hoy la expresión
Según nuestra lectura del mercado (una búsqueda en septiembre de 2026, no un censo), cuatro prácticas llevan el nombre. Cada una hace algo real. Las dos primeras son instrumentos de nuestro propio banco.
La instrucción crítica. Un agente escribe un cambio; un segundo, en contexto nuevo y a menudo de otra familia de modelos, lee el diff con lentes hostiles. Esto elimina la autoevaluación, lo que importa allí donde se aplica: medida sobre ocho modelos jueces, la preferencia por lo propio fue grande en uno, moderada en dos, cercana a cero en dos y ligeramente invertida en tres (preferencia por lo propio, arXiv:2410.21819). Como práctica aporta el encuadre del atacante; no aporta por sí sola un expediente conservado, una medida de cuán correlacionadas estaban las dos lecturas, ni una firma.
El orquestador de dos revisores. Dos familias de modelos revisan el mismo cambio de forma independiente (a veces ciegas entre sí) y luego se critican mutuamente, y una de ellas sintetiza el resultado, a menudo aplicando también la corrección. La fase ciega es acertada. Como forma, deja al modelo revisor como juez de sus propios hallazgos y como su reparador, y no produce por sí sola ni verdad de referencia ni una medida de correlación.
El conjunto de plataforma. Un producto de revisión ejecuta varios modelos dentro de su propia tubería y devuelve comentarios en el pull request con niveles de gravedad; lleva el nombre sobre todo por vecindad, ya que quienes se describen así practican de forma abrumadora las dos primeras. La pluralidad de modelos es aquí una decisión de diseño del proveedor; tal como se vende, la forma no expone qué modelo dijo qué, sobre qué evidencia, ni con qué frecuencia coinciden cuando se equivocan. Aporta volumen e integración. Un hilo de comentarios no es una auditoría.
La casa de humanos con mentalidad de atacante. Lectores con trayectoria ofensiva leen el código fuente como lo haría un atacante, sea como firma o como multitud. Aquí es donde se inventa un ataque que nadie había formulado, y es la práctica a la que la nuestra está hecha para alimentar, no para sustituir. Como forma, no separa por sí sola su evidencia de su veredicto, y la independencia de sus revisores entre sí está sin medir, como la de todos.
Tres propiedades, una sola palabra
Tres propiedades se empaquetan en adversarial: el encuadre de la tarea (la pregunta del atacante), la independencia de errores entre revisores, y la independencia organizativa de quien firma.
| Encuadre de la tarea | Independencia de errores | Independencia organizativa | |
|---|---|---|---|
| Instrucción crítica | sí | no por sí sola, un encargo, un juez | no |
| Orquestador de dos revisores | sí | una fase ciega, sin medir; el revisor arbitra | no |
| Conjunto de plataforma | sí | interna del proveedor, no expuesta | no, una herramienta no puede firmar |
| Casa humana | sí | un solo equipo | sí |
| CounterProof | sí | acotada y registrada, no medida: linajes de modelos separados, el encargo en el expediente, instancias correlacionadas o caídas no cuentan | sí: firmante con nombre, independiente del autor del código; intereses sectoriales declarados por escrito |
Un segundo modelo, elegido por usted, apuntado a lo que usted le muestra, juzgado por usted, no es un adversario. Es una segunda extracción de una distribución dentro de la cual usted ya está. De ahí se siguen tres brechas, y ninguna es un problema de calidad del modelo.
Brecha uno: otro proveedor no es un testigo independiente
Dos modelos de empresas distintas tienen datos de entrenamiento distintos, así que la coincidencia es corroboración y el silencio es tranquilidad; ese es el razonamiento. Un estudio sobre más de 350 modelos halló que cuando dos modelos se equivocan ambos, coinciden en la misma respuesta equivocada mucho más a menudo que el azar (una media del 60 % en una clasificación y del 42 % en la otra), con parejas de proveedores distintos incluidas en todo momento; su afirmación entre proveedores es una inferencia del modelo de regresión del estudio, no un análisis exclusivo de parejas de proveedores distintos (Kim et al., ICML 2025, arXiv:2506.07962). Midió bancos de pruebas y cribado de currículos, no revisión de vulnerabilidades, así que no le da a nadie la cifra de solapamiento para código; lo que establece es que proveedores distintos no son automáticamente independientes. Que eso deba cambiar cómo lee usted la coincidencia de un segundo revisor sobre su código es inferencia nuestra. Los estudiosos de textos hicieron de ese mismo punto una regla hace cinco siglos: una copia de la que se demuestra que desciende de otra copia conservada se elimina del cómputo, no porque sea errónea, sino porque no añade testimonio.
El canal de correlación que se pasa por alto no es el proveedor. Es el encargo: la instrucción, las herramientas, el paquete de evidencia y el encuadre del papel correlacionan a los revisores por encima de los proveedores, y dos modelos a los que se entrega el mismo paquete curado comparten todo lo que ese paquete omite. Tratamos el encargo como parte del aparato y lo archivamos con la revisión. El atacante puede usar cualquier modelo desarrolla qué autoriza esto y qué no.
Brecha dos: nadie decide cuándo no hay que pedir una opinión
Algunas afirmaciones tienen un oráculo, algo que las responde sin la opinión de nadie. ¿Se ejecuta este camino? Ejecútelo. ¿Permite la especificación este valor? Léala. Donde existe un oráculo, un test que se ejecutó supera a un modelo que razonó, y a una persona que razonó también.
Si se le pregunta a un agente revisor si una expresión regular casa con una ruta, producirá una opinión fluida sobre si la expresión regular casa con la ruta. Encaminar esa pregunta a una ejecución es una decisión de ingeniería y, según nuestra lectura, la mayoría del utillaje de revisión no la ha tomado, porque la categoría se compra por hallazgos por pull request, y un hallazgo que resulta ser un script de dos minutos no es un hallazgo. Conocemos la dificultad desde dentro: construimos una comprobación para imponer ese encaminamiento y la entregamos con su autotest definido y nunca invocado. Qué zanja un hallazgo es la autopsia.
Las afirmaciones sin oráculo (qué gravedad, si este supuesto de confianza es aceptable, si un atacante se molestaría) son juicio, y ningún volumen de salida de modelo convierte un juicio en un hecho.
Brecha tres: nadie ha firmado
Una ejecución interna de agentes (con cuantos modelos se quiera, por aislados que estén sus contextos) produce su propia palabra sobre su propio código, sin que nadie de fuera de su organización responda de una sola de sus frases. Según nuestra experiencia, esa es la propiedad que los abogados de un adquirente, el suscriptor de una aseguradora cibernética y el equipo de seguridad de un cliente corporativo piden primero, porque es la que su equipo no puede aportar sobre su propio trabajo.
Bajo el Cyber Resilience Act, la mayoría de los fabricantes pueden autoevaluarse y después se les exige cada registro que lo sostiene: informes de las pruebas realizadas, en la documentación técnica (anexo VII, punto 6), que acreditan el deber de realizar pruebas (anexo I, parte II, punto 3), conservados diez años o durante el período de soporte si es más largo (artículo 13, apartado 13). La notificación de vulnerabilidades explotadas activamente comenzó el 11 de septiembre de 2026; el Reglamento se aplica plenamente desde el 11 de diciembre de 2027. Una evaluación externa apoya el expediente que usted reúne; no es el expediente, y no somos un organismo notificado. Las normas pueden deslizarse, la fecha de notificación no trata el calendario.
Qué obtiene de nosotros
Nada de lo siguiente es un secreto. Un equipo bien llevado podría adoptar cualquiera de estos puntos. Lo que compra es que todos se hagan, se escriban y se firmen, como un expediente que puede entregar a alguien que no estuvo en la sala.
- Primero el oráculo. Una afirmación decidible se encamina a la ejecución, la compilación o la especificación antes de encargar ninguna opinión sobre ella. Nuestro utillaje de paquetes de revisión se niega a construir un encargo sin su paquete de evidencia, y el encargo dice qué no puede mostrar ese paquete, de modo que el silencio de una instancia sobre algo que nunca recibió se lea como silencio y no como ausencia.
- Las instancias son linajes, y el encargo está en el expediente. Los revisores son familias de modelos separadas; las instancias con acceso a ficheros construyen su propia evidencia desde el código fuente, las que no lo tienen leen solo lo que el encargo transporta. El encargo, las herramientas y el paquete que recibió cada una forman parte del expediente. Una instancia caída se registra como ausente, nunca como conformidad; una instancia que resulta compartir contexto con otra se marca y no se cuenta, incluida aquella vez en que una de las nuestras resultó tener nuestro propio documento de hallazgos en su contexto.
- Las devoluciones a ciegas se capturan antes de que exista un dictamen. Lo que dijo cada instancia, literalmente, con su envoltorio (modelo, arnés, fecha, ficheros abiertos) se anota antes de que nadie las compare.
- Un recuento nunca establece nada. Los hallazgos no se cierran por votación. Donde los revisores discrepan sobre qué hace el código, decide el código fuente; donde un rechazo descansa en «incierto», la afirmación pasa a una cola conservada con un responsable, un vencimiento y un criterio de reapertura, y se expone de nuevo a un linaje fresco. La confirmación sube por el peldaño de evidencia: rastro en el código fuente, prueba de compilación, test, reproducción en ejecución real, y para cualquier afirmación probabilística una tasa con intervalo y los registros de cada ensayo conservados; todo lo que se queda por debajo de un peldaño es solo plausible, la otra disposición y no un peldaño más débil. Una superficie examinada y hallada sólida se registra con el método que la examinó y con el control que mostró que ese método puede encontrar lo que buscaba.
- Una persona con nombre firma, y se retracta por escrito. Bajo un identificador que sus mantenedores y su adquirente pueden citar, incluso cuando el hallazgo era nuestro. Publicamos los casos en que fallaron nuestros propios instrumentos, porque una práctica que no puede mostrarle dónde se equivocó no tiene autoridad donde dice acertar.
Consultar varios modelos y quedarse con la mayoría es un conjunto; tal como se vende, no expone nada de esto al comprador. Cuando buscamos en septiembre de 2026 no encontramos ninguna práctica que ofrezca este paquete como un protocolo que un comprador pueda inspeccionar. Es una afirmación sobre la forma, no sobre la tasa de detección: de eso trata lo que le decimos antes de comprar, más abajo.
Dónde encaja esto en su gestión de vulnerabilidades
Encontrar no es donde ganamos nuestros honorarios. Los escáneres, los fuzzers, las plataformas de revisión y sus propios ingenieros ya producen candidatos más rápido de lo que nadie puede dictaminarlos, y nuestros encargos también encuentran cosas; ese es el subproducto. Aquello por lo que se nos paga está donde el ciclo de vida se rompe: el dictamen: un candidato se encamina primero a su oráculo y luego se gradúa por el peldaño de evidencia que alcanzó, de modo que la gravedad sigue a la prueba y no a la confianza de un modelo; el cierre: la discrepancia la zanja el código fuente, no una votación, y «incierto» se mantiene en una cola conservada con un responsable en lugar de convertirse calladamente en «aceptado»; y la garantía: el resultado es un expediente que una persona con nombre ajena a su organización ha firmado y puede retirar, esa parte de un expediente técnico, de un paquete de diligencia debida o de una solicitud de aseguramiento que usted no puede producir sobre su propio trabajo. Sitúenos en la identificación y competiremos con su escáner en volumen, una carrera que no corremos. Sitúenos donde un hallazgo se convierte en una decisión que alguien deberá justificar después, y el expediente es el producto. Un hallazgo no es un veredicto cubre la primera etapa y Qué zanja un hallazgo la mitad decisiva de la segunda; la cola conservada se describe más arriba. Gestión de vulnerabilidades bajo el Cyber Resilience Act recorre cada etapa con el deber del CRA en cada una.
Qué le decimos antes de comprar
Esto le protege a usted, así que está en la página y no en el contrato.
- Vendemos un expediente, no una tasa de detección. No hemos demostrado que un panel encuentre más defectos reales que un solo buen revisor, y no lo afirmamos; medimos nuestro aparato completo frente a una sola pasada económica, preregistrado y puntuado a ciegas, y no ganó con claridad en ninguna de las dos dianas: perdió una y, en la otra, activó su propio umbral de precisión solo eliminando los hallazgos que el auditor había dictaminado reales. Medimos nuestro propio método, y no justificó su coste. El informe de caso del que partimos dice que una doctrina más sencilla (una revisión externa independiente sobre todo aquello sobre lo que vaya a actuar, las disputas zanjadas leyendo el código fuente, ninguna cifra sin medir publicada) encaja con la misma evidencia; si es lo único que se lleva de esta página, lléveselo. Lo que vendemos es el expediente de haberlo hecho, bajo una firma. La independencia entre nuestras instancias está acotada por el procedimiento y registrada, pero no medida para la revisión de código; nadie la ha medido. Cada hallazgo del expediente alcanzó un peldaño con nombre o está marcado como no haberlo alcanzado.
- Dónde está el autor dentro del circuito. Nuestra regla es que quien planteó una afirmación en disputa no la dictamina en solitario. Nuestro banco de revisión son dos personas, lo que significa menos encargos, rechazar trabajo fuera de nuestro ámbito, y que esta regla todavía no tiene mecanismo alguno que la imponga; nuestro propio informe de caso señala esa ausencia como su mayor debilidad sin corregir. En la práctica, una afirmación en disputa pasa por el código fuente y por un linaje fresco antes de cerrarse, el dictamen se registra y el firmante está nombrado, de modo que usted puede ver qué hallazgos se cerraron así y sopesarlos por su cuenta.
- Ningún método alcanza un defecto que ningún testigo planteó. El cotejo solo elige entre lo que se emitió. Los tests, el fuzzing, las pruebas formales y la lectura de un especialista son rutas distintas al mismo sitio, y un programa serio también las usa.
- Somos independientes del autor de su código, no desinteresados en todos los sectores. CounterProof forma parte de un grupo que construye infraestructura de pagos y de custodia de activos digitales. Si usted construye en esos mercados, nuestra filial puede ser vecina suya o competir con usted. Le decimos por escrito qué construye el grupo y dónde opera antes de cualquier encargo y antes de que se mueva dinero, y no emitimos evaluación alguna sobre código escrito por CounterProof o por cualquier empresa de nuestro grupo.
La argumentación extensa, con sus propios límites, es nuestro documento de trabajo, una preimpresión no revisada por pares: research.counterproof.io (doi:10.5281/zenodo.22030516).
Preguntas que nos hacen
¿Es la revisión de código adversarial lo mismo que una prueba de penetración? No. Una prueba de penetración ejercita un sistema en funcionamiento; esto lee código fuente en un commit fijado y establece hallazgos contra el código. Ambas piensan desde el atacante, responden a preguntas distintas, y un programa serio usa las dos.
¿No puedo simplemente pasar dos modelos de IA sobre mi propio código? Puede hacerlo, y un segundo revisor quizá saque a la luz candidatos que el primero no vio. Lo que no puede producir es independencia organizativa: su equipo elige qué ven los revisores, formula las preguntas y juzga las respuestas, y nadie de fuera ha firmado.
Una plataforma de revisión ya ejecuta varios modelos. ¿No es eso un panel? No. Un conjunto cuyos modelos elige el proveedor, cuyas devoluciones individuales usted no puede ver y cuyas discrepancias se resuelven dentro de la tubería es un instrumento con varias piezas. Un panel son varios instrumentos cuyas devoluciones se registran por separado y cuyas discrepancias las zanja el código fuente.
¿La revisión de código adversarial solo se aplica al código generado por IA? No. Al método le da igual quién (o qué) escribió el código. El código escrito por una máquina solo hace la brecha más difícil de ignorar, porque el volumen sube y la fluidez esconde las conjeturas.
¿En qué se diferencia esto de una herramienta de revisión de código con IA? Esas herramientas generan hallazgos, y nosotros usamos herramientas de esa clase como instrumentos. Lo que una herramienta no puede hacer es responder de lo que dice ni firmar.
Las inferencias señaladas como tales más arriba, y aquí: que la coincidencia de un segundo revisor sobre código deba descontarse (Kim et al. midieron otros dominios); que el encargo correlaciona a los revisores; que las cuatro prácticas son la forma del mercado y que el utillaje de revisión compite por hallazgos por pull request (nuestra lectura, una búsqueda, septiembre de 2026); que la independencia organizativa es lo que adquirentes, aseguradoras y compradores corporativos piden primero (nuestra experiencia, no una encuesta). Si algo aquí es incorrecto, lo corregiremos por escrito en esta página.