revisión de código adversarial independiente
CounterProof es una práctica de revisión adversarial independiente para bases de código modernas — el código escrito por máquinas, ante todo. Entregamos lo único que usted no puede producir en casa: una evaluación de seguridad independiente, firmada, graduada por nivel de evidencia, construida para el escrutinio de reguladores, compradores, aseguradoras y clientes corporativos.
Un código escrito por un modelo y revisado por el mismo modelo no ha sido revisado por nadie.
Háblenos antes de que lo haga el plazo →Nadie compra una revisión de código. Se compra lo que desbloquea.
Usted no está leyendo esto porque se haya despertado queriendo una evaluación de seguridad. Algo le está pidiendo evidencia.
Tres de estos cuatro nunca aceptan su palabra sobre su propio código — la independencia es la propiedad que compran, y es la única propiedad que ningún equipo puede suministrar sobre su propio trabajo. El cuarto, el regulador, aceptará a menudo su autoevaluación — y luego le exigirá cada registro que la sustenta. En ambos casos, la evidencia tiene que sostenerse. Eso es lo que producimos.
Dónde encaja la revisión en su gestión de vulnerabilidades, etapa por etapa →
El entregable es la cuestión.
Un encargo produce una CounterProof Assessment bajo un identificador de encargo persistente (CPR-YYYY-NNN — lo que citan sus mantenedores, su comprador o sus commits de corrección). Cada hallazgo se confirma contra su código fuente — fichero y línea exactos, ruta de reproducción, clasificación de impacto — o se gradúa explícitamente como solo plausible. Nada de relleno, nada generado por escáner, nada sobre lo que no pueda actuar. El expediente también deja constancia de lo que comprobamos y no encontramos: un negativo registrado es aquí un entregable, no un encargo fallido.
Cada hallazgo nombra el peldaño de evidencia que alcanzó realmente — traza en el código fuente, prueba de compilación, test o reproducción en ejecución — y nunca insinúa uno superior. Cada cita ruta:línea se resuelve mecánicamente contra la revisión exacta que revisamos antes de que el informe salga de nuestras manos. Puede comprobar nuestro trabajo. Es deliberado.
Cuando un hallazgo no supera el escrutinio — el suyo, el de sus mantenedores o nuestro propio reexamen — lo retractamos por escrito, con la razón, bajo el mismo identificador de encargo. Lo hacemos sin que nadie lo pida; la contraparte no tiene que solicitarlo. El registro de retiradas no es una admisión; es el mecanismo.
Espécimen — la forma de un hallazgoEspécimen ilustrativo, no procedente de un encargo de cliente; los identificadores son marcadores. Los informes se emiten en inglés.
«Los testigos ahora son gratis. La edición crítica no lo es.»
El mercado ha empezado a competir en cuántos hallazgos puede generar una herramienta — pero un hallazgo es un testigo, no un veredicto. Una cita fichero:línea puede abrirse y comprobarse en un minuto; un simple «Crítico», no. En nuestros expedientes, la gravedad es un resultado del grado de evidencia, nunca un insumo del marketing. Los testigos ahora son gratis. La edición crítica no lo es. Un hallazgo no es un veredicto →
Cuatro pasos. Conoce el alcance antes de pagar, y conserva el expediente después.
Un primer encargo no tiene que abarcar todo lo que usted entrega. Un alcance pequeño y bien elegido — un módulo, una frontera de confianza — produce el mismo expediente defendible en un tamaño que puede evaluar, y puede ser la primera pieza de evidencia de la parte II, punto 3), que un fabricante presenta.
La fluidez no es señal de calidad. Es el modo de fallo.
Cuando una persona escribe una línea de código, duda de ella. Sabe que estaba adivinando — y esa duda es un dispositivo de seguridad, porque es lo que la lleva a ir a probar la cosa.
Un modelo escribe la misma línea con fluidez, precisamente con la voz que usa para las líneas que son correctas. Para quien lee, la fluidez se lee como competencia. Un ingeniero junior le entrega algo visiblemente tosco y usted lo comprueba. Un modelo le entrega doscientas líneas pulidas con una razón segura para cada una, y usted no lo hace.
La trampa no es que los modelos se equivoquen más a menudo que las personas. Es que sus respuestas erróneas llegan con la misma voz que las correctas — indistinguibles desde fuera, porque son indistinguibles desde dentro.
Luego el mismo proceso escribe el test que certifica el código, y el comentario que lo explica. Los tres concuerdan, porque los tres salieron del mismo sitio. Esa concordancia se lee como tres confirmaciones independientes. Es una.
«Sus respuestas erróneas llegan con la misma voz que las correctas.»
Así que la pregunta útil no es si un modelo puede escribir buen código — puede, con un método alrededor. Es qué está midiendo realmente su proceso de revisión cuando todo lo que inspecciona salió de la misma fuente: el código, el test, la explicación y, cada vez más, la herramienta que usted construyó para comprobarlos. Bien hecho, el resultado es bueno. Mal hecho, se lee exactamente igual.
Una revisión encuentra lo que su revisor puede encontrar.
Pase un modelo sobre una base de código y un informe breve le dice algo estrecho: ese modelo, en ese arnés, ese día, sacó a la superficie esto. Lo que no sacó no está en el informe, y por construcción no puede estarlo.
Cuánto importa eso depende de cuánto se solapen los puntos ciegos de distintos revisores — lo cual, para la revisión de código, nadie ha medido. La investigación sobre errores correlacionados, en poblaciones de modelos que incluyen distintos proveedores, encontró un solapamiento sustancial en bancos de pruebas de opción múltiple y en una tarea de cribado de currículos; que eso se traslade a encontrar vulnerabilidades no está establecido. Lo que sí muestra: proveedores distintos no son automáticamente independientes entre sí.
Varias cosas pueden acotar lo que una sola pasada omitió: una prueba formal, una suite de tests, un fuzzer, un especialista, defectos sembrados, o un revisor distinto del primero. Lo que no puede acotarlo: leer la misma pasada con más confianza.
No hemos demostrado que la revisión multi-revisor atrape más defectos reales — el experimento que diseñamos para comprobarlo se retiró antes de ejecutarse, y lo decimos públicamente. El punto más estrecho es el que defendemos: una pasada limpia de un revisor es un resultado delimitado, y leerla como certificado de limpieza es una inferencia que ese resultado no sostiene. El argumento completo (en inglés) →
Hemos dejado el argumento largo por escrito, incluido dónde están los límites de nuestro propio método y lo que no hemos demostrado: una introducción en lenguaje llano, y el artículo completo detrás de ella, publicado como preprint bajo doi:10.5281/zenodo.22030516 (CC BY 4.0), en inglés. No está revisado por pares, y lo dice.
Usted podría ejecutar los mismos modelos. No puede ser independiente.
Pasar varios modelos de IA sobre su propio código replica nuestras herramientas y pierde la propiedad que importa. Su equipo elige lo que ven los revisores, encuadra las preguntas y juzga las respuestas — y cada una de esas decisiones devuelve sus supuestos directamente a la revisión. No es un fallo de disciplina; es estructural. El autor de un sistema no puede ser su propio árbitro.
Incluso una revisión interna impecable sigue siendo su palabra sobre su propio código. Lo que ellos compran es un tercero dispuesto a firmar. No somos un organismo notificado y no certificamos conformidad; producimos la evidencia independiente que apoya su evaluación y que está estructurada para ser reexaminada por la de cualquier otro.
Al método le da igual quién — o qué — escribió su código. La independencia falta en el código escrito por humanos con la misma frecuencia. El código escrito por máquinas solo hace que la brecha sea imposible de ignorar.
Lo descubriría de todos modos. Mejor que lo oiga de nosotros.
CounterProof forma parte de un grupo que construye infraestructura de pagos y de custodia de activos digitales. Ahí se forjó este método — y significa que, si usted construye en esos mercados, nuestra filial puede ser adyacente a usted, o competir con usted.
Así que: antes de cualquier encargo, le decimos por escrito exactamente qué construye el grupo y dónde opera. Usted decide si eso es aceptable, y lo decide antes de habernos pagado nada. Si no es aceptable, es una respuesta legítima y preferimos oírla al principio.
Lo que nuestra afirmación de independencia cubre y no cubre, con precisión: no emitimos evaluación alguna sobre código escrito por CounterProof o por cualquier empresa de nuestro grupo. Ese límite es estructural. Es una afirmación sobre el código de quién revisamos, no la pretensión de no tener intereses comerciales en ninguna parte cerca de su sector. Los nuestros están nombrados arriba, y usted decide si son aceptables antes de habernos pagado nada.
Tres personas, con nombre, en el expediente.
Una evaluación firmada significa que el nombre de alguien está en ella. Estas son las personas — y qué nombre lleva qué.
Somos una práctica familiar — padre, hijo e hija — y el banco de revisión lo forman dos personas. Ambos son hechos que un equipo de due diligence descubre por sí solo, así que preferimos decirlos aquí: un banco de dos revisores acepta menos encargos que una firma, declina todo lo que queda fuera de su dominio y no puede esconder una pasada floja detrás de una marca. Ese es el intercambio, y es la razón por la que el método está escrito y mecanizado en lugar de llevarse en la cabeza de alguien.
Lo que estamos leyendo, y lo que estamos comprobando.
Modelos de otros proveedores ayudaron a escribir, seleccionar y juzgar los datos de entrenamiento de Kolibri-1. El resumen europeo enumera siete nombres; el informe técnico explica las distintas funciones. Estas divulgaciones muestran cómo un modelo construido para un despliegue soberano y especializado puede apoyarse en modelos de otros proveedores durante el entrenamiento. No establecen qué comportamientos, si alguno, se heredaron.
De doce configuraciones de agente, la que más veces produjo código que funcionaba lo hizo en el 57 % de las tareas; solo en el 11,8 % su código funcionó y además superó el test de seguridad. Informar al agente del riesgo ayudó un poco. El estudio pudo comprobar la presencia de cada fallo porque ya se había encontrado y corregido, y la corrección venía con un test de seguridad. El código nuevo de su agente todavía no tiene un test así.
El Reglamento nunca menciona los monederos cripto. Se aplica a los productos con elementos digitales. Desde diciembre de 2027, exige además exámenes y pruebas eficaces y periódicos de la seguridad del producto. Según nuestra lectura, ese deber incide en si un fabricante encuentra un fallo antes que un atacante. Esta nota explica el ámbito de aplicación, los plazos de notificación y el papel de una revisión independiente.
Háblenos antes de que lo haga el plazo.
Las solicitudes de información van a Elenora Soons, gestora de cuentas: