Seguridad
Cuando la seguridad es un informe que llega después de que la feature está lista, se convierte en una lista de retrabajo — y la mitad que da demasiado trabajo se posterga para siempre. En Spaccy entra donde todavía es barata: en el diseño, en el código, en la aplicación en ejecución y en la puerta del release.
Vale para tu producto: las etapas siguientes corren contra tu repositorio y tu aplicación, con las herramientas de análisis que ya usas.
Antes de que exista código
Un fallo de diseño descubierto en producción cuesta órdenes de magnitud más que el mismo fallo señalado en la propuesta. Estas tres etapas corren cuando la feature todavía es solo texto.
Recorre el flujo de datos de la feature elemento por elemento aplicando STRIDE — suplantación de identidad, alteración, repudio, divulgación de información, denegación de servicio y elevación de privilegios — y añade la mirada de riesgos específicos de sistemas con agentes. El resultado no es un documento que se queda quieto: se convierte en un criterio de aceptación de la propia feature, con referencia al control ASVS correspondiente.
/threat-model
La evaluación de impacto de privacidad corre con el método LINDDUN sobre los flujos de dato personal de la feature, con referencia a GDPR e ISO 27701. Es la diferencia entre descubrir en la revisión legal que la feature guarda más de lo que debería y haberlo decidido en el diseño — cuando todavía cuesta una línea.
/dpia
A partir de los casos de uso que ya documentaste, deriva los casos de abuso: el mismo flujo, visto por quien quiere romperlo, actor por actor. Sale lo que nadie escribe porque nadie tiene tiempo — y es justo ahí donde viven los incidentes.
/abuse-cases
Sobre el código y sobre la aplicación
Audita el diff pendiente o un directorio y mapea cada hallazgo al control ASVS 5.0 y a la entrada correspondiente del OWASP Top 10 — no a una taxonomía propia que solo existe aquí. Cada hallazgo llega con la referencia que tu equipo ya usa para priorizar.
/security-review
Lo que el análisis estático no ve: la aplicación viva respondiendo. Cabeceras de seguridad, inyección, cross-site scripting y, en el nivel más alto, acceso indebido al objeto de otro usuario y fallos de autenticación. Report-only por diseño: señala y propone, no modifica.
/dast
En la puerta del release
La decisión de liberar o bloquear un release no debería depender de que alguien haya leído un informe un viernes por la tarde.
El gate devuelve un código de salida: cero libera, distinto de cero bloquea. Eso es lo que lo hace utilizable en un paso de CI — ninguna etapa de tu pipeline necesita interpretar prosa para decidir si el release pasa.
No descubre nada nuevo en el momento del release, y es a propósito: un gate que ejecuta análisis es un gate lento y no determinístico. Este lee los artefactos que las etapas anteriores produjeron y decide. Ejecutarlo dos veces da el mismo resultado.
Cada motivo de bloqueo tiene su propio código y una salida obvia: falta el modelo de amenazas, hay un hallazgo crítico abierto en el escaneo, hay una pendiente de seguridad crítica sin resolver. Nadie tiene que adivinar por qué se detuvo el release.
En el nivel de rigor más ligero, y por defecto, el gate informa y deja pasar: bloquear el release es comportamiento del nivel estricto, para cuando el proyecto — o la feature — lo pide. Tú eliges cuándo se cierra el candado; mira cómo se dosifica el rigor.
# en el paso de CI, antes del deploy:
$ /security-gate --tier strict --json
# exit 0 → libera · exit ≠ 0 → bloquea, con el motivoLo que amarra todo
Spaccy orquesta las herramientas de análisis que ya existen y son mejores que cualquier cosa que hiciéramos desde cero — incluido el revisor de seguridad oficial de Anthropic, que entra como motor conectable. Lo que el producto añade es lo que falta en el mercado: integración, dosificación por riesgo, seguimiento y gate.
Los hallazgos de orígenes distintos se normalizan en SARIF, el formato estándar de resultado de análisis estático. Eso significa que el mismo hallazgo es legible por tu editor, por tu interfaz de code review y por el gate — sin que cada herramienta hable su propio dialecto.
Cada hallazgo entra en el mismo registro de pendientes que el resto del trabajo, marcado como seguridad, con severidad y dueño. No existe un backlog paralelo que solo abre el equipo de seguridad — la vulnerabilidad compite por prioridad en el mismo lugar que la feature.
La profundidad sigue el nivel de rigor del proyecto: en el más ligero, foco en secretos y autenticación; en el estándar, análisis estático completo; en el estricto, cadena de suministro, infraestructura como código y el checklist ASVS más alto. Lo que el nivel nunca hace es volver un escaneo menos correcto — solo reduce lo que mira.
Solicita acceso anticipado y modela amenazas en la feature que estés diseñando antes de que exista código.