Como criar um pipeline de CI/CD com foco em segurança

Integração contínua (CI) e entrega contínua (CD) se tornaram práticas comuns entre as equipes de DevOps. O processo de CI/CD se concentra na criação e implantação de novos aplicativos ou no lançamento de atualizações para cargas de trabalho já implantadas. Por isso, a maioria das iniciativas de CI/CD busca acelerar o desenvolvimento. 

No entanto, as práticas de CI/CD podem fazer muito mais do que viabilizar a implantação de cargas de trabalho. Por exemplo, também podemos usar CI/CD como um pipeline com foco em segurança, que submete o código a testes de segurança, verifica o código-fonte em busca de vulnerabilidades e executa outras verificações essenciais antes da implantação dos componentes do aplicativo.

Como é um pipeline de CI/CD com foco em segurança

Vamos começar visualizando o pipeline de CI/CD como um fluxo linear, que vai do desenvolvimento à operação.

Os desenvolvedores começam pelo processo de build e, em seguida, enviam o código para um sistema de controle de versão, como o Git. O código é validado e empacotado; depois, o arquivo do pacote — como um Webdeploy.zip para .NET ou uma imagem de contêiner do Docker — é publicado no ambiente de execução de destino (por exemplo, um host do Docker ou um ambiente Kubernetes). Em seguida, as equipes de operações assumem o controle e gerenciam o ambiente.

Com isso em mente, vamos considerar como o conceito de otimização da segurança em CI/CD chamado “shift left” pode mudar esse processo ao incorporar práticas de segurança ao longo de todo o ciclo. No contexto da segurança, shift left é o processo de integrar a conscientização sobre segurança o mais cedo possível no ciclo de DevOps e mantê-la em todas as etapas do processo. 

No entanto, é importante observar que a maior parte das orientações sobre shift left parte de um conceito geral: aproximar do implementador qualquer preocupação de DevOps (testes, automação operacional e segurança). O objetivo dessa mudança é fechar o ciclo de feedback e dar visibilidade mais rápida aos resultados das alterações nessas áreas. 

A maioria das organizações já está antecipando outros ciclos de processos de DevOps dessa forma, mas encontra dificuldades ou não consegue fazer o mesmo com a segurança. Por isso, surgiu o termo DevSecOps, para destacar a importância de incluir a segurança nas práticas de DevOps.

Vamos analisar alguns recursos de segurança comuns que podemos integrar à estrutura de cada pipeline de CI/CD.

Como mostra este diagrama, é possível estabelecer um fluxo de CI/CD com foco em segurança sem alterar o próprio processo de CI/CD. A adoção desse tipo de fluxo voltado à segurança permite que as equipes de DevOps integrem recursos de segurança a cada ciclo de CI/CD. 

Vamos analisar com mais detalhes alguns dos principais aspectos de segurança mencionados no diagrama, os componentes que podemos incorporar a um pipeline de CI/CD e os benefícios de segurança que eles oferecem. 

Modelagem automatizada de ameaças

As ferramentas de modelagem de ameaças analisam aplicativos em busca de falhas de segurança conhecidas, vulnerabilidades e outros riscos. Elas ajudam as organizações a identificar, reconhecer e prever ameaças, além de apoiar decisões proativas para evitá-las ou mitigá-las. 

A modelagem de ameaças aparece como a primeira etapa do nosso diagrama de pipeline de CI/CD, mas costuma ocorrer antes do início do desenvolvimento. O ideal é repeti-la em diferentes etapas de CI/CD — e é aí que uma abordagem automatizada de modelagem de ameaças se torna útil. 

Lista de materiais de software

Cada vez mais desenvolvedores de código-fonte usam código criado por outras pessoas. Por isso, pode ser difícil acompanhar recursos — como trechos de código aberto, pacotes de software ou contêineres do Docker — ao longo do ciclo de vida de desenvolvimento de um aplicativo. É aí que uma lista de materiais de software (SBOM) pode ser útil.

A SBOM permite que as equipes de desenvolvimento cataloguem aspectos dos componentes de software, como a localização dos pacotes e suas dependências, e oferece visibilidade sobre os componentes de um aplicativo. Essas informações também permitem comparar os pacotes do aplicativo com vulnerabilidades de segurança conhecidas, ajudando a identificar onde e como usuários mal-intencionados poderiam explorar o código. Por esses motivos, as SBOMs se tornaram uma parte essencial dos pipelines de CI/CD com foco em segurança. 

Assinatura de artefatos

Muitas vezes, os desenvolvedores reutilizam artefatos em diferentes aplicativos para agilizar o processo. Em desenvolvimento de software, um artefato é qualquer software ou material relacionado a ele — como as SBOMs descritas anteriormente — que fornece recursos e funcionalidades ao longo do ciclo de vida de um aplicativo de software. 

Podemos considerar o resultado do build ou da compilação do código de desenvolvimento (o resultado da CI) um artefato. Outros artefatos comuns incluem pacotes NuGet para .NET, npm para desenvolvimento com Node.js e Maven para Java. Também podemos considerar scripts de PowerShell ou Bash como artefatos. 

Para proteger os ativos e garantir sua autenticidade, engenheiros de DevOps podem considerar assinar digitalmente o código-fonte que produzem. Essa assinatura digital é um requisito para desenvolvedores de aplicativos que usam plataformas de distribuição como a App Store da Apple e a Google Play Store. Uma assinatura digital vinculada a um certificado permite que quem recebe o código-fonte identifique a organização de origem do artefato. Ela também garante que nenhuma pessoa não autorizada tenha adulterado o código. 

No entanto, o processo de assinatura digital é complexo e exige lidar com certificados de infraestrutura de chave privada. Felizmente, podemos integrar uma ferramenta de automação ao pipeline de CI/CD para implementar assinaturas digitais. 

Testes unitários para validação de segurança

Os testes unitários permitem que os desenvolvedores validem a qualidade e o resultado de uma pequena unidade de software funcional. Esses testes garantem que cada parte do código funcione como esperado. Embora sejam usados principalmente para testar a integridade e a funcionalidade do código, também podemos usá-los especificamente para validar a segurança. 

Os testes unitários podem verificar cada trecho de código em busca de vulnerabilidades conhecidas identificadas pela análise de modelagem de ameaças, o que os torna úteis nesse processo. 

Análise de infraestrutura como código (IaC)

A infraestrutura como código (IaC) permite que as equipes de DevOps definam o estado final da infraestrutura necessária e a implantem usando uma abordagem baseada em modelos. Cada plataforma de nuvem pública oferece ferramentas proprietárias de IaC, como Azure (ARM Templates e Bicep), AWS (CloudFormation) e GCP (Deployment Manager). 

Para ambientes multinuvem, as organizações podem considerar uma solução multiplataforma como o HashiCorp Terraform, que elimina a complexidade de aprender a sintaxe de várias linguagens de modelo. Se a maioria da sua equipe de DevOps tiver experiência em desenvolvimento, uma solução como o Pulumi pode ser uma excelente alternativa. Em vez de fornecer modelos, o Pulumi usa bibliotecas de código e código de fato, com suporte a várias linguagens populares, como JavaScript, Python e DotNet. Ele também é compatível com diversas plataformas de nuvem.  

Os arquivos de modelo de IaC são semelhantes ao código-fonte de aplicativos: contêm componentes de definição, variáveis e links para outros artefatos. Por isso, também devemos aplicar à IaC todas as otimizações voltadas à segurança. Automatizar esses processos de segurança também é eficaz nesse caso. Por exemplo, o Snyk automatiza a análise de vulnerabilidades de segurança na IaC para ajudar as equipes de DevOps a identificá-las com rapidez e eficiência. 

Verificação automatizada de vulnerabilidades

A verificação de vulnerabilidades permite que engenheiros de DevOps integrem essa atividade ao processo do pipeline de CI/CD. Nesse contexto, ela geralmente assume a forma de teste estático de segurança de aplicativos (SAST) ou teste dinâmico de segurança de aplicativos (DAST). 

Primeiro, o SAST verifica o código-fonte em repouso e faz uma validação detalhada diretamente no controle de versão. Em seguida, outro processo de verificação de vulnerabilidades pode ser executado quando o código é compilado e integrado aos pacotes de software. Ele verifica o código-fonte do desenvolvedor em busca de ameaças à segurança e analisa detalhadamente outros pacotes, como contêineres do Docker ou bibliotecas de software. Por fim, o DAST é integrado quando o aplicativo é publicado e testa a segurança do aplicativo em execução. Sem verificar o código-fonte, ele simula as ações de um hacker ou usuário mal-intencionado para testar as defesas do código. 

Há várias ferramentas que ajudam a verificar o código ou automatizar essa verificação. Por exemplo, o Snyk oferece recursos avançados de segurança e análise de código para ferramentas e plataformas comuns de DevOps disponíveis atualmente. 

Segurança contínua 

Estes são alguns aspectos essenciais da integração de controles de segurança a cada ciclo de DevOps. Eles estão alinhados ao conceito de “shift left”, usado no setor para incentivar a integração dos controles de segurança o mais cedo possível no processo de DevOps. 

O resultado é uma prática de segurança contínua, que protege todas as etapas do ciclo de desenvolvimento. Estratégias como essas ajudam as equipes de DevOps a avançar ainda mais nas práticas de segurança e transformar desenvolvimento e operações (DevOps) em desenvolvimento, segurança e operações (DevSecOps). 

O DevSecOps reforça que devemos integrar mecanismos de validação de segurança no início do desenvolvimento e em todas as etapas de DevOps. Por exemplo, podemos começar com a modelagem de ameaças na fase de arquitetura, incluir a verificação de segurança no controle de versão e durante o build do código, e validar a segurança no lançamento e no ambiente de execução da carga de trabalho, quando ela estiver operacional.

A segurança contínua pode — e deve — ser parte integrante do gerenciamento do ciclo de vida do desenvolvimento de software. 

Como otimizar as práticas de CI/CD — e a segurança

Historicamente, os processos de CI/CD têm sido usados para otimizar a velocidade dos lançamentos de software. No entanto, eles também podem ser extremamente úteis quando integrados às práticas de segurança e ampliados para formar um pipeline de CI/CD com foco em segurança. Diante da evolução das ameaças cibernéticas e dos ataques, proteger o ciclo de vida do software exige uma abordagem de segurança mais ativa do que nunca. 

Entre as diretrizes de segurança úteis para equipes de engenharia de DevSecOps estão a modelagem automatizada de ameaças, as SBOMs, a assinatura de artefatos e a verificação automatizada de vulnerabilidades. Adotar estratégias como essas é uma forma de avançar rumo ao monitoramento contínuo da segurança. Assim, sua organização se beneficia de lançamentos de software mais rápidos e que incorporam as melhores práticas de segurança.