MagSolutionsAICuántas veces nos equivocamos
Todo escáner de seguridad produce falsos positivos. Casi ninguno publica cuántos. Este es el nuestro, y se deriva de las pruebas de regresión — nunca se escribe a mano.
Por qué no lo hace nadie más. Una empresa con 17.000 clientes no puede empezar a decir «el 15 % de nuestros comentarios son ruido», aunque una auditoría independiente ya lo haya medido. Sus clientes preguntarían y sus inversores también. Es una posición que solo sostiene quien todavía no tiene nada que perder — y deja de poder sostenerla el día que lo tiene. Por eso la construimos ahora, mientras aún podemos.
Las cifras
| Qué | Valor | De dónde sale |
|---|---|---|
| Correcciones fijadas por una prueba de regresión | 83 | Contadas del fichero de pruebas. Si alguien borra una, el número baja solo |
| Repositorios públicos citados como origen de una corrección | 21 | Cada prueba lleva un comentario owner/repo#PR que puedes abrir |
| Pull requests analizados en los barridos semanales | 1246 | 5 barridos, del 2026-09-04 al 2026-09-14 |
| Dependencias resueltas contra los registros en vivo | 1583 | PyPI y npm, en el momento en que se abrió el pull request |
| Pull requests en los que dijimos algo | 6.4 % | El 93,6 % restante recibió un check limpio y ningún comentario |
| Paquetes alucinados confirmados | 0 | De 10 candidatos 404 en bruto, todos resultaron ser falsos positivos nuestros al revisarlos |
Cifras congeladas en el último despliegue. Esta página intenta refrescarlas en vivo desde nuestro endpoint público; si falla, estás leyendo la copia congelada.
La primera pasada fue pésima, y ese es el argumento
La primera vez que el detector corrió contra 249 pull requests públicos reales produjo 150 hallazgos, 79 marcados como críticos. Los revisamos todos a mano. Casi ninguno era real.
Sobre la misma población, tras las correcciones: 39 hallazgos, de cero a un crítico. La diferencia son las 83 pruebas, y cada una existe porque nos equivocamos sobre el código de otra gente.
Uno reciente, para que veas la forma que tienen. El 17 de septiembre
de 2026, una auditoría de 6.000 ficheros de librerías ya publicadas — google-auth, numba,
torch, kubernetes — encontró cuatro hallazgos en nuestro escaneo de instalación. Los
cuatro eran falsos. Tres eran lo mismo: un comentario que documentaba el formato
PEM, # "-----BEGIN PRIVATE KEY-----...", reportado como clave privada.
Sobre el mismo corpus hoy: cero. Y una clave de verdad comentada sigue
saltando — esa prueba de regresión también existe.
Compruébalo tú mismo
No «créenos». Esto se abre sin cuenta:
- El corpus — las 83 pruebas, cada una con la línea exacta y el pull request del que salió.
- El instrumento — cómo medimos el ruido contra pull requests públicos reales.
- Cómo verificarlo — incluido por qué ninguna de las cadenas con forma de credencial del corpus es real.
- El registro en crudo y las cifras de campo en vivo.
Tres formas de comprobarlo, de menor a mayor esfuerzo: abrir un pull request
citado y buscar la línea; contar las funciones def test_
y compararlo con la cifra de arriba; o instalar la App en un repositorio de usar y
tirar, pegar esas líneas en un pull request y ver si se comporta como dice la prueba.
Lo que esta página no afirma
- No es una tasa de falsos positivos en sentido estadístico. Es un recuento de correcciones y la población en la que se encontró cada una. No afirmamos un porcentaje que no podríamos defender.
- El corpus es nuestro. Nosotros elegimos qué mirar. Una auditoría independiente valdría más, y también la publicaríamos.
- Cero paquetes alucinados confirmados es un resultado real, no uno bueno. Significa que la frecuencia base en pull requests corrientes es muy baja. Lo publicamos porque debilita en parte uno de nuestros propios argumentos.
- Nos hemos equivocado en este mismo registro. El 16 de septiembre informaba de 10 paquetes alucinados cuando la verdad era 0: se había etiquetado el recuento de 404 en bruto como confirmados. Se detectó leyendo la salida en vivo, se corrigió el mismo día y quedó fijado por una prueba. Está en el historial de git.
Publicamos esto porque a un proveedor de seguridad que te pide acceso a tus repositorios no deberías creerle por su palabra. Si encuentras algo en esta página que no se sostiene, dínoslo y se corrige aquí, con la fecha.