Antes de começar, vamos alinhar as expectativas e conceitos, primeiro nesse artigo, viso explicar uma forma de se abordar DevSecOps (Desenvolvimento, segurança e Operação), ao ciclo de desenvolvimento de software, e a sua esteira ou processo de DevOps.

Bem, provavelmente quando você ler DevOps (Desenvolvimento e Operação integradas, com o foco de diminuir o tempo de entrega de um software) ou DevSecOps (Adicionar segurança ao DevOps), logo se pensa em pipeline, CI/CD, automações ou até mesmo alguma ferramenta, mas tanto DevOps quando DevSecOps são culturas e não ferramentas, a ideia em si é compartilhar responsabilidades no ciclo de desenvolvimento de um software para diminuir atritos entre times e tempo para entrega de um projeto.

Então, já que não é necessariamente uma ferramenta, como que tem até vaga com título DevOps/DevSecOps, e são profissionais disputados, bem, aqui vou descrever 3 etapas cruciais para se aderir segurança ao seu processo de DevOps.

1. Processos Link para o cabeçalho

Primeiro de tudo, defina os processos, parece o menor dos problemas quando se fala em DevSecOps, mas sem um processo bem desenhado e definido a automação começa a perder as suas vantagens, que são qualidade e confiabilidade. Imagine que você tem uma pipeline que entrega um software em uma cloud publica, o processo é simples, você sobe um commit para um repositório git, que aciona uma ação no seu pipeline que por sua vez, buildar, testa, faz uma análise de segurança estática e faz o deploy da sua versão no ambiente desejado, parece perfeito, correto?

Em um cenário ideal, o exemplo da pipeline acima é perfeito, tudo flui, levando para contexto real, nem todos os projetos possuem testes, muitos projetos terão códigos vulneráveis, o deploy pode causar impacto para clientes, além de outras N etapas que se colocam em uma pipeline. Mas aí você está pensando, a casos e caso, correto? Ai onde a cultura DevSecOps pode ajudar a sua pipeline a ser uma ferramenta de qualidade e não de limitação ou block, lembre-se que a ideia é compartilhar a responsabilidade com o time de desenvolvimento, vai dizer que você nunca ficou com aquela ânsia quando ver o estágio(os) de segurança na pipeline.

2. Shift left Link para o cabeçalho

Melhor estratégia para compartilhar a responsabilidade com a equipe de desenvolvimento, em resumo o objetivo é trazer a segurança para o início do processo de desenvolvimento de software. Imagine o estágio de segurança rodando na IDE do desenvolvedor em tempo real, validando tudo que ele está implementado, um sonho?

Se ainda não ficou claro a necessidade do shift letf, imagine você desenvolver um software, sem realizar build, sem rodar testes e sem validar as dependências. Antes de comentar, sei que tem muito lugares que o exemplo acima é real, onde o desenvolvedor mal consegue buildar o projeto local, mas imagine o tempo para realizar essa entrega? Imagine quantos commits só para fazer uma simples entrega de funcionalidade de um software, e cada commit tem N estágios que o desenvolvedor só vai descobrir se atende ou não os requisitos no momento de esteira.

O shift left da segurança vai da mais autonomia sobre o planejamento, antes no cenário acima o time só teria visibilidade dos problemas na etapa de entrega, que é a final, e ninguém quando tem a bola do pênalti, quer ter no lugar do goleiro tem um muro “Gate de Sec”.

3. Framework de desenvolvimento seguro Link para o cabeçalho

Bem, essa parte é onde o time de segurança deve atuar mais fortemente, nem todo desenvolvedor vai ter conhecimento necessários para corrigir ou mitigar uma vulnerabilidade. E por outro lado, o time de segurança não escala, você vai sempre um número limitado de colaborares, e aí? se correr o bicho pega, se ficar o bicho come?

Defina um framework para que todos devem seguir, esse framework deve ser bem documentado e de fácil acesso para que todos tenham acesso. E você deve levar em consideração algumas features, a primeira dela é uma calculadora de risco de uma aplicação, exemplo OWASP Risk Assessment Framework, com ele você vai dar visibilidade do risco que cada aplicação, e vai dá a possibilidade e métricas para qual problema atacar primeiro (antes que os h4ckers ataquem), segunda feature do seu framework tem que ser a modelagem de ameaça, garanto que quando você vai desenvolver uma aplicação você pensa em qual linguagem, quais serviços, arquitetura, design patterns entre outras coisas (se você não pensa nessas coisas, comece a pensar!), mas e a lupa de segurança, porque quase nunca está associada na criação? Use a modelagem de ameaça para martela essa ideia, segurança tem que nascer junto a aplicação.

Agora imagine que você tem a pipeline, fez o shift left, criou um framework de desenvolvimento seguro com tudo fluindo, e mesmo assim não consegue obter bons resultados? Bem só relembrando as expectativas, a ideia aqui é como se aborda DevSecOps ao ciclo de vida de desenvolvimento de software SDLC, e cada caso é um caso, os 3 pontos que falei brevemente servem para se criar uma adesão de forma mais natural.

E não existe algoritmo para resolver todo problema de segurança, cada caso é um caso, além de existir outras formas de fazer essa aproximação de segurança com SDLC, como cursos (securtiy champions), fórum de discursão, exemplos de como fazer coisas corriqueiras de maneira segura, entre outras, enfim, já falei bastante.