Segurança
Quando a segurança é um relatório que chega depois de a feature estar pronta, ela vira lista de retrabalho — e a metade que dá trabalho demais é adiada para sempre. No Spaccy ela entra onde ainda é barata: no desenho, no código, na aplicação rodando e na porta do release.
Vale para o seu produto: as etapas abaixo rodam contra o seu repositório e a sua aplicação, com as ferramentas de análise que você já usa.
Antes de existir código
Uma falha de desenho descoberta em produção custa ordens de grandeza mais do que a mesma falha apontada na proposta. Estas três etapas rodam quando a feature ainda é texto.
Percorre o fluxo de dados da feature elemento por elemento aplicando STRIDE — falsificação de identidade, adulteração, repúdio, vazamento, negação de serviço e elevação de privilégio — e acrescenta a lente de riscos específicos de sistemas com agentes. O resultado não é um documento parado: vira critério de aceitação da própria feature, com referência ao controle ASVS correspondente.
/threat-model
A avaliação de impacto de privacidade roda pelo método LINDDUN sobre os fluxos de dado pessoal da feature, com referência a GDPR e ISO 27701. É a diferença entre descobrir na revisão jurídica que a feature guarda mais do que devia e ter decidido isso no desenho — quando ainda custa uma linha.
/dpia
A partir dos casos de uso que você já documentou, deriva os casos de abuso: o mesmo fluxo, pela ótica de quem quer quebrá-lo, ator por ator. Sai o que ninguém escreve porque ninguém tem tempo — e é exatamente onde moram os incidentes.
/abuse-cases
Sobre o código e sobre a aplicação
Audita o diff pendente ou um diretório e mapeia cada achado ao controle ASVS 5.0 e ao OWASP Top 10 correspondente — não a uma taxonomia própria que só existe aqui. Cada finding chega com a referência que o time já usa para priorizar.
/security-review
O que a análise estática não vê: a aplicação viva respondendo. Cabeçalhos de segurança, injeção, cross-site scripting e — no nível mais alto — acesso indevido a objeto de outro usuário e falhas de autenticação. Report-only por desenho: aponta e propõe, não altera.
/dast
Na porta do release
A decisão de liberar ou barrar um release não deveria depender de alguém ter lido um relatório na sexta à tarde.
O gate devolve um código de saída: zero libera, diferente de zero bloqueia. É isso que o torna usável num passo de CI — nenhuma etapa do seu pipeline precisa interpretar prosa para decidir se o release passa.
Ele não descobre nada de novo na hora do release, e é de propósito: um gate que executa análise é um gate lento e não determinístico. Este lê os artefatos que as etapas anteriores produziram e decide. Rodar duas vezes dá o mesmo resultado.
Cada motivo de bloqueio tem um código próprio e uma saída óbvia: falta o modelo de ameaças, existe achado crítico aberto no scan, existe pendência de segurança crítica não resolvida. Ninguém precisa adivinhar por que o release parou.
No nível de rigor mais leve e no padrão o gate reporta e libera: bloquear release é comportamento do nível estrito, para quando o projeto — ou a feature — pede isso. Você escolhe quando a trava fecha; veja como o rigor se dosa.
# no passo de CI, antes do deploy:
$ /security-gate --tier strict --json
# exit 0 → libera · exit ≠ 0 → bloqueia, com o motivoO que amarra tudo
O Spaccy orquestra as ferramentas de análise que já existem e são melhores do que qualquer coisa que fizéssemos do zero — inclusive o revisor de segurança oficial da Anthropic, que entra como motor plugável. O que o produto acrescenta é o que falta no mercado: integração, dosagem por risco, rastreamento e gate.
Achados de origens diferentes são normalizados em SARIF, o formato padrão de resultado de análise estática. Isso significa que o mesmo achado é legível pelo seu editor, pela sua interface de code review e pelo gate — sem cada ferramenta falando um dialeto.
Cada achado entra no mesmo registro de pendências do resto do trabalho, marcado como segurança, com severidade e dono. Não existe backlog paralelo que só o pessoal de segurança abre — a vulnerabilidade compete por prioridade no mesmo lugar que a feature.
A profundidade acompanha o nível de rigor do projeto: no mais leve, foco em segredos e autenticação; no padrão, análise estática completa; no estrito, cadeia de suprimentos, infraestrutura como código e o checklist ASVS mais alto. O que o nível nunca faz é tornar um scan menos correto — só reduz o que ele olha.
Peça acesso antecipado e modele ameaças na feature que estiver em desenho antes de qualquer código existir.