Pular para o conteúdo principal

Questão de Segurança da Informação — Análise de Vulnerabilidade e Gestão de Riscos — FGV 2026

Segurança da InformaçãoAnálise de Vulnerabilidade e Gestão de Riscos
Código
gp007225
Banca
FGV
Órgão
TJ-SC
Ano
2026
Cargo
Analista de Sistemas
Uma aplicação em produção foi comprometida por meio daexploração de uma biblioteca com CVE conhecido, que permiteexecução remota de código. O pipeline da aplicação possui SAST durante a fase dedesenvolvimento, DAST em ambiente de homologação e, ainda,possui monitoramento em produção. Após investigação, verificouse que a vulnerabilidade estava em uma dependência indireta, nãohouve alerta durante o pipeline e a exploração ocorreuimediatamente após o deploy. Com base nesse contexto, assinale a afirmativa que explicacorretamente a falha de detecção.
  1. AAusência de análise de composição de software (SCA) nopipeline para identificação de vulnerabilidades emdependências transitivas.
  2. BLimitação do SAST na análise de fluxos dinâmicos de execuçãoda aplicação.
  3. CDependência do DAST de cobertura de testes paraidentificação de vulnerabilidades exploráveis.
  4. DNatureza reativa do monitoramento em produção, voltada àdetecção pós-exploração.
  5. EAusência de testes funcionais capazes de exercitar cenários defalha na aplicação.
Revelar gabarito e comentário

GabaritoA — Ausência de análise de composição de software (SCA) no pipeline para identificação de vulnerabilidades em dependências transitivas.

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

Segurança da Informação – Análise de Vulnerabilidades

Gabarito: letra A. A falha de detecção ocorreu porque o pipeline não possuía uma ferramenta de Análise de Composição de Software (SCA), que é a responsável por identificar vulnerabilidades conhecidas (CVE) em dependências diretas e, principalmente, em dependências transitivas (indiretas). SAST analisa código-fonte estático, DAST testa a aplicação em execução e o monitoramento em produção é reativo — nenhum deles é capaz de detectar uma biblioteca com CVE em uma dependência indireta que não foi explicitamente incluída no código.

Ferramenta / Prática

Função Principal

Consegue detectar CVE em dependência indireta?

Explica a falha do caso?

SCA (Análise de Composição de Software)

Inventariar dependências (diretas e transitivas) e verificar CVEs conhecidos

Sim

Sim (ausência dela é a causa)

SAST (Análise Estática)

Analisar código-fonte em busca de vulnerabilidades de codificação

Não (foco no código próprio)

Não

DAST (Análise Dinâmica)

Testar a aplicação em execução contra vulnerabilidades exploráveis

Não (não correlaciona com banco de CVEs)

Não

Monitoramento em produção

Detectar atividades suspeitas após a exploração

Não (reativo)

Não

1SAST (desenvolvimento)
Código-fonte estático
Não detecta dependências
2DAST (homologação)
Aplicação em execução
Não correlaciona CVEs
3SCA (ausente)
Dependências diretas
Dependências transitivas
Detecta CVEs conhecidos
4Monitoramento (produção)
Reativo
Pós-exploração
Pipeline de segurança
LEVELsoulevel.com.br
Pipeline de segurança: SAST (desenvolvimento) (Código-fonte estático, Não detecta dependências); DAST (homologação) (Aplicação em execução, Não correlaciona CVEs); SCA (ausente) (Dependências diretas, Dependências transitivas, Detecta CVEs conhecidos); Monitoramento (produção) (Reativo, Pós-exploração)

Alternativa A — ✅ Correta ⟵ GABARITO

A ausência de SCA no pipeline explica diretamente o fato de a vulnerabilidade em uma dependência indireta não ter sido alertada. SCA é a prática específica para inventariar e verificar componentes de software (incluindo os transitivos) contra bancos de dados de vulnerabilidades como o NVD, que cataloga CVEs. Sem essa análise, mesmo que o CVE seja conhecido, o time não é notificado.

Alternativa B — ❌ Incorreta

O SAST analisa fluxos estáticos do código fonte, mas não é projetado para detectar vulnerabilidades em dependências de terceiros. A limitação apontada (fluxos dinâmicos) não é o problema central — mesmo um SAST perfeito não encontraria uma CVE em uma biblioteca indireta, a menos que o código fonte da biblioteca também fosse analisado. O erro aqui é confundir a finalidade do SAST.

Alternativa C — ❌ Incorreta

DAST testa a aplicação em funcionamento, mas depende de cobertura de testes para encontrar vulnerabilidades exploráveis. No entanto, o problema não é falta de cobertura: a vulnerabilidade estava em uma dependência indireta que, mesmo sendo exercitada, não seria identificada como um CVE conhecido pelo DAST, a menos que o DAST tivesse um mecanismo de correlação com bases de CVE. A afirmação não explica por que o alerta não ocorreu.

Alternativa D — ❌ Incorreta

O monitoramento em produção é inerentemente reativo — ele detecta atividades suspeitas após a exploração. A questão é que a detecção falhou antes do deploy, pois o pipeline não alertou. O monitoramento não é o responsável pela detecção prévia; sua natureza reativa não é a causa primária da falha. A ausência de SCA é anterior a qualquer monitoramento.

Alternativa E — ❌ Incorreta

Testes funcionais visam validar o comportamento esperado da aplicação, não identificar vulnerabilidades de segurança em dependências. Mesmo que existissem testes cobrindo cenários de falha, eles não substituem uma análise de composição de software para detectar CVEs em bibliotecas de terceiros.

PEGA ESSA DICA!

Decore o papel de cada ferramenta no pipeline de segurança: SAST (código estático), DAST (aplicação em execução), SCA (dependências de software), IAST (análise interativa), RASP (proteção em tempo de execução). Para vulnerabilidades em bibliotecas de terceiros, a ferramenta obrigatória é o SCA.

Link permanente: /questoes/gp007225