Questão de Segurança da Informação — Testes de Segurança em Desenvolvimento (SAST e DAST) — VUNESP 2025

SAST (Static Application Security Testing) e a análise estática de código

Gabarito: letra C. O SAST é um teste de segurança estático, que analisa o código-fonte (ou bytecode/binários) antes da execução da aplicação, sem precisar colocá-la em funcionamento — por isso, exige acesso ao código-fonte. As demais alternativas confundem o SAST com outras técnicas (port scan, DAST, RASP) ou invertem a hierarquia entre os métodos.

O SAST (Static Application Security Testing) é uma técnica de teste de segurança que atua na fase de desenvolvimento do software, examinando o código-fonte, o bytecode ou os binários da aplicação sem executá-la. O objetivo é identificar vulnerabilidades, más práticas de codificação e falhas lógicas o mais cedo possível no ciclo de vida do desenvolvimento — é o chamado shift left, em que a segurança é deslocada para o início do processo. Por trabalhar diretamente sobre o código, o SAST requer acesso ao código-fonte, sendo classificado como uma análise de caixa-branca (white-box).

O contraste fundamental é com o DAST (Dynamic Application Security Testing), que é um teste dinâmico: a aplicação precisa estar em execução para que o analisador simule ataques externos e identifique falhas exploráveis. Enquanto o SAST olha "de dentro para fora" (o código), o DAST olha "de fora para dentro" (o comportamento da aplicação rodando). São métodos complementares e independentes — nenhum é subtipo do outro. Há ainda o IAST, que combina técnicas de SAST e DAST analisando a segurança enquanto a aplicação roda, e o RASP, que protege a aplicação em tempo real no ambiente de produção.

Na prática, um desenvolvedor que roda o SonarQube ou o Checkmarx sobre o repositório do projeto está fazendo SAST: a ferramenta varre o código, aponta trechos vulneráveis (como concatenação de SQL que permite injeção) e sugere correções — tudo antes de o software ser compilado e executado. Já o OWASP ZAP ou o Burp Suite, que atacam uma aplicação já implantada em um ambiente de testes, são exemplos de DAST. A pegadinha clássica da banca é inverter esses papéis ou afirmar que um é subtipo do outro.

Guarde a fronteira decisiva: SAST = código + antes da execução; DAST = aplicação em execução + simulação de ataques. É exatamente nesse par que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Confunde SAST com port scan (escaneamento de portas de rede abertas). O port scan é uma técnica de reconhecimento de rede, usada para mapear serviços disponíveis em um host — não tem relação com análise de código-fonte. O SAST não verifica portas; ele examina o código da aplicação.

Alternativa B — ❌ Incorreta

Descreve, na verdade, o RASP (Runtime Application Self-Protection), que atua com a aplicação em execução por meio de um agente embutido. O SAST, ao contrário, é realizado sem executar a aplicação — ele analisa o código de forma estática, antes da execução.

Alternativa C — ✅ Correta ⟵ GABARITO

O SAST é uma análise estática do código-fonte (ou bytecode/binários), realizada antes da execução da aplicação. Por isso, requer acesso ao código-fonte — é a característica central que o define como teste de caixa-branca. Ferramentas como SonarQube, Checkmarx e Veracode exemplificam essa categoria.

Alternativa D — ❌ Incorreta

Inverte a relação: o SAST não é um subtipo do DAST. São métodos independentes e complementares — o SAST é estático (código, antes da execução) e o DAST é dinâmico (aplicação em execução). Nenhum deriva do outro.

Alternativa E — ❌ Incorreta

Afirma o contrário da alternativa D, mas com o mesmo erro de hierarquia: o DAST não é subtipo do SAST. Ambos são técnicas distintas de teste de segurança de aplicações, cada uma com seu foco e momento de aplicação no ciclo de desenvolvimento.

Gabarito: letra C