Questão de Segurança da Informação — NIST (National Institute of Standarts and Technology) — FCC 2026

Desenvolvimento Seguro de Software: Shift Left e o NIST SSDF

Gabarito: letra A. O NIST SSDF (Secure Software Development Framework) preconiza a integração de práticas de segurança ao longo de todo o ciclo de desenvolvimento de software (SDLC), e não apenas nas fases finais. A alternativa A captura exatamente esse princípio ao mencionar o "shift left" — a antecipação da segurança para as fases iniciais —, o que reduz custos, vulnerabilidades e o esforço de correção tardia. As demais alternativas contrariam essa lógica ao concentrar a segurança em etapas específicas e tardias, como testes finais, homologação ou produção.

O NIST SSDF (NIST SP 800-218) é um framework que define práticas de segurança para o desenvolvimento de software, organizadas em quatro grupos: Preparar a Organização (PO), Proteger o Software (PS), Produzir Software Bem Protegido (PW) e Responder a Vulnerabilidades (RV). A filosofia central é que a segurança não é uma fase isolada, mas um requisito contínuo que permeia todas as etapas do SDLC, desde a concepção dos requisitos até a manutenção e resposta a incidentes. Essa abordagem é conhecida como "shift left", pois desloca a segurança para a "esquerda" do ciclo de vida, ou seja, para o início do processo.

A lógica por trás do shift left é simples e econômica: quanto mais cedo um defeito (incluindo vulnerabilidades de segurança) é encontrado, mais barato e rápido é corrigi-lo. Corrigir uma vulnerabilidade na fase de requisitos ou design custa uma fração do que custaria corrigi-la em produção, após o software já estar em uso. Além disso, a segurança aplicada apenas no final tende a ser reativa e superficial, tratando sintomas em vez de causas. O SSDF, portanto, promove a segurança por design e a segurança por padrão, integrando práticas como modelagem de ameaças, análise de código estática e dinâmica, e testes de segurança contínuos.

Na prática, um Ministério Público que desenvolve seus próprios sistemas de auditoria deve, por exemplo, definir requisitos de segurança junto com os requisitos funcionais, realizar revisões de código com foco em segurança durante o desenvolvimento, e executar testes de segurança (como pentests e fuzzing) de forma contínua, não apenas na fase de homologação. A alternativa A reflete essa prática recomendada, enquanto as demais propõem abordagens reativas ou que isolam a responsabilidade da segurança, o que vai contra a filosofia do framework.

A pegadinha desta questão está em identificar qual alternativa representa a abordagem correta segundo o NIST SSDF. As alternativas B, C, D e E descrevem práticas que, embora possam ter algum valor em contextos específicos, não são a recomendação central do framework, que é a integração da segurança desde o início. A banca explora a tendência do candidato de aceitar práticas comuns (como auditorias externas ou testes na homologação) sem considerar o que o SSDF efetivamente preconiza. Guarde o conceito de "shift left" como o critério decisivo: a alternativa que antecipa a segurança para as fases iniciais é a correta.

Alternativa A — ✅ Correta ⟵ GABARITO

Esta alternativa está correta porque reflete o princípio do "shift left" do NIST SSDF. O framework preconiza que as práticas de segurança sejam integradas desde as fases iniciais do SDLC, e não apenas no final. Isso reduz custos, pois corrigir vulnerabilidades no início é mais barato, e reduz o esforço de correção tardia, pois problemas são identificados e tratados precocemente. A alternativa espelha diretamente a filosofia do SSDF de segurança contínua e proativa.

Alternativa B — ❌ Incorreta

Esta alternativa está incorreta porque isola a responsabilidade da segurança no time de QA, o que contraria o SSDF. O framework preconiza que a segurança é responsabilidade de toda a equipe de desenvolvimento, desde os desenvolvedores até os testadores, e não de um único time. Delegar exclusivamente ao QA cria uma abordagem reativa e fragmentada, em vez da integração contínua proposta pelo SSDF.

Alternativa C — ❌ Incorreta

Esta alternativa está incorreta porque concentra os testes de segurança na fase de homologação, o que é uma abordagem tardia. O SSDF preconiza que a segurança seja aplicada ao longo de todo o ciclo de desenvolvimento, não apenas em uma fase final. Esperar a homologação para testar segurança significa que vulnerabilidades podem ser descobertas tarde demais, aumentando custos e riscos.

Alternativa D — ❌ Incorreta

Esta alternativa está incorreta porque propõe auditorias externas apenas no produto pronto, o que é uma abordagem reativa e pontual. O SSDF preconiza a integração contínua da segurança durante o desenvolvimento, e não apenas uma avaliação externa no final. Auditorias externas podem ser complementares, mas não substituem a prática de segurança integrada ao SDLC.

Alternativa E — ❌ Incorreta

Esta alternativa está incorreta porque sugere aguardar o software estar em produção para usar logs de incidentes. Isso é uma abordagem totalmente reativa, que trata a segurança apenas após a ocorrência de problemas. O SSDF preconiza a prevenção e a integração da segurança desde o início, não a espera por incidentes para melhorar a próxima versão. Essa prática, embora possa ter algum valor, não é a recomendação central do framework.

Gabarito: letra A