O que é, afinal, DevSecOps? A segurança como propriedade do processo

DevSecOps é uma daquelas palavras que se esticam até deixarem de significar alguma coisa. Cola-se a um produto, a um cargo ou a um único scanner num pipeline. Sem o marketing, descreve algo simples e valioso: integrar a segurança na forma como o software é feito, em vez de a tratar como uma barreira no fim.

O problema que resolve

O modelo tradicional é uma revisão de segurança mesmo antes do lançamento: um especialista testa a aplicação acabada, entrega uma pilha de conclusões e a equipa corre para as corrigir sob a pressão dos prazos. Encontra problemas reais, mas no pior momento possível: quando são mais caros de corrigir e mais propensos a atrasar o lançamento. Pior ainda, é um instantâneo. No dia a seguir ao teste, o código novo começa a acumular novos riscos que ninguém está a vigiar.

O DevSecOps desloca as verificações para a esquerda, ou seja, mais cedo no processo, para o pull request e para o pipeline, de modo que os problemas são detetados à medida que surgem, quando são baratos de corrigir e ainda estão frescos na cabeça de quem os escreveu.

Como é na prática

Em concreto, num projeto conduzido desta forma, a segurança aparece em vários pontos, e nenhum deles trava a equipa:

• Análise estática (SAST) em cada alteração, afinada para que o sinal seja real e não uma parede de falsos positivos que toda a gente aprende a ignorar.
• Análise de dependências e da cadeia de fornecimento, com versões fixadas, para que uma biblioteca com uma vulnerabilidade conhecida seja assinalada antes de ser publicada, e não depois de aparecer nas notícias.
• Deteção de segredos no código e na CI, para que uma chave de API ou uma palavra-passe nunca chegue a entrar num commit.
• Pipelines de build reforçados, com passos de privilégio mínimo, dependências verificadas e artefactos assinados, para que o próprio pipeline não seja o elo mais fraco.
• Modelação de ameaças para novas funcionalidades, para que os riscos de conceção sejam detetados antes de serem construídos.
• Um teste de intrusão focado antes de cada versão importante, assente em tudo o que está acima em vez de carregar sozinho todo o peso.

O difícil não são as ferramentas

Qualquer equipa consegue aparafusar um scanner à CI. A diferença entre um DevSecOps que funciona e um DevSecOps de fachada está na afinação e na cultura. Um pipeline que inunda os programadores de falsos positivos ensina toda a gente a saltar o passo de segurança. Isso é pior do que não o ter, porque agora existe uma falsa sensação de segurança. A arte está em configurar as ferramentas para que as suas conclusões sejam fiáveis, correr as verificações rápidas em linha e as lentas em separado, e tratar a maioria dos resultados como informação para o autor e não como um bloqueio rígido.

A segurança deixa de ser uma revisão pontual e passa a ser uma propriedade do processo. Categorias inteiras de problemas são detetadas no merge, antes que alguém tenha de pensar nelas.

Substitui os testes de intrusão?

Não. Muda a sua finalidade. Quando os problemas de rotina já estão a ser detetados continuamente, um teste de intrusão deixa de ser uma caça frenética a erros e passa a ser o que deve ser: uma pessoa experiente à procura de falhas na lógica de negócio, lacunas no controlo de acessos e cadeias criativas que nenhum scanner encontra. As duas coisas reforçam-se. As verificações contínuas garantem a amplitude; a pessoa, a profundidade.

Por onde começar

Não precisa de adotar tudo de uma vez, e não deve. Comece pelos ganhos com mais impacto e menos atrito: deteção de segredos, para que as credenciais deixem de fugir, e análise de dependências, para saber que bibliotecas vulneráveis está a publicar. Acrescente SAST quando o tiver afinado. Integre a modelação de ameaças no trabalho novo. O que importa é a direção, não uma implementação de uma só vez: cada verificação que antecipa é um risco apanhado mais barato.

É esta a abordagem que aplicamos nos projetos que entregamos. Se quer que a segurança seja algo que o seu processo produz por omissão, e não algo acrescentado à pressa perto do prazo, é esse o trabalho, e teremos todo o gosto em ajudar a pô-lo em prática.