Questão de Segurança da Informação — DevSecOps — INSTITUTO AOCP 2024

DevSecOps: Integração de Testes de Segurança em Pipelines de CI/CD

Gabarito: letra B. No DevSecOps, a segurança é incorporada automaticamente em todas as fases do ciclo de vida do software, e os testes automatizados de segurança devem ser integrados à pipeline de CI/CD de forma que cada commit dispare análises de SAST, com resultados críticos bloqueando automaticamente a progressão da pipeline — é exatamente o que descreve a alternativa B. Essa prática reflete o princípio de shift left e a automação contínua, pilares do DevSecOps.

O DevSecOps (Development, Security e Operations) é uma abordagem que integra a segurança como responsabilidade compartilhada em todo o ciclo de vida da TI, permitindo o desenvolvimento de software seguro na velocidade do Agile e do DevOps. Diferentemente do modelo tradicional, em que a segurança é tratada apenas no final do processo, o DevSecOps incorpora a segurança desde o início, com automação e colaboração entre as equipes.

Uma das melhores práticas centrais é o shift left: mover a segurança da direita (final) para a esquerda (início) do processo de DevOps. Isso significa que os testes de segurança devem ser executados o mais cedo possível, idealmente a cada commit, para detectar vulnerabilidades precocemente e reduzir o custo de correção. A automação é essencial: os testes devem ser disparados automaticamente pela pipeline, sem intervenção manual, e os resultados críticos devem bloquear a progressão, impedindo que código vulnerável avance para as próximas fases.

As ferramentas de segurança no DevOps são complementares e atuam em diferentes momentos:

A pegadinha clássica da banca é inverter o momento de execução de cada ferramenta ou sugerir que a segurança deve ser tratada apenas no final do processo. Por exemplo, afirmar que o SAST deve ser executado após o deployment contraria o princípio de shift left; ou que o DAST deve ser executado antes de qualquer código ser integrado, quando na verdade o DAST exige a aplicação em execução. A alternativa correta (B) captura a essência: automação, detecção precoce e bloqueio automático de resultados críticos.

Guarde a fronteira entre o que é automação contínua e o que é intervenção manual ou execução tardia: é exatamente nela que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Afirma que o SAST deve ser executado apenas após a fase de deployment. Isso contraria o princípio de shift left: o SAST analisa o código-fonte antes da execução e deve ser executado o mais cedo possível, idealmente a cada commit, para detectar vulnerabilidades precocemente. Executar apenas após o deployment atrasa a detecção e aumenta o custo de correção, indo contra a filosofia do DevSecOps.

Alternativa B — ✅ Correta ⟵ GABARITO

Descreve corretamente a implementação: cada commit dispara análises de SAST, e resultados críticos bloqueiam automaticamente a progressão da pipeline. Isso reflete a automação contínua e o shift left, garantindo que vulnerabilidades sejam detectadas e corrigidas antes de avançar para as próximas fases. O bloqueio automático impede que código vulnerável seja integrado ou entregue, assegurando conformidade com as políticas de segurança.

Alternativa C — ❌ Incorreta

Afirma que o DAST é mais eficaz quando implementado na fase de desenvolvimento inicial, antes que qualquer código seja integrado ao repositório principal. O DAST é uma análise dinâmica que testa a aplicação em execução, portanto exige que a aplicação esteja rodando em um ambiente de testes. Executá-lo antes de qualquer código ser integrado é inviável, pois não há aplicação para testar. O DAST deve ser executado em ambientes de staging ou testes, após a aplicação ser construída e implantada.

Alternativa D — ❌ Incorreta

Afirma que os testes de segurança devem ser executados em paralelo com testes de regressão e performance para garantir que não atrapalhem os ciclos de desenvolvimento. Embora a execução em paralelo possa ser uma estratégia para otimizar o tempo, a justificativa apresentada é incorreta: os testes de segurança não devem ser configurados apenas para "não atrapalhar", mas sim para garantir a detecção precoce de vulnerabilidades. Além disso, a execução em paralelo não é uma regra obrigatória; o importante é que os testes sejam integrados à pipeline e que resultados críticos bloqueiem a progressão, independentemente de serem paralelos ou sequenciais.

Alternativa E — ❌ Incorreta

Afirma que o RASP é utilizado para proteger aplicações em tempo de execução e não é tipicamente integrado nas fases iniciais de CI, mas sim aplicado em ambientes de produção ou próximos a ele. Essa afirmação está correta em relação ao RASP: ele protege a aplicação em tempo real, detectando e bloqueando ataques enquanto ocorrem, e é aplicado em produção. No entanto, a alternativa é apresentada como uma descrição incorreta da implementação de testes de segurança, pois o RASP não é um teste automatizado de segurança, mas sim uma proteção em tempo de execução. A questão pede a alternativa que descreve corretamente como os testes podem ser implementados e integrados nas pipelines de CI/CD, e o RASP não se enquadra nesse contexto de testes automatizados.

Gabarito: letra B