Como Integrar a Trend Micro Cloud One à segurança do seu CI/CD Pipeline usando GitHub Actions
Atualmente, CI/CD pipelines são essenciais para garantir a agilidade dos negócios e o sucesso de muitas empresas. As equipes de DevOps estão mudando sua abordagem no desenvolvimento de software, para uma mentalidade voltada à nuvem e à adoção de APIs. Como resultado, as equipes agora podem usar várias ferramentas e implantar seus softwares em diferentes ambientes. Realizar mudanças ou adicionar novas integrações não são mais um problema e permite que seus aplicativos aproveitem os muitos serviços e/ou recursos que os provedores de nuvem têm para oferecer.
Implementar a segurança de pipelines de CI/CD é um requisito óbvio, já que hoje é uma das prioridades dos times de DevOps. A execução, entretanto, não é um processo tão simples. A implementação de segurança em CI/CD pipelines é a melhor abordagem para proteger qualquer software moderno: quanto antes sua equipe identificar novos bugs ou vulnerabilidades no código, mais fácil será para consertá-los. Aguardar até que o aplicativo seja implantado em produção torna muito mais difícil implementar quaisquer alterações e corrigir bugs.
As seguintes ferramentas irão auxiliar as equipes de DevOps a ter maior visibilidade em relação às deficiências no seu código e, também, ajudar a priorizar vulnerabilidades mais importantes, investindo menos tempo em corrigir bugs não críticos, a fim de reduzir os riscos de segurança das aplicações de uma maneira geral.
Segue abaixo o artigo do meu amigo Fernando Cardoso, que explica em detalhes mais ferramentas de segurança de CI/CD pipelines:
https://medium.com/swlh/how-to-integrate-security-on-the-devops-pipeline-e36dea836d7b
A melhor forma de entender como esses conceitos são aplicados na vida real é colocando a mão na massa. Então, vamos criar alguns containers e escaneá-los no pipeline.
A arquitetura é bem simples: temos um repositório de código, um sistema automatizado de CI/CD, um registro, e uma plataforma para implantar a aplicação (neste artigo não irei cobrir a fase de implantação, talvez no próximo artigo 🤞). Vamos criar o container do zero, incluir no registro e escaneá-lo para checar quantas vulnerabilidades eu, ou minha equipe, introduzimos nessa nova aplicação.
Para começar, irei usar GitHub como meu repositório de código e GitHub Actions como meu sistema de CI/CD, pois são integrados – e muito fáceis de usar – e, para escanear meu novo container irei usar Trend Micro Cloud One™Container Security (antes chamado Deep Security Smart Check), pois me garante que irei ter visibilidade de problemas de segurança antes de implantar qualquer aplicação no ambiente de produção: posso checar por malwares (Arquivos Maliciosos), Vulnerabilidades, Segredos, Compliance e, ainda, bloquear meu pipeline de mover minha aplicação para produção, caso encontre qualquer problema no meu código.
Arquitetura Base do nosso CI/CD Pipeline
Obs.: Estou usando o AWS ECR como meu registro, mas o mesmo processo se aplica para Microsoft Azure, Google Cloud ou qualquer outro provedor de cloud pública com um registro baseado em Docker ou até mesmo um ambiente local. 👍
Criei um repositório público no GitHub chamado Trend-Micro-Container-Security-for-CI-CD. Nele existe um Dockerfile que irei usar para construir meu container e alguns outros arquivos necessários para que a aplicação funcione. Vou começar utilizando GitHub Action para rodar a primeira build:
Para criar seu primeiro pipeline no GitHub Actions você precisa criar uma estrutura em pastas dentro do seu repositório no seguinte formato:
Meu-Repositorio/.github/workflow/pipeline.yml
My-Repo/.github/workflow/pipeline.yml
Dentro da pasta do workflow, você precisa criar um arquivo YML que represente o seu pipeline. Eu já tenho um criado no meu repositório:
https://gist.github.com/felipecosta09/0456df1c0e5e720be805e887a31a15c8
Obs.: Talvez você tenha notado que uma parte das variáveis do ambiente são, na verdade, segredos – a ideia é que seja mais legível e seguro para ser exposto na internet. Você deve, sempre, fazer uso de segredos para expor suas chaves e segredos.
As tarefas de Build, Tag e Push de containers já são conhecidas por todos que trabalham com pipelines de CI/CD, mas eu quero focar em como você pode escanear esses containers assim que estão prontos. A última parte do pipeline é onde vamos escanear o container. É uma ação simples que eu criei e publiquei no GitHub Marketplace para que você possa usar para escanear seus containers com facilidade sem gastar muito tempo, criando códigos e, o mais importante, você pode bloquear o avanço do pipeline, caso alcance o limite de problemas definido por você. Para usar esta ação você só precisa selecioná-la no Marketplace e incluir as informações solicitadas e pronto!
O mecanismo para escanear os container é baseado num container Docker que a equipe da Trend Micro criou para usar a API do Cloud One™ Container Security (Formerly Deep Security Smart Check) para iniciar um scan e checar seu status. Isso significa que você pode escanear containers em qualquer pipeline, não somente no GitHub Actions. Vou deixar o link do Marketplace para que você possa aprender como usar, quais tipos de informações você precisa fornecer e quais tipo de resultados esperar. Também criei exemplos de como usar essa ação com registros no Azure e AWS e, ainda, usando um comando Docker.
https://github.com/deep-security/smartcheck-scan-action
Para adicionar a Ação no seu pipeline, você pode copiar o código do Marketplace, ou pode editar o seu código YML do pipeline diretamente do site do GitHub, e ainda, você conseguirá pesquisar as ações da Marketplace.
Cloud One Container Security Scan Action Code
De volta ao pipeline, assim que você rodá-lo e fornecer as informações necessárias, a Ação deve começar a Build, Tag, Push e Escanear o container. No nosso caso, o Segundo job “Container_Scan” falhou ao terminar de escanear o container, assim identificamos:
- 1 malware (arquivo malicioso);
- 1 segredo exposto (chave privada);
- 156 vulnerabilidades (incluindo pacotes do sistema operacional e pacotes de terceiros);
- 13 checklists (falhamos nas conformidades PCI-DSS v3, HIPAA e NIST 800–190)
Resultados da Ação GitHub no Pipeline
Estão detalhadas as informações que você pode ver na console do Smart Check, incluindo os detalhes gerais do Scan e cada uma das camadas onde o Smart Check identificou problemas no nosso código:
Resultados do Scan no Console Smart Check
Malware encontrado (arquivo malicioso)
Segredo exposto (chave privada)
Vulnerabilidades (incluindo pacotes do sistema operacional e de terceiros)
Checklist de Compliance de PCI-DSS v3, HIPAA e NIST 800–190
Checklist PCI-DSS v3, HIPAA and NIST 800–190
Caso você esteja rodando um container baseado em Java, você também pode contar com uma checagem de dependências através de uma parceria com Snyk, que possui o maior banco de dados para vulnerabilidades em dependências de Open-Source. Abaixo há um exemplo de como isso é mostrado na Console Smart Check.
Snyk Vulnerability Results
Resultados de Vulnerabilidaes (Snyk)
Você pode ir na base de conhecimento do Snyk KB para saber mais sobre cada uma das vulnerabilidades e criar um Pull Request para cada uma delas.
Imagine quantas vulnerabilidades eu ou minha equipe poderíamos incluir numa nova ou antiga aplicação. Sem essas ferramentas, provavelmente nunca saberíamos. O fato de que podemos detectar e prevenir esses problemas desde a criação de um container para uma aplicação é uma das melhores práticas de segurança que você pode implantar no seu pipeline DevOps. O quanto mais você mover mais para perto do desenvolvimento de código as responsabilidades de segurança, maior será a confiabilidade e menor serão os riscos de segurança – de uma forma geral.
Referencias:
https://www.github.com/deep-security/smartcheck-scan-action
https://www.trendmicro.com/containers
https://www.github.com/felipecosta09/Deep-Security-Smart-Check-Scan-Action
https://www.github.com/marketplace/actions/deep-security-smart-check-scan-action
