Questão de Segurança da Informação — Práticas de Segurança e Ameaças em Programação — VUNESP 2025

SAST (Static Application Security Testing)

Gabarito: letra E. O SAST é uma técnica de análise estática que examina o código-fonte, bytecode ou binário antes da execução, com o objetivo de detectar vulnerabilidades de segurança ainda na fase de desenvolvimento, antes que o software vá para produção. As demais alternativas distorcem características essenciais dessa técnica, confundindo-a com testes dinâmicos (DAST), com análise de código de máquina ou com propriedades que ela não possui.

O SAST (Static Application Security Testing) é uma abordagem de análise estática de segurança. Isso significa que a ferramenta examina o código-fonte (ou bytecode/binário) sem executar o programa, procurando por padrões de código que indiquem vulnerabilidades conhecidas, como injeção de SQL, cross-site scripting (XSS), buffer overflow, entre outras. O grande valor do SAST está em permitir a detecção precoce de falhas, no chamado "shift left" — ou seja, deslocar a segurança para o início do ciclo de desenvolvimento, quando corrigir um problema é mais barato e menos arriscado.

A principal distinção que a banca explora é entre SAST e DAST (Dynamic Application Security Testing). Enquanto o SAST analisa o código estaticamente (sem rodar), o DAST testa a aplicação em execução, simulando ataques externos, sem precisar acessar o código-fonte. Essa diferença é fundamental: o SAST é considerado um teste de caixa branca (white-box), pois tem acesso total ao código; o DAST é um teste de caixa preta (black-box), pois enxerga apenas o comportamento externo da aplicação. O contexto de apoio reforça essa distinção ao apresentar a tabela comparativa: "SAST | White-box (Caixa Branca). 'Às claras' | Durante o desenvolvimento | Sim" e "DAST | Black-box (Caixa Preta). 'No escuro' | Com a aplicação em execução | Não".

Outro ponto importante é que o SAST não é imune a falsos positivos. Como a análise é feita por padrões e heurísticas, é comum que a ferramenta aponte vulnerabilidades que, no contexto real do código, não são exploráveis. Por isso, os resultados do SAST precisam ser revisados manualmente. Além disso, o SAST pode e deve ser integrado a pipelines de CI/CD (Integração Contínua/Entrega Contínua) no contexto de DevOps e DevSecOps, automatizando a verificação de segurança a cada commit ou build. Ferramentas como SonarQube, Checkmarx e Veracode são exemplos clássicos de SAST que se integram perfeitamente a esses fluxos.

Por fim, é preciso destacar que o SAST não se limita a linguagens compiladas. Embora a análise de bytecode ou binário seja comum em linguagens como Java e C/C++, o SAST também se aplica a linguagens interpretadas (como Python, JavaScript, PHP), pois a análise é feita sobre o código-fonte, que existe independentemente de ser compilado ou interpretado. A banca, ao afirmar que o SAST "não se aplica a programas baseados em linguagens interpretadas", comete um erro conceitual grave, pois a análise estática não depende da execução nem da compilação.

Guarde a fronteira entre análise estática (SAST) e análise dinâmica (DAST): é exatamente nela que as alternativas desta questão se dividem. A alternativa correta (E) descreve com precisão o objetivo do SAST, enquanto as demais ou invertem essa lógica ou atribuem ao SAST características que pertencem a outras técnicas.

Alternativa A — ❌ Incorreta

Afirma que o SAST é um teste de "caixa preta" (black-box). Isso está errado: o SAST é um teste de caixa branca (white-box), pois analisa o código-fonte internamente, com acesso total à implementação. O teste de caixa preta é característico do DAST, que testa a aplicação em execução sem conhecer o código interno. A banca inverteu os conceitos: quem não tem acesso ao código é o DAST, não o SAST.

Alternativa B — ❌ Incorreta

Afirma que o SAST não se aplica a linguagens interpretadas, pois seria baseado em análise de código de máquina. Isso é duplamente errado: (1) o SAST analisa o código-fonte (ou bytecode), não o código de máquina; (2) linguagens interpretadas (Python, JavaScript, PHP) também possuem código-fonte que pode ser analisado estaticamente. A análise estática não depende de compilação ou execução, portanto se aplica a qualquer linguagem.

Alternativa C — ❌ Incorreta

Afirma que o SAST é imune a falsos positivos. Isso é falso: como o SAST usa padrões e heurísticas para identificar vulnerabilidades, é comum gerar falsos positivos — apontamentos de problemas que, no contexto real, não são exploráveis. Por isso, os resultados exigem revisão manual. A alternativa confunde a característica de outra técnica: o IAST (Interactive Application Security Testing), que combina SAST e DAST, é que reduz falsos positivos ao analisar a aplicação em execução com contexto.

Alternativa D — ❌ Incorreta

Afirma que o SAST não pode ser integrado a pipelines CI/CD de DevOps. Isso é falso: o SAST é uma das ferramentas mais utilizadas em pipelines de CI/CD, justamente por permitir a automação da verificação de segurança a cada integração. Ferramentas como SonarQube, Checkmarx e Veracode são amplamente integradas a esses fluxos, no contexto de DevSecOps. A banca inverteu a realidade: o SAST é altamente integrável e recomendado para CI/CD.

Alternativa E — ✅ Correta ⟵ GABARITO

Afirma que o SAST propõe detectar vulnerabilidades no código-fonte antes que ele vá para ambiente de produção. Isso está correto e é a definição essencial do SAST: análise estática do código, antes da execução, para identificar vulnerabilidades de segurança. O contexto de apoio confirma: "O SAST (Static Application Security Testing) é uma abordagem de análise estática que examina o código-fonte, bytecode ou binário antes da execução, identificando vulnerabilidades sem a necessidade de rodar o programa." Essa detecção precoce é o objetivo central da técnica, permitindo correções antes do deploy.

Gabarito: letra E