Questão de Arquitetura de Software — Arquitetura de Software — FGV 2024
Arquitetura de Software›Arquitetura de Software
Código
fg091419
Banca
FGV
Órgão
Prefeitura de Nova Iguaçu - RJ
Ano
2024
Nível
Superior
Cargo
Analista Tributário do Tesouro Municipal
Um determinado órgão público tem requisitos extremamente críticos no que se refere a segurança dos seus sistemas.Indique a opção que descreve, dentro de uma metodologia de desenvolvimento de software, a forma correta de mitigar os riscos relativos à segurança no desenvolvimento do sistema.
AAplicar correção das vulnerabilidades durante a fase de implementação enquanto o código é escrito.
BDetectar todas as vulnerabilidades na fase de teste antes do lançamento.
CCriar um documento de análise de riscos relativos à segurança na fase de requisitos.
DResponder as vulnerabilidades conforme são descobertas em uso na fase de manutenção.
EDesenvolver um protótipo robusto que minimize riscos de segurança na fase de design do sistema.
Revelar gabarito e comentário▾
GabaritoC — Criar um documento de análise de riscos relativos à segurança na fase de requisitos.
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”.
Mitigação de Riscos de Segurança no Desenvolvimento de Software
Gabarito: letra C. A forma mais eficaz de mitigar riscos de segurança é tratá-los desde o início do ciclo de desenvolvimento, na fase de requisitos, por meio de uma análise de riscos formal. Isso permite identificar ameaças e definir controles antes mesmo da implementação, seguindo o princípio de "segurança desde a concepção" (security by design). As demais alternativas tratam a segurança de forma reativa ou tardia.
A banca testa o conhecimento sobre engenharia de software e boas práticas de segurança. O erro comum é achar que a segurança pode ser "adicionada depois", apenas em fases de teste ou manutenção. A abordagem correta é integrar a análise de riscos já na fase de requisitos, documentando vulnerabilidades e planejando mitigações.
Alternativa A — ❌ Incorreta
Afirma que a correção de vulnerabilidades deve ocorrer durante a implementação, enquanto o código é escrito. Essa é uma abordagem reativa e pontual, que não considera a segurança de forma sistêmica. A correção de vulnerabilidades no código é necessária, mas não substitui uma análise antecipada de riscos. A mitigação eficaz começa antes, na concepção.
Alternativa B — ❌ Incorreta
Diz que é necessário detectar todas as vulnerabilidades na fase de teste antes do lançamento. Embora os testes sejam importantes, detectar "todas" as vulnerabilidades é inviável e a abordagem reativa nos testes é tardia. A segurança deve ser planejada desde os requisitos, não apenas verificada no fim.
Alternativa C — ✅ Correta ⟵ GABARITO
Criar um documento de análise de riscos relativos à segurança na fase de requisitos. Essa é a prática recomendada por metodologias como Microsoft SDL (Security Development Lifecycle) e OWASP CLASP. A análise de riscos na fase de requisitos permite identificar ameaças, definir requisitos de segurança e planejar mitigação antes de qualquer codificação, integrando segurança ao processo desde o início.
Alternativa D — ❌ Incorreta
Propõe responder às vulnerabilidades conforme são descobertas em uso, na fase de manutenção. Essa é uma postura reativa e de alto risco, pois as vulnerabilidades já estão em produção, podendo ser exploradas. A manutenção corretiva deve ocorrer, mas não é a forma principal de mitigação.
Alternativa E — ❌ Incorreta
Desenvolver um protótipo robusto na fase de design. Embora o design seja importante, a análise de riscos deve vir antes, nos requisitos. Um protótipo robusto no design não substitui a identificação documentada de riscos e a definição de controles. A segurança deve ser tratada como requisito, não como característica do protótipo.
NÃO CAIA NESSA!
A banca confunde o candidato com alternativas que abordam fases posteriores do ciclo (implementação, teste, manutenção) ou ações reativas. A chave é lembrar que a análise de riscos é uma atividade da fase de requisitos, não de design ou implementação. A segurança precisa ser planejada antes de qualquer código ser escrito.