// AUTO-AUDITORÍA
Cómo nos testeamos a nosotros mismos
La transparencia continua vale más que cualquier claim de cero falsos positivos. Estos son problemas reales que encontramos en nuestro propio producto, corregimos y re-verificamos, descritos sin detalle explotable.
Atajos de laboratorio en el camino de escaneo real
Revisando el motor encontramos rutas pensadas para laboratorios de prueba conocidos que seguían activas en el escaneo real. No afectaban a clientes ni a los benchmarks que publicamos (Broken Crystals, VAmPI y NodeGoat), pero podían hacer que el motor pareciera mejor en esos laboratorios concretos de lo que es en una app desconocida. Las quitamos del escaneo real en cinco lotes; ahora solo existen en los scripts de benchmark, separados.
Un fallo de login que el informe no contaba
Si el scan no conseguía iniciar sesión en la app objetivo, el informe no lo decía con claridad y podía parecer que había cobertura donde no la hubo. Ahora el informe muestra un aviso de AUTENTICACIÓN FALLIDA que no se puede ocultar.
Un informe que decía más de lo que había
El gráfico de severidad podía mostrar "1 hallazgo" con cero hallazgos, y el impacto de negocio de las cabeceras de seguridad aparecía aunque no faltara ninguna. Ahora el informe solo narra riesgos detectados, y el aviso de scan superficial tiene un color propio, más visible.
El registro revelaba si un email ya tenía cuenta
La respuesta del registro público era distinta para un email nuevo y para uno ya registrado. Ahora ambas respuestas son idénticas.
Aislamiento entre organizaciones y peticiones del servidor
Al cerrar la pestaña, un scan podía quedarse marcado como en curso porque la limpieza no llevaba la organización correcta. Y la verificación del inicio de sesión con SSO hacía dos peticiones de servidor sin pasar por nuestro filtro de destinos internos. Ambas corregidas, con tests.
Un módulo secundario con controles más débiles que el principal
Un módulo secundario no aplicaba la misma comprobación de plan, de propiedad del dominio y de cuota que el pentest principal. Lo detectamos en una revisión interna y ahora aplica los mismos controles.
Un control de parada que no paraba nada
Lanzamos un control para detener un scan en curso a mitad del ataque. Al probarlo en vivo contra un target real, el botón no respondía. Lo rastreamos a una regla de estilo que deshabilitaba en silencio todo el panel de control mientras un scan estaba activo: el botón era visible pero inerte. Corregido y re-verificado el mismo día contra un scan en vivo.
Un canal en vivo que perdía mensajes en silencio
Nuestro puente interno de eventos se reconectaba cada 5 segundos sin lanzar ningún error: los mensajes publicados durante la brecha se perdían en silencio, alrededor del 40% del tiempo. Nuestro primer intento de fix detuvo el bucle visible de reconexión, pero nuestro propio monitoreo detectó que dejaba el canal colgado en silencio tras cualquier caída. Revertimos y lanzamos una versión que comprueba activamente que sigue vivo, en lugar de solo vigilar desconexiones.
Dos marcas de tiempo, un solo reloj
Un proceso en segundo plano registraba el inicio y fin de un scan como el mismo instante exacto, ambos capturados al guardar el registro, no cuando el scan realmente empezaba o terminaba. Corregido para que cada marca de tiempo se capture una sola vez, en el momento en que realmente ocurre.
Nuestro propio reporte de muestra se contradecía
Una línea decía que coincidía exactamente con el formato de reporte de producción; otra, en el mismo documento, admitía que ese formato aún no estaba listo. Detectamos la contradicción nosotros mismos, corregimos el copy para que fuera preciso, y estamos siguiendo el fix real (generar muestras desde el mismo motor que usa producción) como trabajo de ingeniería aparte.
Un formulario que registraba más de lo debido
El formulario de solicitud de demo de nuestro propio sitio de marketing no tenía rate limiting y escribía nombres completos, emails y nombres de empresa en logs en texto plano. Añadimos rate limiting y rehicimos el logging para conservar solo lo necesario para depurar, no los datos de contacto de las personas.
Una página de estado que nunca podía decir que algo fallaba
Nuestra página de estado pública siempre mostraba "Operational", una cadena estática, no una comprobación real. La reemplazamos por un health check en vivo del lado servidor contra la misma señal de liveness que usa nuestro propio motor.
Esto es una instantánea estática, no un feed en vivo, con fecha 25 de septiembre de 2026.