Auditoria de segurança com gstack: o que o comando /cso analisa?

Fala aí, beleza? Quem shippa rápido acumula dívida de segurança invisível

O segredo que entrou num commit de madrugada, a dependência que ninguém abriu, o endpoint que nasceu "temporário" e virou permanente

O /cso é a skill de segurança do gstack, o setup de Claude Code publicado por Garry Tan no repositório oficial garrytan/gstack, descrito lá como um conjunto de 23 ferramentas opinativas que atuam como CEO, Designer, Eng Manager, Release Manager, Doc Engineer e QA

O que ele faz é direto: uma auditoria baseada em OWASP Top 10 mais modelagem de ameaças STRIDE em cima do teu codebase

Este post é pra quem quer uma camada a mais de auditoria rodando na própria máquina, pegando o óbvio antes que ele vire incidente 🙂

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O que a auditoria do /cso cobre

O escopo é descrito como infrastructure-first, ou seja, ele não começa pelo teu código bonitinho, ele começa por onde a casa costuma estar aberta

São estes os blocos:

• Arqueologia de segredos: varre o histórico do git atrás de credenciais vazadas, checa arquivo .env versionado e procura segredos inline em configs de CI. Esse é o clássico do vibe coding acelerado: tu remove a chave do arquivo, commita a remoção e acha que resolveu, mas o histórico do git guardou tudo
• Cadeia de suprimentos de dependências: o npm install de terça passada trouxe coisa que ninguém leu, e essa superfície cresce sozinha
• Segurança de pipeline CI/CD: o pipeline tem credencial de deploy e roda código automaticamente, é um alvo redondo e quase sempre configurado no "funcionou, deixa quieto"
• Segurança de LLM/IA: fronteira de confiança nova, com regra velha. Se tem prompt recebendo entrada de usuário, tem superfície
• Cadeia de suprimentos de skills: skill instalada é código de terceiro rodando com o teu contexto, beleza? Poucos tratam skill como dependência, e ela é
• OWASP Top 10: a lista de sempre, aplicada no que tu escreveu
• Modelagem STRIDE: aqui não é procurar bug, é pensar como o atacante pensaria contra a tua arquitetura
• Verificação ativa: a parte que confere, em vez de só apontar

Repara no padrão: metade dessas superfícies não está no código que tu revisa no pull request, ela está em volta dele

Como as fases 0 a 14 se organizam

A auditoria completa é organizada em fases numeradas de 0 a 14, ou seja, 15 fases no total, porque a contagem começa no zero

O fluxo pra entender a mecânica:

1. Rode o comando sem nenhuma flag pra disparar a auditoria completa, todas as fases de 0 a 14 no modo diário:

/cso

2. A fase 0 é a detecção de stack. Faz sentido: antes de dizer o que está errado, a skill precisa saber o que tu está usando
3. A fase 1 é o censo de superfície de ataque, o mapa do que existe e pode ser tocado de fora
4. As demais fases estão definidas no arquivo de fases da própria skill, dentro da instalação do gstack:

~/.claude/skills/gstack/cso/sections/audit-phases.md

5. Abra esse arquivo se quiser a lista completa fase a fase

O erro comum deste passo: supor o conteúdo das fases intermediárias por dedução, e depois tomar decisão em cima disso. O arquivo audit-phases.md é a fonte de verdade, e ele está aí, a um cat de distância 😀

Modo diário x modo –comprehensive: qual usar

São dois níveis de rigor, e a diferença toda está no portão de confiança:

A lógica é boa: no dia a dia, relatório cheio de "talvez" vira ruído e tu para de ler

Aí, quando o custo do erro sobe (vai abrir pro público, vai plugar num cliente), tu baixa o portão pra 2/10 e aceita ler os TENTATIVE um por um

Flags de escopo: como recortar a auditoria

Auditoria completa toda hora não é realista. Por isso existem as flags de escopo, cada uma amarrada a um subconjunto de fases:

1. --infra roda as fases 0-6 e 12-14
2. --code roda as fases 0-1, 7, 9-11 e 12-14
3. --skills roda as fases 0, 8 e 12-14
4. --supply-chain roda as fases 0, 3 e 12-14
5. --owasp roda as fases 0, 9 e 12-14
6. --scope <domínio> recorta por área do sistema, por exemplo:

/cso --scope auth

7. --diff limita a auditoria às mudanças da branch, e essa aqui é combinável com as de escopo:

/cso --diff --code

O erro comum deste passo: empilhar duas flags de escopo achando que soma cobertura. Elas são mutuamente exclusivas, e a skill devolve erro:

--infra and --code are mutually exclusive. Pick one scope flag, or run /cso with no flags for a full audit.

Ou seja: escolhe UMA de escopo, ou roda sem flag nenhuma pra auditoria completa

Como instalar o gstack para rodar o /cso

A instalação documentada é git clone mais script de setup, next, next e finish:

1. Clone o repositório oficial pra pasta de skills e rode o ./setup:

git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup

2. Depois disso os arquivos da skill de segurança vivem em ~/.claude/skills/gstack/cso/, com o arquivo de fases dentro da subpasta sections/, no caminho ~/.claude/skills/gstack/cso/sections/audit-phases.md que eu citei ali em cima

O erro comum deste passo: buscar "gstack" e cair no Ahacad/gstack. Ele se descreve como um wrapper de plugin de Claude Code em cima do garrytan/gstack, não é o repositório oficial. Tome cuidado, porque em ferramenta de SEGURANÇA a origem do código importa mais que em qualquer outra 😛

Como o /cso entra na rotina de quem shippa rápido

O encaixe natural tem três velocidades:

• No fluxo de branch, antes do merge: --diff deixa a auditoria só nas mudanças daquela branch, que é o único recorte que cabe num ciclo curto
• Durante o desenvolvimento de uma área: mexendo em login a semana inteira? --scope auth mantém o foco onde tu está
• Em momentos de marco: aí sim a auditoria completa, das fases 0 a 14, e eventualmente no --comprehensive

O que torna isso acionável é o formato do relatório: cada achado vem com severidade, evidência, correção recomendada e um cenário concreto de exploração

Esse último item é o que muda o jogo, porque "possível vulnerabilidade em X" ninguém prioriza, agora "assim aqui alguém pega o teu token" vai pro topo da lista na hora

E repara no limite: o /cso olha o codebase, não a máquina onde ele roda. Se o teu deploy vive num servidor teu, configurar auditoria e logs em VPS continua sendo outra camada, com outra checagem

Mesma coisa pro que tu automatiza em volta: auditoria de segurança no n8n é superfície própria, com exigência própria de compliance

Auditoria automatizada não substitui revisão humana

Agora o contrapeso honesto, porque post de ferramenta sem contrapeso é folder de vendas

O próprio repositório do gstack tem uma issue pública de auditoria de segurança, a Issue #783, reportando 6 achados críticos e 10 altos em rede, sistema de arquivos e fronteiras de confiança de LLM

Ou seja: ferramenta de segurança também é código de terceiro rodando na tua máquina, com os teus arquivos ao alcance

E tem o outro lado, que a própria skill assume: o portão de confiança 8/10 do modo diário existe justamente porque nem todo achado é certeza. Um portão alto filtra ruído, mas filtro é filtro, alguma coisa fica de fora

Daí a régua, a mesma da abertura: use como camada, não como carimbo de aprovado

Vídeo: como o Claude Code se comporta com skills instaladas

Pra começar do zero na parte de skills e consumo de token no Claude Code, este vídeo do canal mostra como um comando muda o gasto da sessão

Serve bem de contexto antes de você encher a instalação de skill nova, incluindo a de auditoria de segurança

Conclusão

Recapitulando: o /cso do gstack é uma auditoria de OWASP Top 10 mais STRIDE, organizada em fases de 0 a 14, com dois níveis de rigor (padrão em 8/10 e --comprehensive em 2/10) e recortes por flag de escopo, todas mutuamente exclusivas

O próximo passo é bem concreto: instala o gstack pelo repositório oficial com o git clone mais ./setup, roda /cso --diff numa branch pequena só pra ver o formato dos achados (severidade, evidência, fix, cenário de exploit) e abre o audit-phases.md pra ler a lista completa das fases

É meia hora de trabalho pra descobrir o que já estava lá o tempo todo…

até o próximo post! 😀