Questão de Segurança da Informação — NIST (National Institute of Standarts and Technology) — CESPE / CEBRASPE 2025
Segurança da Informação›NIST (National Institute of Standarts and Technology)
Código
ce418110
Banca
CESPE / CEBRASPE
Órgão
TRF 6
Ano
2025
Cargo
AJ TRF6
A respeito do NIST – secure software development framework, julgue o item a seguir.
É recomendado que as organizações realizem revisões e testes de segurança focados apenas nos testes finais, pois essa conduta permite identificar e mitigar vulnerabilidades antes que o software seja lançado, aumentando a segurança do produto final.
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoE — Errado
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”.
NIST SSDF e a segurança no desenvolvimento de software
❌ ERRADO. A afirmação está incorreta porque o NIST Secure Software Development Framework (SSDF) recomenda que a segurança seja integrada em todas as fases do ciclo de desenvolvimento de software — não apenas nos testes finais. A abordagem correta é a de "segurança por design" e testes contínuos ao longo do processo, e não uma revisão concentrada apenas no final.
O NIST SSDF (Secure Software Development Framework) é um framework que define boas práticas para o desenvolvimento seguro de software. Ele estrutura-se em quatro grupos principais de práticas, que devem ser aplicados de forma contínua e integrada ao longo de todo o ciclo de vida do software:
Prepare the Organization (PO): estabelecer políticas e treinamentos de segurança.
Protect the Software (PS): implementar mecanismos de segurança para proteger todos os componentes do software.
Produce Well-Secured Software (PW): aplicar padrões seguros durante o desenvolvimento.
Respond to Vulnerabilities (RV): monitorar continuamente e responder rapidamente a falhas, identificando vulnerabilidades residuais.
A lógica por trás dessa abordagem é simples: quanto mais cedo uma vulnerabilidade é identificada, menor o custo e o impacto de sua correção. Testar apenas no final é arriscado, pois problemas estruturais podem passar despercebidos e exigir retrabalho extenso, além de aumentar a superfície de ataque do produto final. A segurança deve ser uma preocupação desde a concepção do software, passando pelo design, codificação, testes e implantação.
Na prática, isso significa que as organizações devem realizar revisões de código, testes de segurança (como análise estática e dinâmica), testes de penetração e outras atividades de verificação em múltiplos pontos do pipeline de desenvolvimento, e não apenas na fase final. O próprio SSDF enfatiza a importância de "testes contínuos em múltiplos pontos do pipeline, conforme evolução do produto".
A pegadinha da questão está em afirmar que os testes devem ser "focados apenas nos testes finais". Isso contraria diretamente o princípio de segurança integrada ao longo do ciclo de vida. A banca tenta induzir o candidato a aceitar uma prática inadequada como recomendada, quando na verdade o framework preconiza o oposto.
NÃO CAIA NESSA!
A banca inverte o conceito: em vez de segurança contínua em todas as fases, ela afirma que basta testar no final. O candidato que não conhece o SSDF pode achar que "testar antes do lançamento" é suficiente, mas o framework exige testes e revisões durante todo o desenvolvimento, não apenas no fim.
NIST SSDF: Abordagem correta (Segurança em todas as fases, Testes contínuos no pipeline, Segurança por design); Grupos de práticas (Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), Respond to Vulnerabilities (RV)); Testes apenas no final (Contraria o framework, Aumenta risco de falhas)
Item — ❌ Errado
A afirmação diz que "é recomendado que as organizações realizem revisões e testes de segurança focados apenas nos testes finais". Isso é falso segundo o NIST SSDF. O framework recomenda que a segurança seja incorporada em todas as etapas do ciclo de desenvolvimento, desde o planejamento até a manutenção. Testar apenas no final é uma prática inadequada, pois não permite identificar e mitigar vulnerabilidades de forma eficaz, aumentando o risco de o software ser lançado com falhas de segurança.