A empresa Bravo, que produz softwares, utiliza o modelo de desenvolvimento de software em cascata e dedica atenção à segurança do software apenas nas fases finais do ciclo de desenvolvimento. A equipe de analistas de sistemas da Bravo está adotando o princípio DevSecOps shift left security para tornar a programação dos softwares mais segura. Para aplicar o princípio shift left security no modelo de desenvolvimento de software em cascata, a equipe deve mover a preocupação proativa com a segurança do software para o início da fase de:
- A)análise de requisitos;
Correta, porque a segurança deve ser incorporada desde a análise de requisitos, quando ainda é possível definir necessidades e restrições de proteção.
- B)projeto;
Errada, porque o projeto já vem depois da definição dos requisitos, então a preocupação com segurança chega tarde para ser verdadeiramente proativa.
- C)codificação;
Errada, porque na codificação a solução já está sendo implementada, o que reduz a chance de prevenir problemas de segurança desde a origem.
- D)testes;
Errada, porque testes de segurança ajudam a detectar falhas, mas não substituem a antecipação da segurança no início do desenvolvimento.
- E)manutenção.
Errada, porque manutenção é a etapa mais tardia do ciclo e serve para corrigir e evoluir o sistema, não para iniciar a segurança de forma preventiva.
Gabarito: A
No modelo em cascata, as fases costumam seguir uma ordem bem linear: requisitos, projeto, codificação, testes e manutenção. Isso faz com que um erro de segurança descoberto no fim saia caro e dê mais trabalho para corrigir, quase como tentar trocar a fundação depois da casa pronta. Por isso, o DevSecOps com o princípio shift left security defende que a segurança seja pensada o mais cedo possível, e não só “lá na frente”. Na prática, “mover para a esquerda” significa antecipar a preocupação com segurança para as etapas iniciais do ciclo, especialmente quando as necessidades do sistema ainda estão sendo levantadas e definidas. É nessa fase que você consegue identificar requisitos de proteção, privacidade, controle de acesso, autenticação e outras necessidades de segurança antes que elas virem código ou retrabalho. Por isso o gabarito A está correto: a preocupação proativa com a segurança deve começar na fase de análise de requisitos. Se você deixa isso só para projeto, testes ou manutenção, já perdeu a chance de prevenir muita coisa e acaba apenas reagindo aos problemas. Em DevSecOps, a lógica é justamente prevenir desde o começo, em vez de remendar no fim.