Pentest para SaaS: como testar segurança a cada deploy

Por que SaaS precisa de teste contínuo

Um SaaS não é um artefato pronto: é um alvo em movimento. Cada release adiciona endpoint, muda uma permissão, expõe um campo novo na API. A superfície de ataque muda a cada deploy — e é exatamente aí que nasce a maioria das regressões de segurança. Testar uma vez e assumir que continua seguro é medir a temperatura de ontem.

O agravante do modelo SaaS é o multi-tenancy: vários clientes compartilham a mesma aplicação e o mesmo banco, separados só por lógica de autorização. Um deploy que erra um filtro de tenant_id não derruba o sistema — ele silenciosamente deixa o cliente A ler os dados do cliente B. Nenhum teste funcional pega isso; um pentest, sim.

O custo da mentalidade "pentest 1× por ano"

O pentest manual anual existe por um motivo econômico: custa R$8.000–18.000 e leva 1 a 2 semanas. Nesse preço, ninguém roda toda semana. O resultado é uma janela cega enorme — você faz dezenas ou centenas de deploys entre uma auditoria e a próxima, e cada um pode ter introduzido a falha que só vai aparecer no laudo do ano que vem (ou no vazamento).

Para um SaaS que entrega valor pela velocidade de iteração, isso é um descompasso estrutural: o produto muda em dias, a verificação de segurança acontece em meses. A correção não é testar menos — é baixar o custo do teste até ele caber na frequência do deploy.

Shift-left: segurança dentro do CI/CD

Shift-left é mover a verificação de segurança para o começo do ciclo, junto com os testes que você já roda. Se um pentest automatizado custa poucos reais e roda em minutos, ele deixa de ser um evento e vira um step de pipeline — como lint, type-check e testes de integração.

Na prática, isso significa disparar o scan contra o ambiente de staging (ou um preview deploy) a cada merge na main, e ler o resultado antes de promover para produção. A falha é pega no momento em que foi introduzida — quando o dev ainda tem o contexto fresco — e não seis meses depois, quando ninguém lembra por que aquele endpoint existe.

O que priorizar em SaaS a cada deploy

Nem toda classe de falha tem o mesmo peso num SaaS. As que mais quebram entre releases, e que você quer verificar em todo deploy:

• Broken Access Control / IDOR entre tenants — o cliente A consegue acessar recurso do cliente B trocando um ID na URL ou no corpo da requisição. É a falha nº 1 do OWASP Top 10 e a mais perigosa em multi-tenant.
• Autenticação e sessão — tokens que não expiram, JWT mal validado, reset de senha burlável, sessão que sobrevive ao logout. Uma mudança no fluxo de login pode reabrir um buraco fechado meses atrás.
• Exposição de dados em APIs — endpoint que devolve mais campos do que a UI mostra (dados de outro usuário, hash de senha, flags internas). Comum quando o back-end serializa o objeto inteiro em vez de um DTO.
• Mass assignment — o cliente envia role: admin ou is_verified: true num payload que o back-end aceita cego, elevando privilégio sem passar por autorização.
• Rate limiting e abuso — endpoints de login, OTP e envio de e-mail sem limite, abrindo brute-force e enumeração de usuários.

Cadência recomendada por tipo de mudança

Nem todo commit precisa do mesmo rigor. Um guia prático de quando acionar o quê:

Como encaixar sem travar o time

O medo legítimo é que segurança no CI vire gargalo. Três decisões evitam isso: rode contra staging, não bloqueando o build em si; gate por severidade, não por qualquer ruído — só achado crítico ou alto confirmado segura a promoção para produção; e exija confirmação por exploração, para o dev não perder tempo triando falso positivo.

Esse último ponto é o que separa um pentest automatizado sério de um scanner tradicional. Scanner cospe uma lista de CVEs teóricas e afoga o time em ruído; um motor que explora de verdade só reporta o que conseguiu confirmar, com evidência e CVSS. A diferença de fundo é a mesma do pentest manual vs automatizado: velocidade e custo, sem abrir mão da confiabilidade.

Escudo Code como linha de base contínua

O Escudo Code foi feito para exatamente esse encaixe: um pentest automatizado que explora de verdade — executa exploits reais e só reporta o que confirmou, com evidência e CVSS por achado. No agregado já são 900+ vulnerabilidades confirmadas (508 críticas/altas), validado em benchmarks como OWASP Juice Shop e VAmPI. Roda em minutos por R$50–200 por scan, o que viabiliza tratá-lo como step de CI a cada deploy em vez de evento anual.

As credenciais que você fornece ficam só em memória durante o scan, e a regra é simples: só teste o que é seu. Veja como testamos ou os planos para acoplar ao seu pipeline. Antes de subir, vale também cruzar com o checklist de segurança web e revisar as vulnerabilidades comuns em APIs REST.