Questão de Segurança da Informação — Ciclo de Vida de Desenvolvimento Seguro — FCC 2025

Desenvolvimento Seguro de Software: frameworks e boas práticas

Gabarito: letra D. A alternativa correta combina dois frameworks reconhecidos e complementares: o NIST SSDF (Secure Software Development Framework), que organiza práticas de segurança em todo o ciclo de vida do software (incluindo as práticas "Preparar a Organização" e "Proteger o Software"), e o OWASP Top 10, que cataloga as vulnerabilidades web mais críticas, servindo como guia para mitigação durante o desenvolvimento e os testes. As demais alternativas distorcem conceitos ou atribuem funções incorretas a metodologias e práticas de segurança.

O desenvolvimento seguro de software é uma abordagem que integra a segurança em todas as fases do ciclo de vida do software, desde a concepção até a manutenção, em vez de tratá-la como uma etapa final. O objetivo é reduzir vulnerabilidades e riscos de segurança desde o início, tornando o software mais robusto contra ataques. Diversos frameworks e metodologias foram criados para orientar essa prática, cada um com seu foco e abordagem.

O NIST SSDF é um framework do National Institute of Standards and Technology (NIST) que define um conjunto de práticas de alto nível para o desenvolvimento seguro de software. Ele é organizado em quatro grupos de práticas: Preparar a Organização (PO), Proteger o Software (PS), Produzir Software Bem Protegido (PW) e Responder a Vulnerabilidades (RV). O framework é agnóstico em relação a tecnologias e metodologias específicas, fornecendo um guia de boas práticas que podem ser adaptadas a diferentes contextos.

O OWASP Top 10 é um documento de conscientização (awareness) da Open Web Application Security Project (OWASP), uma fundação sem fins lucrativos dedicada a melhorar a segurança de software. Ele lista as dez categorias de riscos de segurança mais críticas para aplicações web, como Injeção (Injection), Falhas de Autenticação (Identification and Authentication Failures) e Exposição de Dados Sensíveis (Cryptographic Failures). O Top 10 não é uma norma completa, mas um guia essencial para priorizar esforços de mitigação durante o desenvolvimento e os testes.

A combinação do NIST SSDF com o OWASP Top 10 é uma prática comum e eficaz: o SSDF fornece a estrutura de processos, enquanto o Top 10 orienta sobre as vulnerabilidades específicas a serem tratadas. Essa abordagem integrada é exatamente o que a alternativa D descreve.

A banca explora, nas alternativas incorretas, a confusão entre os diferentes frameworks e práticas de segurança, atribuindo a cada um funções que não lhes pertencem ou distorcendo seus conceitos fundamentais. É essencial conhecer as características principais de cada metodologia (SDL, CLASP, SSDF, OWASP) e os princípios de segurança (como a validação no servidor, não no cliente) para identificar a alternativa correta.

Alternativa A — ❌ Incorreta

O CLASP (Comprehensive, Lightweight Application Security Process) é um guia de desenvolvimento seguro baseado em 24 atividades organizadas em 5 visões (Conceitual, Papéis, Avaliação de Atividades, Implementação de Atividades e Vulnerabilidades). Ele fornece orientações sobre como mitigar vulnerabilidades, mas não tem como eixo central a "configuração segura dos ambientes de hospedagem". Essa é uma prática de segurança operacional (hardening), não o foco do CLASP. A alternativa atribui ao CLASP uma função que não é a sua principal.

Alternativa B — ❌ Incorreta

A alternativa contém dois erros conceituais. Primeiro, menciona "Cross-Site Sculpting (XSS)", que não existe — o ataque correto é Cross-Site Scripting (XSS). Segundo, afirma que, com práticas de programação defensiva no código, "testes de segurança adicionais podem ser minimizados na etapa de validação". Isso é incorreto: a programação defensiva (como validação de entrada e tratamento de exceções) é uma camada importante, mas não elimina a necessidade de testes de segurança, que devem ser realizados ao longo de todo o ciclo de desenvolvimento, incluindo a fase de validação. Testes de segurança são complementares, não substituíveis por boas práticas de codificação.

Alternativa C — ❌ Incorreta

A alternativa afirma que "a autenticação no front-end garante a integridade dos dados transmitidos para o backend". Isso é falso por dois motivos. Primeiro, a autenticação (verificar quem é o usuário) não garante a integridade dos dados (garantir que os dados não foram alterados). Segundo, e mais importante, a segurança nunca deve ser confiada apenas ao front-end (client-side). A validação de entrada e o controle de acesso devem ser implementados no backend (server-side), pois o front-end pode ser facilmente contornado por um atacante. A regra de ouro é: "nunca confie no frontend; validação client-side é apenas UX, não segurança".

Alternativa D — ✅ Correta ⟵ GABARITO

A alternativa descreve corretamente a adoção do NIST SSDF, citando duas de suas práticas reais: "Preparar a Organização" (PO) e "Proteger o Software" (PS). Além disso, propõe complementar o SSDF com o OWASP Top 10 para mitigar as vulnerabilidades web mais críticas durante o desenvolvimento e os testes. Essa combinação é coerente e alinhada com as melhores práticas: o SSDF estrutura o processo de segurança, enquanto o OWASP Top 10 fornece o conhecimento específico sobre as vulnerabilidades mais comuns a serem tratadas. A alternativa está correta em todos os seus termos.

Alternativa E — ❌ Incorreta

O SDL (Security Development Lifecycle), criado pela Microsoft, incorpora a segurança em todas as fases do desenvolvimento, seguindo o modelo SD3+C (Secure by Design, Secure by Default, Secure by Deployment e Communications). A análise de ameaças (threat modeling) é uma atividade que ocorre principalmente nas fases de design e requisitos, mas a alternativa erra ao afirmar que "as atualizações posteriores de segurança ocorrerão por meio de patches de infraestrutura". Isso é uma visão limitada e incorreta: a segurança no SDL é contínua, e as atualizações de segurança do software em si (não apenas da infraestrutura) são parte do ciclo de vida. A manutenção e a resposta a vulnerabilidades são fases integrantes do SDL, não algo delegado apenas a patches de infraestrutura.

Gabarito: letra D