Questão de Segurança da Informação — Análise de Vulnerabilidade e Gestão de Riscos — FGV 2026
Segurança da Informação›Análise de Vulnerabilidade e Gestão de Riscos
Código
fg133881
Banca
FGV
Órgão
TJ-RJ
Ano
2026
Nível
Superior
Cargo
Analista Judiciário - Tecnologia da Informação - Analista de Segurança da Informação
A empresa Beta, que trabalha com soluções para o setor educacional, está migrando seus sistemas para a nuvem e adotando práticas DevSecOps para garantir segurança desde o desenvolvimento até a operação. Durante uma reunião de planejamento, o CTO (Chief Technology Officer) da empresa Beta propôs integrar ferramentas de segurança diretamente no pipeline de CI/CD.Com base nas práticas DevSecOps, a ação alinhada com o modelo a ser implementada pela empresa Beta é:
Arealizar testes de segurança apenas após a aplicação estar em produção;
Bdelegar a responsabilidade de segurança exclusivamente à equipe de operações;
Cutilizar scripts manuais para validar segurança após cada ciclo de desenvolvimento;
Dintegrar ferramentas de análise de vulnerabilidades no pipeline de integração contínua;
Epriorizar velocidade de entrega sobre validações de segurança em ambientes de teste.
Revelar gabarito e comentário▾
GabaritoD — integrar ferramentas de análise de vulnerabilidades no pipeline de integração contínua;
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”.
DevSecOps e Integração de Segurança no Pipeline de CI/CD
Gabarito: letra D. No modelo DevSecOps, a segurança é incorporada desde o início do desenvolvimento, integrando ferramentas de análise de vulnerabilidades diretamente no pipeline de integração contínua (CI/CD). Isso permite identificar e corrigir falhas ainda na fase de desenvolvimento, antes da produção. As demais alternativas contradizem os princípios fundamentais do DevSecOps.
1Segurança desde o início (shift left)
2Automação de testes no pipeline
3Responsabilidade compartilhada (Dev+Sec+Ops)
4Correção antes da produção
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Realizar testes de segurança apenas após a aplicação estar em produção vai contra o princípio de "shift left" do DevSecOps, que preconiza testes contínuos desde o início do ciclo de desenvolvimento.
Alternativa B — ❌ Incorreta
Delegar a responsabilidade de segurança exclusivamente à equipe de operações fere o conceito de responsabilidade compartilhada ("security is everyone's job") e a integração entre desenvolvimento, segurança e operações.
Alternativa C — ❌ Incorreta
Utilizar scripts manuais para validar segurança após cada ciclo de desenvolvimento é ineficiente e não escala. O DevSecOps valoriza a automação de verificações de segurança no pipeline.
Alternativa D — ✅ Correta ⟵ GABARITO
Integrar ferramentas de análise de vulnerabilidades no pipeline de integração contínua está perfeitamente alinhado com as práticas DevSecOps, automatizando a detecção de falhas de segurança desde cedo.
Alternativa E — ❌ Incorreta
Priorizar velocidade de entrega sobre validações de segurança em ambientes de teste negligencia a segurança, o que é oposto ao objetivo do DevSecOps de equilibrar agilidade com segurança.
PEGA ESSA DICA!
Em questões de DevSecOps, busque sempre a alternativa que trate segurança como parte integrante do pipeline de desenvolvimento e automação, nunca como etapa isolada ou manual.