47 checks de seguridad en lenguaje simple
- Cliente
- Supersônica
- Sector
- SaaS de seguridad
- Período
- 2026
Stack
- Next.js
- TypeScript
- Supabase
- Nuclei
- Inngest
- Stripe
- AWS EC2
- Vercel
El desafío
Los sitios hechos con IA llegan a producción sin revisión de seguridad, y un escáner tradicional responde en un formato ilegible para quien los construyó.
Lo que construimos
Un SaaS que ejecuta 47 verificaciones contra una URL pública, descubre endpoints ocultos rastreando bundles de JavaScript, ajusta las pruebas al stack detectado y devuelve cada hallazgo en lenguaje simple con un prompt de corrección listo para pegar.
Resultados
- Verificaciones de seguridad por escaneo
- 47
- Pruebas automatizadas en el repositorio
- 1.200
- Primer pago real en producción
- 30/04/2026
Este es un producto del propio estudio, no un trabajo entregado a un cliente. Supersônica diseñó, construyó y opera SecureMyVibe. Está en producción, en desarrollo activo, y es el caso en el que podemos abrir todos los números sin pedirle permiso a nadie.
El problema
Las herramientas de vibecoding ponen un sitio en producción en una tarde. Quien publica rara vez es quien sabe qué es Row Level Security, qué permite una cabecera de seguridad ausente, o por qué una ruta de API que devuelve datos de usuario sin exigir login es un incidente con fecha pendiente. El sitio abre, responde, tiene el formulario funcionando: entonces parece terminado.
Los escáneres de seguridad ya existen, y son el segundo problema. El resultado de una herramienta como Nuclei es una lista de identificadores de plantilla y niveles de severidad: perfectamente legible para quien ya trabaja en seguridad, inútil para quien construyó el sitio conversando con un modelo. El diagnóstico llega y no se convierte en corrección, lo que en la práctica equivale a no haber llegado.
La intervención
SecureMyVibe ejecuta 47 verificaciones contra una URL pública — 46 plantillas Nuclei más un probador de endpoints — con cobertura del OWASP Top 10. Antes de probar, descubre la superficie real: un crawler recorre los bundles de JavaScript en busca de rutas de API que no aparecen en ningún enlace, y cada ruta encontrada se sondea para detectar autenticación ausente con peticiones de solo lectura.
Dos decisiones definieron el producto.
La primera es que el escaneo es consciente del stack. Identificada la plataforma, entran plantillas condicionales: reglas de Row Level Security en Supabase, reglas de seguridad en Firebase, server actions en Next.js. Un escaneo genérico gasta la atención del usuario en ruido; este reporta lo que ese stack expone específicamente.
La segunda es el informe, y es la que define el producto. Cada hallazgo se reescribe en lenguaje directo — "tablas de Supabase accesibles usando solo la clave pública, sin Row Level Security habilitado" en lugar de un identificador de plantilla — y viene con un prompt de corrección listo para pegar de vuelta en la herramienta que generó el sitio. El ciclo cierra donde el usuario ya está, en vez de terminar en un PDF que no sabe ejecutar.
La infraestructura acompaña esa decisión: Next.js y Supabase en Vercel, el escáner aislado en EC2 porque un barrido de red no comparte proceso con una aplicación web, Inngest orquestando los trabajos asíncronos y Stripe en el pago. El informe sale en tres idiomas.
El resultado
El producto está en producción y tuvo su primer pago real validado el 30 de abril de 2026. Detrás de él hay 1.200 pruebas automatizadas: 639 en la aplicación web y 561 en el escáner.
Ese último número es el que más nos interesa como estudio, y no es vanidad de cobertura. Un escáner de seguridad que se equivoca es peor que ningún escáner — un falso negativo le da el alta a un sitio vulnerable y además le entrega a su dueño la confianza de que todo está bien. Las 561 pruebas del escáner existen para que cada uno de los 47 checks siga significando exactamente lo que dice que significa después de cada cambio. Es la parte del trabajo que el cliente nunca ve y sin la cual el informe no podría tomarse en serio.