Trazendo uma abordagem DevSecOps nos pipelines de aplicação e Infraestrutura

7 min readMay 31, 2021

No último post que fiz recentemente abordei o deploy completo da infraestrutura necessária para o AWS ECS via Terraform. Para um melhor entendimento do post de hoje recomendo a leitura deste anterior.

Dito isso, a ideia do post de hoje é discutirmos um pouco sobre DevSecOps na entrega tanto de aplicações quanto infraestrutura.

Uma breve introdução sobre DevSecOps

DevSecOps é um tema muito abordado atualmente, não é difícil encontrar conteúdo sobre isso através de uma rápida busca no Google, mas resumindo aqui, DevSecOps seria uma mudança na cultura dentro das organizações com relação a entrega de um produto seguro. É comum associarmos DevSecOps a segurança de aplicações somente, porém é algo um pouco mais complexo que isso.

O principal desafio é encaixar segurança no processo de desenvolvimento de forma orgânica e deixar claro para todos os envolvidos na entrega de um software que a segurança deve estar presente desde a sua concepção.

Como trazer o DevSecOps para a minha realidade?

Não existe resposta simples aqui, não tem formula mágica para resolver os problemas de segurança na entrega de software. O que existe são algumas práticas que podem ser incorporadas no processo de desenvolvimento que irão dar um maior controle sobre o estado de segurança.

O tal do Shift Left

O termo refere-se a ideia de trazer a esquerda, ou seja, trazer segurança para o inicio do processo de desenvolvimento. Quanto mais distante do inicio do processo de desenvolvimento é a detecção de falhas de segurança, maior será o custo de correção, dessa forma é preciso pensar em formas de munir os times de segurança, desenvolvimento e operações desde o inicio e tornar isso contínuo ao longo das demais etapas.

Para exemplificar a introdução acima, pegarei o projeto do post anterior e incluirei algumas etapas de segurança. A ideia é mostrar como podemos incorporar práticas de segurança sem criar um gargalo, ou qualquer tipo de bloqueio que acabe atrasando a entrega.

Topologia

Abaixo eu elaborei uma outra topologia a fim de exemplificar o ciclo de vida da aplicação que utilizei no projeto do post anterior:

Na topologia seguinte, as etapas de segurança que serão implementadas a fim de garantir um maior controle sobre as falhas e vulnerabilidades.

Vamos detalhar aqui cada controle de segurança que será implementado conforme a topologia apresentada acima.

Análise estática a nível de IDE

Existem alguns plugins que permitem a análise estática da linguagem que está sendo desenvolvida mesmo quando essa ainda nem foi enviada para um para um repositório remoto. Aqui nesse exemplo estou utilizando o plugin do HCL AppScan Code Sweep. Esse é um plugin de código aberto que me permite detectar algumas falhas de codificação que posso estar cometendo.

Nesse exemplo, eu utilizei o comando metodo console.log() na linha 7 para realizar alguns testes durante o desenvolvimento, no entanto, subir meu código para produção dessa forma pode abrir a brecha de vazamento de informações sensíveis uma vez que utilizei esse método justamente para visualizar quais objetos eram trazidos pelo método fetch().

Nota: Eu não sou desenvolvedor, por favor, perdão se cometi algmas gafes no trecho de código acima.

Neste link você pode conferir mais informações sobre HCL AppScan CodeSweep.

Uma vantagem em se adotar um plugin como este é que análise acontece num momento pré commit do código, ou seja, o tempo de correção tende a ser extremamente rápido, além disso, não há a exposição do colaborador. Normalmente análises estáticas a nível de IDE são locais, dessa forma o colaborador não precisa se preocupar com uma possível exposição, antes disso ele mesmo já pode corrigir o seu próprio código.

Análise estática no pós commit

Seguindo a nosso ciclo de desenvolvimento, o próximo controle de segurança que irei implementar ainda é uma análise estática, porém esta se dá numa outra etapa do processo: o commit.

A ideia é que a partir do commit (pull request, merge request, etc) para meu repositório remoto haja uma análise estática dos meus arquivos de maneira que possam ser encontradas vulnerabilidades antes da minha etapa de CI/CD.

Para garantir isso, utilizei o DeepSource. É uma plataforma de código aberto para repositórios públicos e também para até 3 repositórios privados. Ela me permite analisar estaticamente através de um painel centralizado possíveis falhas, bugs e vulnerabilidades existentes nos arquivos do meu repositório remoto.

Basta incluir na raiz do repositório um arquivo com a extensão .toml

Análise estática do repositório com DeepSource

Você pode conferir mais detalhes no site oficial da DeepSource

Segurança na etapa de CI/CD

Chegamos na etapa de integração contínua e entrega contínua. O projeto que estou utilizando de exemplo é uma simples página estática com javascript, o tópico anterior acabou cobrindo a análise estática do meu código. No entanto, é importante ressaltar que caso você esteja trabalhando com um projeto de linguagem compilada (.NET, Java, etc) deve-se pensar em incluir alguma ferramenta de análise estática pós build do projeto, ou seja, análise dos binários, dos artefatos do seu projeto. Essa análise é muito importante pois existem vulnerabilidades que só podem ser descobertas na etapa pós build.

Vale a pena dar uma olhada na página da OWASP que e hoje um dos maiores guias de segurança de aplicações que existe. A OWASP é um projeto de código abeto e possui algumas ferramentas que atuam na análise estática, interativa e dinâmica.

Claro que existem também ferramentas enterprise que realizam diversas análises na etapa de CI/CD. Irei destacar duas que na minha opinião são as melhores do mercado:

Checkmarx — https://www.checkmarx.com/
Veracode — https://www.veracode.com/

Certo, mas ainda sim preciso implementar algum controle de segurança na entrega do meu projeto. Apenas para recapitular, meu processo de CI/CD basicamente é o build de uma imagem docker e deploy da mesma no meu repositório ECR. Então irei habilitar um recurso do próprio ECR que é o scan da minha imagem Docker. Dessa forma, quando o push da imagem estiver sendo feito, o ECR fará uma análise de segurança na imagem e caso haja vulnerabilidades, essas serão expostas na própria console da AWS.

Para fazer isso, preciso habilitar essa função de scan. Como o deploy da minha infraestrutura foi realizado via código, preciso alterar um bloco de configuração do meu arquivo de ECR conforme imagem abaixo:

Assim que o push da imagem é concluído, já é possível visualizar os detalhes da análise na própria console da AWS.

vulnerabilidades da imagem do meu projeto

Pelo jeito não terei uma vida fácil na correção dessas vulnerabilidades!

Neste link você pode conferir com mais detalhes como habilitar essa feature do ECR. Vale ressaltar que essa feature é nativa do ECR e não há custos adicionais para habilitá-la, a não ser o próprio custo do ECR.

Segurança na Infraestrutura

Como comentado acima, o deploy da infraestrutura desse projeto foi realizado via Terraform. Infraestrutura como código já é um facilitador de segurança na infraestrutura por si só, pois como a infraestrutura está escrita e de certa forma documentada, da mesma maneira que fazemos análise estática para as aplicações é possível realizar uma análise estática do código da infraestrutura.

Para isso tive primeiro que criar um pipeline CI no Gitlab para deploy automatizado da infraestrutura via Terraform, um desses estágios faz a análise estática.

A imagem acima é um trecho do meu arquivo de pipeline, não coloquei ele completo aqui pois, é maior. Mas futuramente irei disponibilizar esse código num repositório publico bem como um projeto de exemplo.

A ferramenta que estou utilizando é o Terrascan, também de código aberto. Neste link você pode consultar mais detalhes sobre a ferramenta.

Aliás, existem algumas outras ferramentas que possibilitam a análise dos arquivos terraform. Vale apena dar uma olhada nessa comparação realizada dentre as ferramentas de análise de código de infraestrutura.

A análise do Terrascan nos mostra a seguinte saída quando existem falhas no nosso código:

Dependendo da maturidade do processo, é possível inclusive travar o deploy caso falhas de segurança estejam presentes:

Bom, então agora estou seguro?

Não mesmo! Nesse post eu procurei apresentar algumas maneiras de adicionar controles de segurança no processo de desenvolvimento e entrega de software, no entanto, encontrar as falhas é apenas o inicio do caminho.

Ainda existem outras análises segurança que podem ser reaizadas como IAST e DAST que se aplicam num contexto onde a aplicação já esta de certa forma concebida e as vulnerabilidades pode ser encontradas em tempo de execução.

É necessário relacionar todas as falhas encontradas, centralizá-las numa plataforma única, eliminar os falsos positivos e atacar as falhas que são mais críticas ao seu negócio. E esse trabalho é contínuo! Diariamente surgem novos vetores de ataque e é necessário estar atento a isso. Por isso a colaboração deve ser entre todos os times envolvidos.

Por hoje é só pessoal. Até mais!