OWASP Top 10; SAST × DAST × IAST × SCA; pentest; CSP, WAF

A ideia que organiza o assunto

Uma vulnerabilidade de aplicação web tem dois lados. Ela existe no código, escrita numa linha que ninguém revisou, e ela só se realiza na execução, quando uma requisição real atravessa aquela linha com um dado que o autor não previu. Nenhuma técnica de teste alcança os dois lados ao mesmo tempo sem pagar por isso, e é dessa limitação — não de uma taxonomia arbitrária — que nascem as famílias de teste que a prova cobra.

Por isso, diante de qualquer sigla do tópico, faça duas perguntas: o software precisa estar em execução? e a técnica enxerga o código-fonte? As respostas já dão os nomes:

	precisa executar	enxerga o código	é
SAST	não	sim	caixa branca
DAST	sim	não	caixa preta
IAST	sim	sim (instrumentado por dentro)	caixa cinza
SCA	não	não olha o seu código: olha as dependências	inventário

Guardada essa grade, quase todo item do assunto se decide sem decorar definições: se o enunciado diz que a técnica examina o comportamento em tempo de execução, ela não pode ser SAST; se diz que revisa o código-fonte sem executar, não pode ser DAST; se fala em bibliotecas de terceiros e CVE, é SCA.

A segunda metade do tópico é institucional e cai por confusão de nomes. OWASP é a organização; ela publica coisas de naturezas diferentes e a banca troca uma pela outra: o Top 10 é um documento de conscientização, uma lista dos dez riscos mais críticos — não é norma, não é obrigatório e não é ferramenta; o ASVS é o padrão de requisitos verificáveis; o SAMM é o modelo de maturidade do processo de desenvolvimento; o ZAP é a ferramenta de teste dinâmico. Top 10 é o que você conhece, ASVS é o que você exige, SAMM é como você amadurece, ZAP é com o que você ataca.

E acima de tudo isso está o pentest: o humano que faz o que nenhum verificador automático faz — encadear falhas e explorar lógica de negócio.

Por que se usa (e o que custa)

Cada técnica compra cobertura numa dimensão e paga na outra.

O SAST entra cedo, vê todos os caminhos do código (inclusive os que nenhum teste exercita) e aponta arquivo e linha. Paga em falsos positivos: sem contexto de execução, ele não sabe se aquele caminho é alcançável nem se há um saneamento a montante. O DAST tem o defeito simétrico — só encontra o que consegue alcançar atacando pela porta da frente, chega tarde e não diz a linha do defeito — mas o que ele acha está comprovadamente explorável, e ele funciona sobre qualquer linguagem, inclusive sobre o que já está em produção.

O IAST promete os dois lados porque o agente vive dentro da aplicação e vê a requisição chegar e o trecho de código responder. Cobra instrumentação, custo de desempenho em tempo de execução e suporte por linguagem — e continua limitado ao que o tráfego de teste exercitar. O SCA é o mais barato dos quatro e o de melhor retorno: comparar a lista de dependências com bases de vulnerabilidades conhecidas é quase de graça. Em compensação, ele só enxerga o conhecido — CVE já publicada — e não diz nada sobre o código que a própria equipe escreveu.

O pentest encontra o que nenhum dos quatro encontra: falha de lógica de negócio, escalonamento de privilégio, cadeia de explorações. Custa caro, é manual e vale para um instante — muda-se o sistema, envelhece o laudo. Por isso os testes automatizados vivem dentro do pipeline e o pentest é periódico, sobre uma aplicação já em estágio avançado.

A formulação honesta para a prova: as técnicas não competem, se completam. Nenhuma delas, sozinha, garante aplicação livre de vulnerabilidades — item que promete isso é falso por construção.

Como funciona

As quatro técnicas, uma a uma. O SAST analisa o código-fonte, o bytecode ou o binário sem executá-lo: percorre a árvore sintática e rastreia o fluxo de dados da entrada (source) até o ponto perigoso (sink). É a aplicação de shift-left à segurança — roda no commit, na IDE, no build. O DAST faz o contrário: trata a aplicação como caixa preta em execução e envia requisições maliciosas contra ela, observando as respostas. É aí que mora o fuzzing, que submete grandes volumes de entradas inválidas, inesperadas ou aleatórias a qualquer mecanismo de entrada até que algo estoure — exceção não tratada, estouro de buffer, erro 500. O IAST instala um agente dentro do tempo de execução e correlaciona o ataque recebido com a linha executada, o que reduz falso positivo e aponta a linha. O SCA não testa: inventaria. Monta a lista de componentes de terceiros e suas versões (a base de um SBOM) e confronta com CVE e NVD, cobrindo o risco de cadeia de fornecimento.

Análise estática não é só segurança. A mesma varredura sem execução serve à qualidade: sintaxe, padrões de codificação, complexidade, duplicação. O SonarQube é o representante do tópico. Ele classifica o que encontra em bug, vulnerabilidade e code smell, cobre dezenas de linguagens (compiladas, interpretadas e de dispositivos móveis), integra-se ao Jenkins e a outros orquestradores, analisa por branch e guarda histórico para acompanhar a saúde do projeto ao longo do tempo — com uma ressalva que a banca usa: há uma rotina de limpeza que descarta dados antigos, então ele não guarda tudo indefinidamente. Uma questão apontada pode ser resolvida como corrigida, como falso positivo (quando a ferramenta se enganou) ou como won’t fix (quando o problema é real e se decide conviver com ele). Do lado do clean code que ele mede: funções curtas — no máximo cerca de vinte linhas e dois níveis de indentação —, polimorfismo no lugar de cadeias de condicionais, e comentário como último recurso, porque comentário não compensa código ruim: o certo é reescrever o código.

O OWASP Top 10 de 2021, na ordem. A ordem importa porque a banca pergunta posição e troca categoria por categoria:

A01 quebra de controle de acesso · A02 falhas criptográficas · A03 injeção · A04 design inseguro · A05 configuração incorreta de segurança · A06 componentes vulneráveis e desatualizados · A07 falhas de identificação e autenticação · A08 falhas de integridade de software e dados · A09 falhas de registro e monitoramento · A10 SSRF.

O que mudou em relação a 2017 explica metade dos itens antigos: injeção caiu de A1 para A3 e absorveu o XSS; quebra de controle de acesso subiu de A5 para A01; exposição de dados sensíveis virou falhas criptográficas (causa, não sintoma); XXE foi absorvido por configuração incorreta; desserialização insegura foi absorvida por falhas de integridade; e entraram três categorias novas — design inseguro, falhas de integridade e SSRF.

As categorias que mais caem, pelo que de fato significam. A quebra de controle de acesso é o usuário agindo fora das permissões que lhe cabem: viola o princípio do menor privilégio e o dano pode ultrapassar os privilégios do próprio perfil atacado. Seu caso mais simples é a referência insegura e direta a objetos (IDOR), em que a aplicação expõe um identificador interno e não valida se o autenticado pode acessar aquele registro; a forma mais simples de explorá-la é a adulteração de URL — trocar id=1332 por outro número na barra de endereço —, e quando o registro alcançado é de outro usuário do mesmo nível o escalonamento é horizontal. Já a quebra de autenticação é outra coisa: é o atacante assumindo a identidade da vítima por senha, chave ou sessão comprometida. O design inseguro é a categoria que não se conserta codificando melhor: um projeto inseguro não é corrigido por uma implementação perfeita, e falta de perfil de risco do negócio é uma das causas. A configuração incorreta pode ocorrer em qualquer nível da pilha — sistema operacional, servidor web, SGBD, biblioteca, nuvem — e contas e senhas padrão ainda habilitadas são o exemplo canônico; ela é justamente a categoria que varredores automatizados detectam bem. O SSRF é a aplicação sendo induzida a buscar uma URL escolhida pelo atacante, sem exigir credencial nenhuma — é o servidor quem tem o privilégio, não o atacante.

Defesas em execução. O WAF é um filtro de camada de aplicação (camada 7) na frente da aplicação web: inspeciona HTTP e bloqueia o que casa com assinaturas de ataque conhecidas — padrões de requisição, respostas anômalas do servidor, IPs sabidamente maliciosos — ou o que foge de um modelo de comportamento esperado. O ModSecurity, módulo do Apache, é o exemplo clássico: protege e monitora o tráfego HTTP em tempo real com pouca ou nenhuma alteração de infraestrutura. WAF é mitigação, não correção: ele não conserta o código. O OWASP ZAP é o proxy de teste dinâmico: a varredura passiva apenas observa o tráfego, a ativa ataca a aplicação com requisições conhecidas, e o fuzzer submete entradas inválidas a qualquer campo. Limite que a documentação declara e a banca usa: varredura automatizada não encontra vulnerabilidade lógica — controle de acesso quebrado, por exemplo, exige teste manual.

O pentest é um processo com fases. Segundo o grau de informação entregue ao testador, ele é caixa preta (nada se sabe do alvo; começa-se por coleta de informações), caixa branca (conhecimento e detalhes do ambiente e da aplicação) ou caixa cinza (conhecimento parcial). Segundo o combinado com a organização, é cego, duplo-cego (a equipe de defesa não sabe que haverá teste), direcionado (testador e equipe interna atuam juntos sobre um alvo definido — a escolha quando se quer provar um ataque novo ou concentrar num host específico), externo ou interno. E a execução segue sempre a mesma espinha: reconhecimento, varredura, obtenção de acesso, manutenção do acesso e cobertura de rastros, com planejamento antes e relatório depois.

O SAMM completa o quadro. Enquanto o Top 10 lista riscos do produto, o OWASP SAMM mede a maturidade do processo: cinco funções de negócio — governança, design, implementação, verificação e operações —, cada uma com três práticas de segurança, e três níveis de maturidade.

O que decide os itens

A grade das quatro técnicas — a distinção que decide a maior fatia do tópico:

	o que examina	executa a aplicação	vê o código	quando	acha bem
SAST	código-fonte, bytecode, binário	não	sim (caixa branca)	desenvolvimento, a cada commit	injeção, credencial fixa, erro de sintaxe e de fluxo de dados
DAST	a aplicação em execução	sim	não (caixa preta)	homologação, produção	falha explorável de verdade, exceção não tratada, erro de configuração exposto
IAST	execução instrumentada por dentro	sim	sim (caixa cinza)	teste funcional e automatizado	o de ambos, com a linha do defeito e pouco falso positivo
SCA	dependências de terceiros	não	não é o seu código	build, continuamente	componente vulnerável ou desatualizado (CVE / NVD)

Confusões de nome que a banca monta com isso:

o item diz	quem realmente é
revisa todo o código-fonte sem executar o software	análise estática, não dinâmica
identifica exceções não tratadas e estouro de buffer com entradas longas	análise dinâmica
SonarQube detecta vulnerabilidades por DAST	SonarQube é SAST
SAST procura falhas depois de o sistema entrar em produção	SAST é shift-left: antes, no desenvolvimento
SAST, DAST e SCA analisam o comportamento dinâmico em tempo de execução	só o DAST (e o IAST) executa a aplicação
varredura de vulnerabilidade dirigida especificamente a bibliotecas de terceiros	isso é o SCA, uma parte do programa, não o todo

OWASP: quem é o quê — a outra metade dos itens:

	é
Top 10	documento de conscientização: os dez riscos mais críticos. Não é norma nem exigência obrigatória
ASVS	o padrão de requisitos de verificação de segurança
SAMM	modelo de maturidade do processo: 5 funções de negócio, 3 práticas cada, 3 níveis
ZAP	ferramenta de teste dinâmico (proxy, varredura passiva e ativa, fuzzer)
Cheat Sheets / Testing Guide	material de apoio técnico

Risco → prevenção característica. A banca descreve corretamente a prevenção de uma categoria e assina com o nome de outra:

risco	a prevenção que é dele
Quebra de controle de acesso (A01)	negar por padrão; verificar autorização no modelo de domínio; verificar propriedade do registro; registrar falhas de acesso
Falhas criptográficas (A02)	cifrar em trânsito e em repouso; TLS; algoritmos fortes e atualizados; hash com sal para senhas; gestão de chaves; não armazenar dado sensível desnecessário
Injeção (A03)	consulta parametrizada; validação no lado do servidor; escape; LIMIT
Design inseguro (A04)	modelagem de ameaças; padrões de projeto seguros; ciclo de desenvolvimento seguro
Configuração incorreta (A05)	endurecimento; remover contas e senhas padrão; plataforma mínima; varredura automatizada de configuração
Componentes vulneráveis (A06)	inventário de componentes; acompanhar CVE e NVD; atualizar; obter de fonte oficial
Falhas de identificação e autenticação (A07)	múltiplos fatores; bloquear senha fraca; limitar tentativas; invalidar sessão
Falhas de integridade (A08)	assinatura digital; verificar fonte da atualização e do componente; não desserializar dado não confiável
Registro e monitoramento (A09)	registrar falhas de login, de controle de acesso e de validação com contexto de usuário, e reter por tempo suficiente para perícia
SSRF (A10)	segmentar a rede; negar por padrão o tráfego que não precisa sair; validar a URL fornecida pelo usuário

Tipos de pentest:

	o testador sabe	uso típico
Caixa preta	nada — começa por coleta de informações	simular atacante externo real
Caixa branca	conhecimento e detalhes do ambiente e da aplicação	profundidade, cobertura completa
Caixa cinza	parcial (por exemplo, credenciais de usuário comum)	simular usuário interno ou parceiro
Cego / duplo-cego	no duplo-cego, a defesa também não sabe	medir detecção e resposta
Direcionado	equipe interna e testador atuam juntos, alvo definido	provar um ataque novo ou um host específico

Fronteiras que a banca repete: análise de vulnerabilidade é contínua, ao longo de todo o ciclo de vida e depois dele — nunca “apenas no desenvolvimento”; IDOR se caracteriza por não validar a autorização; WAF opera na camada de aplicação; senha se guarda com hash e sal, nunca em texto puro, por melhor que seja o controle de acesso ao banco; nenhuma ferramenta isolada garante software “livre de vulnerabilidades”; pentest exige aplicação em estágio avançado do ciclo para render informação útil.

Números que caem


OWASP Top 10	10 riscos, revisado a cada 3 ou 4 anos (2013, 2017, 2021)
A01 de 2021	quebra de controle de acesso (era A5 em 2017)
A03 de 2021	injeção (era A1 em 2017) e absorveu o XSS
categorias novas em 2021	3: design inseguro (A04), falhas de integridade (A08), SSRF (A10)
OWASP SAMM	5 funções de negócio, 3 práticas cada (15), 3 níveis de maturidade
ASVS	3 níveis de verificação
WAF	camada 7 (aplicação) do modelo de referência
clean code	funções de no máximo ~20 linhas e 2 níveis de indentação
erro que o fuzzing persegue	HTTP 500 (falha não tratada no servidor)

Como a CEBRASPE derruba você aqui

Troca de termo — 37%, o formato dominante, e por um motivo estrutural. O assunto é uma coleção de nomes próximos: quatro siglas de teste, dez categorias de risco, quatro produtos da OWASP. A frase inteira descreve corretamente um conceito e assina com o nome do vizinho. “Na análise dinâmica, é possível revisar todo o código-fonte sem a necessidade de execução do software” — isso é análise estática, por definição. O SonarQube detectando vulnerabilidades “por meio de DAST (dynamic application security testing)” — ele lê código sem executar, logo é SAST. A descrição inteira da quebra de controle de acesso assinada “a quebra de autenticação”. O XXE, “ataque contra um aplicativo web que analisa a entrada XML”, assinado “a quebra de controle de acesso”. A quebra de autenticação assinada “o ataque de referência insegura a objetos”. O Top 10 descrito e assinado “O OWASP SAMM”. A adulteração de URL chamada de “a passagem de diretório, que é a maneira mais simples de explorar uma vulnerabilidade IDOR”. E o falso positivo do SonarQube chamado de “classificada como wont fix” — won’t fix é a questão real que se decide não corrigir; falso positivo é o engano da ferramenta. Defesa: leia a descrição até o fim, decida sozinho de que conceito ela é e só então olhe o nome que o item usou.

Ainda em troca de termo: a natureza do próprio documento. Dois itens mexem no que o Top 10 é, e não no conteúdo dele. Um o apresenta “como um padrão obrigatório”, quando a própria OWASP o define como documento de conscientização e ponto de partida — quem faz o papel de requisito verificável é o ASVS, e quem mede maturidade de processo é o SAMM. O outro diz que ele “se restringe à listagem das vulnerabilidades de encontradas em sistemas operacionais”, quando o escopo é aplicação web. Guarde os quatro produtos separados: Top 10 conscientiza, ASVS verifica, SAMM mede maturidade, ZAP testa.

Inversão — 27%. A propriedade definidora aparece ao contrário. Testes estáticos que procurariam falhas “após o sistema entrar em produção”, quando o SAST existe justamente para rodar antes, a cada alteração enviada ao repositório. O IDOR que expõe o identificador interno “mas valida se o usuário autenticado estiver autorizado a acessá-lo” — se valida, não há vulnerabilidade. Fuzzing como “inserção de poucos dados não aleatórios”, quando é o oposto em volume e em natureza. Dados sensíveis com tráfego cifrado, mas recomendando que “o seu armazenamento interno seja feito sem criptografia”. Credencial em texto puro que “é uma prática segura, desde que o acesso ao banco de dados seja bem controlado”. Varredura automatizada declarada “ineficaz na tarefa de detectar falhas de configuração”, justamente a categoria em que ela mais rende. E o clean code em que “o uso de polimorfismo deve ser evitado” e em que “comentários em um código-fonte servem para compensar um código mal escrito” — as duas recomendações invertidas. Diga em voz alta qual é a propriedade essencial antes de julgar; se o item afirma o contrário dela, pare de ler.

Generalização — 17%. Um quantificador absoluto num tópico de ferramentas é quase sempre o erro. Análise de vulnerabilidades “apenas durante a fase de desenvolvimento do aplicativo”, quando DAST e teste de invasão atuam sobre a aplicação em execução e o SCA precisa ser contínuo porque uma CVE nova torna vulnerável o componente que ontem estava íntegro. SonarQube exigindo “que todo código analisado seja compilado antes da execução da análise estática”, quando Python e JavaScript são analisados direto do fonte. SonarQube que “armazena todos os dados das análises feitas em um projeto”, quando há rotina de limpeza que consolida instantâneos antigos. O uso de ferramentas de varredura que “será direcionado especificamente às bibliotecas de software de terceiros”, deixando de fora o código próprio, que é onde estão injeção e falha de autorização. E o SSRF que “só pode ser explorado se o atacante tiver credenciais administrativas no servidor de destino” — no SSRF quem tem privilégio é o servidor, não o atacante.

Escopo ampliado — 10%. A regra é certa e o alcance é esticado. A afirmação de que SAST, DAST e SCA “são técnicas de análise do comportamento dinâmico das aplicações em tempo de execução” vale só para o DAST: o SAST não executa nada e o SCA nem analisa comportamento, inventaria dependências e as confronta com bases de vulnerabilidades. O WAF cuja atuação padrão abrangeria “as camadas de rede, de transporte e de aplicação”, o que apaga exatamente a diferença que o define. E o active scan do ZAP usado “para varrer vulnerabilidades como quebra de controle de acesso a aplicações web”: varredura automatizada acha falha técnica com assinatura, não falha lógica — a própria documentação registra isso, e quebra de controle de acesso exige teste manual.

Atribuição errada — 7%: prevenção real, categoria errada. “De modo a prevenir falhas de injeção de dados maliciosos”, recomenda-se abandonar FTP e SMTP no transporte de dados confidenciais — a medida é correta, mas combate exposição de dados sensíveis, porque esses protocolos trafegam sem cifra; prevenir injeção é consulta parametrizada e validação no servidor. E “bloquear o acesso a recursos internos de um ambiente, exceto aos recursos que realmente necessitem ser públicos” oferecido como diretiva de cryptographic failures, quando é endurecimento de ambiente e prevenção de SSRF; a diretiva criptográfica é cifrar em trânsito e em repouso, com algoritmos fortes e gestão de chaves.

Causa inventada — 3%. Um item apenas, mas o disfarce é eficiente: o uso de componentes com vulnerabilidades conhecidas “que resulta da desserialização de dados de fontes não confiáveis”. A categoria citada existe, mas sua causa é outra — biblioteca desatualizada ou com falha já publicada; desserialização insegura é falha de integridade de software e dados. Quando a oração explicativa aparece, confira se a causa é mesmo a que define o risco nomeado.

Erros clássicos

Achar que DAST vê o código. Não vê — é caixa preta, ataca de fora a aplicação que está rodando. Quem vê o código e não executa nada é o SAST. Item que dá ao DAST acesso ao código-fonte, ou que faz o SAST rodar contra a aplicação em execução, está errado pelo mesmo motivo.

Somar SCA às técnicas dinâmicas. SCA não executa nem analisa o seu código: ele confere a lista de bibliotecas de terceiros contra bases de vulnerabilidades conhecidas. É a frente de cadeia de fornecimento, e é a resposta certa quando o item fala em CVE, NVD, versão desatualizada ou SBOM.

Confundir quebra de autenticação com quebra de controle de acesso. A primeira é quem você é — sessão, senha e chave comprometidas, o atacante assume a identidade da vítima. A segunda é o que você pode — o usuário autenticado age fora das permissões. IDOR pertence à segunda.

Tratar o Top 10 como norma obrigatória. É documento de conscientização, um ponto de partida. Quem faz papel de padrão verificável é o ASVS, e quem mede maturidade de processo é o SAMM.

Esperar que a varredura automatizada ache tudo. Ela acha injeção, componente desatualizado e erro de configuração. Falha de lógica de negócio e controle de acesso quebrado só aparecem em teste manual — é exatamente por isso que existe pentest.

Achar que o pentest cabe no começo do desenvolvimento. Ele precisa de uma aplicação suficientemente pronta para ser atacada; cedo demais, o laudo não diz nada. O que vai para o começo do ciclo é o SAST e o SCA — shift-left.

Supor que WAF corrige a vulnerabilidade. Ele filtra a requisição na camada de aplicação e compra tempo; o defeito continua no código até alguém consertá-lo.