Teste de intrusão para SaaS e questionários enterprise (SIG, CAIS)

O questionário que bloqueia o contrato

A demonstração correu bem, a equipa técnica do cliente gostou e chega a folha de cálculo da equipa de segurança: SIG, CAIS ou um questionário próprio de gestão de risco de terceiros, com 150 perguntas. A certa altura surge a linha que dita o ritmo do negócio: "A empresa realiza testes de intrusão independentes? Quando foi o último? Pode partilhar o resultado?"

Quem responde "sim, fazemos" sem anexo costuma receber nova pergunta. Quem responde "sim, em março, segue o resumo executivo com reteste" passa à linha seguinte. Este guia mostra como preparar essa segunda resposta antes de o questionário chegar.

Enquanto a folha de cálculo fica sem resposta, o contrato também fica parado. O comercial insiste, a engenharia diz que "temos um teste de intrusão, só preciso de encontrar o PDF", e o analista do cliente marca o item como pendente. A revisão de segurança é muitas vezes o último passo antes da assinatura, e cada ronda de perguntas e respostas adia a data do primeiro pagamento.

O que a equipa de risco do cliente quer realmente saber

O analista de risco de terceiros não vai ler o seu relatório técnico completo. Precisa de assinalar uma caixa defensável perante o auditor interno. Na prática, procura cinco coisas:

Independência: o teste foi feito por terceiros, não pela sua equipa de desenvolvimento.
Atualidade: normalmente nos últimos 12 meses ou após uma alteração relevante ao produto.
Âmbito compatível: cobre a aplicação e a API que o cliente vai usar, não apenas o site institucional.
Tratamento das vulnerabilidades: as críticas e altas foram corrigidas e retestadas.
Método: metodologia indicada (OWASP WSTG, OWASP API Security, PTES, NIST SP 800-115), e não só uma lista de itens.

Se o seu material responder a estas cinco questões numa página, a maior parte do atrito desaparece.

O que partilhar: carta de atestação, resumo executivo ou relatório completo

Quase nunca se envia o relatório completo. Contém detalhes de vulnerabilidades, caminhos internos e provas de exploração. Em mãos erradas, torna-se um guia de ataque. O padrão de mercado tem três níveis:

Documento	O que contém	Quando enviar
Carta de atestação	Quem testou, quando, âmbito, metodologia, resumo de severidades, estado do reteste. Uma página.	Resposta padrão a questionários e primeiro contacto de due diligence
Resumo executivo	Panorama de riscos, contagem por severidade, correções confirmadas, limitações do teste. 2 a 4 páginas.	Clientes enterprise, pedidos de segurança durante a negociação
Carta de reteste	Confirma, achado a achado, o que foi corrigido e o que continua em aberto, com datas.	Quando o cliente pergunta se os problemas graves foram resolvidos
Relatório completo	Vulnerabilidades detalhadas, evidências, passos de reprodução.	Apenas sob NDA e para clientes específicos com pedido formal; prefira leitura supervisionada

Duas regras práticas: nunca envie vulnerabilidades em aberto sem plano de correção e mantenha uma versão do resumo sem nomes de endpoints, contas de teste ou credenciais. Fale com o departamento jurídico sobre o NDA antes de o pedido chegar, não durante.

Como responder à pergunta no questionário

Uma resposta que costuma passar sem nova pergunta tem esta estrutura:

Sim, com periodicidade definida ("anual e após alterações significativas de arquitetura").
Data do último teste e quem o executou (empresa independente).
Âmbito: aplicação web, API, autenticação e isolamento entre clientes.
Metodologia: OWASP WSTG e OWASP API Security Top 10.
Estado das vulnerabilidades: críticas e altas corrigidas e retestadas na data X.
Anexo: carta de atestação ou resumo executivo.

Evite expressões vagas como "realizamos testes de segurança regularmente". Evite também prometer uma cobertura que o teste não teve: se o âmbito foi apenas a API, diga que foi apenas a API.

Exemplos de resposta para adaptar

Pergunta: "A empresa realiza testes de intrusão independentes?"

Sim. Realizamos um teste de intrusão independente anualmente e após alterações significativas de arquitetura. O último foi concluído em [mês/ano] por [empresa], abrangendo aplicação web, API, autenticação e isolamento entre clientes, segundo o OWASP WSTG e o OWASP API Security Top 10. Os achados críticos e altos foram corrigidos e retestados em [data]. A carta de atestação segue em anexo.

Pergunta: "Pode partilhar o relatório completo?"

O relatório técnico completo contém detalhes de exploração e só é partilhado sob NDA, mediante pedido formal. Disponibilizamos carta de atestação e resumo executivo, e podemos apresentar os achados numa sessão de leitura supervisionada.

Se o primeiro teste ainda não foi feito:

Teste de intrusão independente contratado, com execução prevista para [mês]. Enviaremos a carta de atestação assim que o reteste estiver concluído.

Nunca invente a data de um teste que não existe. O analista pode pedir o anexo, e uma resposta honesta com prazo costuma ser melhor aceite do que um "sim" sem prova.

Âmbito de um teste de intrusão para SaaS B2B

O SaaS vendido a empresas tem um risco que um site institucional não tem: vários clientes dentro da mesma aplicação. Um bom âmbito cobre:

Aplicação web (todas as funcionalidades autenticadas, por perfil de utilizador).
API usada pelo front-end e por integrações, incluindo endpoints não documentados. Veja o guia de testes de intrusão a APIs.
Autenticação e sessão: início de sessão, MFA, recuperação de palavra-passe, SSO/SAML/OAuth, expiração de tokens.
Isolamento multi-tenant: um utilizador do cliente A consegue ler ou alterar dados do cliente B? É a vulnerabilidade que mais preocupa os compradores enterprise e a mais comum em APIs (BOLA).
Autorização e perfis: escalada de privilégios entre papéis (utilizador comum para administrador).
Carregamento de ficheiros, exportações, webhooks e integrações com sistemas de terceiros.
Componentes de IA, se existirem (assistentes, RAG, agentes), tratados como parte da superfície de ataque.

A infraestrutura cloud entra no âmbito se o cliente perguntar por ela, mas em SaaS o essencial é aplicação, API e isolamento entre inquilinos.

Na prática, os pontos fracos de um SaaS B2B são previsíveis: objetos acedidos por identificador sem verificar o proprietário (BOLA/IDOR), funções de administração acessíveis a utilizadores comuns, SSO com validação fraca de asserções ou tokens, uploads que aceitam conteúdo executável e exportações que expõem dados de outro cliente. Peça ao fornecedor que teste cada perfil de utilizador e pelo menos duas contas de clientes diferentes, para provar o isolamento em vez de o presumir. O painel de administração interno também entra no âmbito: é onde um erro expõe todos os inquilinos de uma só vez.

Quando testar para não atrasar o contrato

O pior momento para contratar um teste de intrusão é depois de receber o questionário. O teste demora dias, o relatório mais alguns, e a correção e o reteste ainda mais tempo. Um calendário realista:

Antes de começar a vender para enterprise: faça o primeiro teste e deixe a carta de atestação pronta.
A cada 12 meses, ou após uma alteração grande (nova arquitetura de autenticação, novo módulo de pagamentos, migração cloud).
Quando um cliente grande pede um âmbito próprio: avise o fornecedor cedo, porque ajustar âmbito e janela de teste demora.

Um teste de 2023 apresentado em 2026, depois de duas migrações, torna-se uma pergunta e não uma resposta.

O custo de adiar o teste

Compare o preço do teste de intrusão com o custo do atraso, não com zero. Cada semana de negociação parada adia receita recorrente que só começa depois da assinatura, mantém o comercial e a engenharia em retrabalho e dá espaço ao concorrente que já tem a resposta pronta. Não existe um valor universal, mas pode estimá-lo com os seus dados: pegue no valor anual dos últimos três contratos enterprise que travaram em segurança, multiplique pelas semanas de atraso e divida por 52. Coloque esse valor ao lado do orçamento do teste.

Reteste: a evidência que fecha a conversa

O analista de risco não precisa de um relatório sem falhas. Sabe que os testes encontram problemas. Quer ver que os problemas graves foram corrigidos e verificados por quem os encontrou. Por isso o reteste é importante:

Data do reteste e quais as vulnerabilidades confirmadas como corrigidas.
Vulnerabilidades residuais, com aceitação de risco justificada ou plano de correção.
Referência no resumo executivo, e não escondida num anexo.

Um resumo que mostra "3 altas encontradas, 3 corrigidas e retestadas" é mais forte do que um relatório limpo sem reteste.

Como manter a evidência atual entre um teste e outro

A carta de atestação envelhece. Para continuar útil ao longo do ano:

Registe no histórico de versões as alterações relevantes (novo módulo de pagamentos, novo método de autenticação, migração de cloud) e decida se cada uma exige um teste complementar.
Prefira um teste dirigido ao que mudou, em vez de refazer tudo, quando a arquitetura base é a mesma.
Atualize a carta com a data do último reteste sempre que houver nova ronda.
Mantenha os achados residuais com responsável e prazo, e reveja o backlog trimestralmente.
Use análise contínua e revisão de dependências como complemento. Ajudam na higiene, mas não substituem o teste manual.

Como isto acelera o negócio e se liga ao SOC 2 e à ISO 27001

Ter a carta de atestação e o resumo prontos tira as equipas de segurança e comercial da fila de e-mails. Em vez de "vamos ver com a equipa técnica" e duas semanas de espera, a resposta sai no mesmo dia e o analista de risco do cliente tem o que precisa para aprovar.

O teste de intrusão não substitui uma certificação. O SOC 2 e a ISO 27001 mostram que tem processos de segurança; o teste mostra que o produto resiste a ataques. Complementam-se, e vários controlos de ambos pedem testes independentes periódicos. O artigo sobre testes de intrusão para ISO 27001, SOC 2 e RGPD detalha o que cada um exige. Se ainda não tem certificação, um teste recente já ajuda a passar a maioria dos questionários.

Quanto ao custo, o guia de preços de testes de intrusão explica o que altera o valor. Para um SaaS com aplicação web e API, o investimento é normalmente inferior ao custo de um ciclo de vendas enterprise parado por falta de resposta.

Lista de verificação: pronto para o próximo questionário

[ ] Teste de intrusão independente nos últimos 12 meses, cobrindo aplicação web, API, autenticação e isolamento multi-tenant
[ ] Carta de atestação de uma página, revista pelo departamento jurídico
[ ] Resumo executivo com contagem por severidade e estado do reteste
[ ] Reteste das vulnerabilidades críticas e altas documentado com data
[ ] Texto padrão de resposta à pergunta sobre testes de intrusão
[ ] Política de NDA definida para o envio do relatório completo
[ ] Calendário do próximo teste (anual ou após alteração grande)

Perguntas frequentes

Posso enviar o relatório completo ao cliente?

Pode, mas não deve ser o procedimento habitual. Prefira a carta de atestação e o resumo executivo. O relatório completo apenas sob NDA, para um cliente específico com pedido formal e, de preferência, em leitura supervisionada.

O meu teste tem mais de 12 meses. Ainda é válido?

Muitos clientes aceitam até 12 meses e perguntam o que mudou desde então. Se houve uma alteração grande de arquitetura, autenticação ou cloud, planeie um novo teste ou um teste complementar ao que mudou.

Preciso de SOC 2 ou ISO 27001 para vender a empresas grandes?

Não necessariamente. Muitos clientes aceitam um teste recente, políticas documentadas e respostas consistentes ao questionário. A certificação ajuda quando o cliente a exige em contrato.

Um scanner automático serve como evidência?

Em geral não. Quem avalia distingue um scan de um teste manual. Veja a diferença em scanner, pentest ou bug bounty.

Quanto tempo demora a ter o resumo executivo?

Depende do âmbito. Combine com o fornecedor, desde o início, o formato da carta de atestação e do resumo, para que saiam em conjunto com o relatório e o reteste.

Quem assina a carta de atestação?

A empresa que executou o teste, com data, âmbito, metodologia e estado do reteste. O jurídico da sua empresa deve rever o texto antes do primeiro envio.

O teste deve ser feito em produção ou em ambiente de testes?

O ideal é um ambiente equivalente à produção, com dados fictícios, ou produção com janela combinada e salvaguardas. A carta deve indicar que ambiente foi testado, porque o analista de risco vai perguntar.

O cliente pode exigir testar o nosso produto por conta própria?

Alguns pedem. Costuma funcionar definir no contrato a janela, o âmbito, as contas de teste e a proibição de negação de serviço, e oferecer o relatório independente como alternativa.

Prepare a resposta antes do próximo questionário

A Pentest Machine realiza testes de intrusão a SaaS com documentação pronta para clientes enterprise: carta de atestação, resumo executivo, relatório técnico completo e reteste das vulnerabilidades corrigidas. Defina o âmbito connosco antes de o questionário chegar. Peça um orçamento.