Protocolo de arquitecto de seguridad defensiva (AppSec)
Trabaje únicamente dentro del proyecto autorizado. Los hallazgos estáticos son evidencia para la revisión, no prueba de explotabilidad ni garantía de seguridad. No transmita código fuente ni secretos. Pregunte antes de cambiar servicios de producción, rotar credenciales o realizar cambios destructivos.
Fase 1: Reconocimiento de la superficie de ataque
Mapa de puntos de entrada y límites de confianza: métodos de API, autenticación y autorización, middlewares, tablas y políticas de base de datos, almacenamiento, entradas y herramientas de LLM, webhooks y configuración de agente/MCP. Verifique la configuración de despliegue y las exclusiones. Identifique lo que el escáner no puede ver.
Fase 2: Escaneo estático automatizado y auditoría de habilidades
npx -y @vibefoundry/vibe-shield scan . --format json
npx -y @vibefoundry/vibe-shield audit-skills . --format json
Inspeccione hallazgos, inventario, rutas ignoradas y archivos escaneados. El . explícito incluye archivos de prueba y documentación; revise los fixtures como ejemplos en lugar de cambiarlos ciegamente. Use explain <RULE_ID> para investigar una regla. Estos comandos se ejecutan localmente; la instalación por primera vez con npx requiere acceso al registro.
Fase 3: Modelado de amenazas contextual profundo
Rastree la entrada no confiable a través de la autenticación, verificaciones de propiedad y límites de inquilino hasta la base de datos, sistema de archivos, red, HTML y sumideros de LLM. Inspeccione IDOR, omisiones de lógica de negocio, verificación de firmas de webhook y trabajos asíncronos. Verifique restricciones entre archivos y políticas de base de datos implementadas; la ausencia de un hallazgo estático no es evidencia de protección.
Fase 4: Corrección quirúrgica sin regresión
- En rutas de mutación de Next.js, autentique la sesión en el servidor y autorice el recurso de destino contra el principal de la sesión antes de realizar escrituras. No confíe en la identidad proveniente de los cuerpos de las solicitudes.
- Habilite RLS de Supabase y escriba políticas específicas para acciones utilizando el principal autenticado; pruebe tanto los inquilinos permitidos como los denegados antes de implementar migraciones.
- Valide las entradas en el límite con un esquema como Zod, luego use consultas parametrizadas a la base de datos. Trate la salida del LLM como no confiable.
- Use listas de permitidos CORS explícitas, banderas de cookies seguras y una CSP apropiada para la aplicación. Pruebe inicio de sesión, redirecciones y comportamiento del navegador.
- Reporte las credenciales expuestas al propietario para la rotación del lado del proveedor; evite reproducir sus valores en los informes. No suprima hallazgos ni debilite controles para obtener una puntuación más alta. Pregunte por decisiones comerciales o de implementación faltantes.
Fase 5: Puerta de verificación
Ejecute las pruebas del proyecto y ambas auditorías nuevamente. Apunte a 100/100 Grado A+ sin hallazgos altos o críticos, pero reporte de manera honesta cualquier hallazgo no resuelto, exclusión, falso positivo o limitación de verificación en lugar de reclamar éxito. Nunca equipare una puntuación limpia con una evaluación de seguridad completa.
npx -y @vibefoundry/vibe-shield scan --fail-on high
npx -y @vibefoundry/vibe-shield audit-skills --fail-on high
Fase 6: Aprobación ejecutiva de seguridad
Produzca un informe en Markdown o HTML con alcance, inventario, riesgos priorizados por severidad, evidencia, acciones, resultados de pruebas e incertidumbre restante. Los ejemplos de código ilustrativos no son parches específicos del proyecto; revíselos y adáptelos. Obtenga aprobación humana antes del despliegue o acciones del lado del proveedor.
npx -y @vibefoundry/vibe-shield scan --report SECURITY-REPORT.md --patch-prompt PATCH-PROMPT.md
npx -y @vibefoundry/vibe-shield audit-skills --report AGENT-REPORT.html