Questão de Tecnologia da Informação · FGV CGE-SP 2025 (nº 71)

O conceito-chave aqui é que cada técnica de teste de segurança tem um ponto forte e um ponto cego. SAST analisa o código-fonte (estático), DAST testa a aplicação por fora (dinâmico), IAST combina os dois com instrumentação interna, e Fuzzing joga dados malformados para causar crashes. A pegadinha da banca é inverter as capacidades de cada técnica: elas trocam os pontos fortes e fracos entre si.

• (A) Incorreta: A afirmativa I é falsa porque SAST analisa o código-fonte sem executá-lo, então ele não entende o contexto de execução (como sessão de usuário ou permissões em runtime). Para detectar IDOR (quando você acessa o recurso de outro usuário mudando um ID na URL), o DAST é mais eficaz, pois ele executa a aplicação e testa acessos reais com diferentes credenciais.
• (B) Incorreta: A afirmativa I é falsa (como explicado acima) e a IV é falsa porque DAST depende de spidering (rastreamento de links) que não descobre todas as rotas de uma API REST, especialmente as que exigem autenticação ou métodos como POST/PUT. Sem documentação OpenAPI/Swagger, o DAST perde cobertura, e ele nunca é mais abrangente que SAST em cobertura de código (SAST vê 100% do código-fonte, DAST só o que é executado).
• (C) Correta: A afirmativa II é verdadeira: IAST instrumenta o código (insere sensores) e correlaciona a entrada com o fluxo real em runtime, o que reduz falsos positivos do SAST, mas o overhead (custo de performance) pode inviabilizar o uso em produção. A afirmativa III é verdadeira: Fuzzing é excelente para achar buffer overflow e use-after-free (erros de memória) em código compilado, mas é péssimo para lógica de negócio, pois ele não entende sequências de operações válidas (ex.: comprar item → pagar → receber).
• (D) Incorreta: A afirmativa II é verdadeira, mas a IV é falsa (DAST não descobre todas as rotas de API sem documentação e não é mais abrangente que SAST em cobertura de código).
• (E) Incorreta: A afirmativa III é verdadeira, mas a IV é falsa (DAST depende de documentação para APIs REST e tem cobertura de código inferior ao SAST).

Armadilha da banca (distrator mais tentador - letra A): A banca tenta te convencer de que SAST é "mais inteligente" por analisar o código, mas a pegadinha é que SAST não executa a aplicação. IDOR é uma falha de autorização que só aparece quando você testa com dois usuários diferentes em runtime. Quem cai na pegadinha pensa: "SAST vê o código, então vê a lógica do IDOR". Errado! O SAST vê o código, mas não sabe se o usuário A pode acessar o recurso do usuário B, porque isso depende de estado de sessão e permissões que só existem na execução.