Início › Blog › SAST para SaaS feito com IA

SAST para SaaS feito com IA: o que o Semgrep pega e o que escapa

12 de outubro de 2026 · ~8 min de leitura

Se você colocou um SaaS no ar com ajuda de IA e quer "rodar um SAST antes de lançar", a primeira ferramenta que aparece costuma ser o Semgrep. É uma ótima ferramenta — e grátis para muita coisa. Mas existe uma classe inteira de falhas, justamente a que mais derruba SaaS novo, que ela quase nunca pega. Este artigo explica a diferença sem enrolar.

Primeiro: SAST, DAST e SCA em uma frase cada

Os três são complementares. O SAST é o mais acessível no fluxo de dev (roda no CI, não precisa de ambiente) — e é por isso que quase todo mundo começa por ele.

O que o Semgrep (e o SAST por padrão) pega muito bem

Ferramentas de SAST baseadas em padrões (regras que casam com um trecho de código) são excelentes para falhas que têm uma "cara" reconhecível:

• Segredos no código — chaves de API, tokens, senhas em texto plano.
• Funções perigosas — eval(), dangerouslySetInnerHTML, child_process.exec com entrada do usuário.
• Injeção por fluxo de dados (taint) — um input que chega "sujo" até uma query SQL ou um comando de shell.
• Configurações inseguras conhecidas — CORS com *, cookies sem httpOnly, TLS desligado.

Para esse tipo de coisa, rode o Semgrep no seu CI hoje mesmo. É retorno garantido e barato.

O que escapa — e por que

O limite do SAST por padrão aparece quando a falha não é um trecho errado, e sim uma regra de negócio ausente ou mal aplicada. Para enxergar isso, a ferramenta precisaria entender a intenção do código, não só a forma. Exemplos:

1. Autorização quebrada (IDOR / BOLA)

Este endpoint é sintaticamente perfeito. Nenhuma regra de padrão reclama dele:

app.get('/orders/:id', auth, async (req, res) => {
  const order = await db.orders.findById(req.params.id);
  res.json(order); // ❌ nunca checa se o pedido é do usuário
});

Está "logado" (passou pelo auth), mas qualquer um troca o :id e lê o pedido dos outros. Para um SAST por padrão isso é código normal — a falha é a linha que não existe (a checagem de dono), e padrão não enxerga ausência. É a falha nº 1 do OWASP API Top 10 e a que mais vaza dados em SaaS multi-cliente.

2. Regras de acesso do banco (Firestore / Supabase RLS)

Em stacks tipo Firebase e Supabase, boa parte da segurança não está no seu TypeScript — está no firestore.rules ou nas políticas de RLS do Postgres. O SAST da sua app nem olha esses arquivos, e uma regra aberta ali expõe o banco direto, sem passar pelo seu código. (Escrevemos um guia só sobre isso: os 7 erros de Firebase Security Rules.)

3. Checagem no cliente que deveria ser no servidor

O botão de admin some da tela, mas a rota da API continua aberta. Ou o limite do plano é validado só no front. O padrão vê duas peças corretas isoladamente; não entende que a confiança foi posta no lugar errado.

4. Lógica de negócio e estado entre arquivos

"Pagou → libera" com condição de corrida. Cupom que pode ser aplicado duas vezes. Webhook sem idempotência. São falhas que exigem seguir o fluxo por vários arquivos e entender o que deveria acontecer — território onde regras de padrão não chegam.

Onde entra uma revisão com IA

É aqui que o SAAS SHIELD é complemento, não substituto, do Semgrep. Em vez de casar padrões, ele lê o repositório como um revisor humano faria: segue o fluxo entre arquivos, entende quem deveria poder fazer o quê, e sinaliza a autorização que falta, o isolamento de cliente frágil e as regras de Firestore/RLS abertas. Cada achado vem com local no código, evidência e correção, mapeado para OWASP.

A combinação prática: Semgrep no CI para os padrões (segredos, injeção, funções perigosas) + uma revisão de lógica e autorização antes de lançar. Um cobre a forma; o outro cobre a intenção.