Segurança em Pipelines: Integrando práticas de segurança no CI/CD

Introdução à segurança em CI/CD - Apresentação

Apresentando o curso e o instrutor

Olá e boas-vindas ao curso de segurança em CACD da Alura. Eu sou Gustavo Rarato, analista de segurança da informação, e estou aqui para acompanhá-los nessa jornada.

Audiodescrição: Gustavo é um homem de pele branca, com cabelo castanho escuro. Ele está vestindo uma blusa cinza. Atrás dele, há uma parede branca com algumas cores.

Introduzindo a segurança em CICD

Primeiro, vamos realizar uma introdução sobre segurança em CACD. O que é a segurança em CACD? Precisamos entender o que significa a sigla CICD. O CI, Continuous Integration (integração contínua), refere-se ao processo de entregar, validar e testar o código a cada modificação no repositório de forma automática.

O CI possui dois conceitos: o Continuous Delivery, que é quando o software está pronto para ir para a produção ou para qualquer outro projeto, seja desenvolvimento, staging ou teste, mas necessita de um gatilho manual para realizar o deploy; e o Continuous Deployment (implantação contínua), que é o processo automático de deploy no ambiente de produção, teste ou staging, sem necessitar de um gatilho manual.

Exemplificando o uso de CICD

Por exemplo, se estamos desenvolvendo uma aplicação utilizando Node.js e o nosso CICD está programado para realizar somente até o build da imagem, ele faz todos os processos de testes e integração, e então realiza o build da imagem. Se há uma imagem Docker, por exemplo, pronta para ir para o ambiente de produção, mas não faz essa implantação automaticamente, trata-se de Continuous Delivery. Se automaticamente pegamos do registry, onde está a imagem Docker, como o Docker Hub, e enviamos automaticamente, fazendo a troca de versão no ambiente de staging, desenvolvimento ou produção, é o Continuous Deployment.

Portanto, o CICD é a automatização do processo de desenvolvimento e entrega de software. E por que a segurança em CICD é importante? Porque as vulnerabilidades podem surgir rapidamente a cada novo commit, com alguma dependência adicionada ou modificação de código. A automação acelera essas falhas, assim como acelera as entregas, especialmente em ambientes grandes, onde é difícil controlar e visualizar todos os commits.

Discutindo a importância da segurança no pipeline

A qualidade e segurança devem caminhar juntas em cada etapa do pipeline, e detectar falhas reduz custos com correções e incidentes em produção. O que queremos dizer com reduzir custos? Quando detectamos tardiamente uma vulnerabilidade em produção, por exemplo, há todo o custo de realizar essa alteração desde o início e voltar às etapas do desenvolvimento de software.

Vamos dar um exemplo. Se desenvolvemos um software com uma biblioteca embarcada vulnerável, com uma vulnerabilidade crítica e sem atualizações, já sem garantia de suporte, será necessário chamar a pessoa desenvolvedora novamente. Talvez ela não se lembre mais de todo o contexto do software, e precisará de tempo para reaprender o que precisa ser feito na aplicação, o impacto da alteração que fará na troca da biblioteca. Após realizar a troca, há todo o processo de testes e validações com a equipe de produto e qualidade, gerando uma cadeia que volta ao início e gera custos de horas, além de possíveis falhas nesse processo quando a detecção de vulnerabilidades é tardia.

Comparando DevOps e DevSecOps

Outro conceito importante de entender é o de DevOps e DevSecOps, e quais são as diferenças entre eles.

O foco principal do DevOps é a velocidade e entrega contínua, enquanto o DevSecOps foca na velocidade com ênfase em segurança. No contexto de segurança, o DevOps tem uma responsabilidade tardia, onde a pessoa profissional de segurança normalmente realiza testes e avaliações no ambiente de pré-produção, ou em ambientes que chamamos de staging ou produção, realizando testes e detecções. Já o DevSecOps é integrado durante todo o ciclo, desde o início até o final, garantindo segurança em todo o processo.

Explorando a integração de segurança no DevSecOps

A equipe de segurança, como mencionado, atua mais no final do processo no DevOps, quando já está nos ambientes, enquanto no DevSecOps, a atuação ocorre durante todo o ciclo, desde o primeiro commit até o final no ambiente. Em relação à automação, o DevOps possui estágios padrões no pipeline, como build, test e deploy, que são comuns. O DevSecOps, por sua vez, inclui todos esses estágios normais do pipeline, mas acrescenta mais estágios de segurança. Portanto, o DevSecOps é mais abrangente que o DevOps, incorporando segurança desde o início.

Analisando casos reais de falhas de segurança

Trouxemos alguns casos reais para ilustrar a importância dos testes de segurança e do DevSecOps. Um exemplo é o vazamento de chaves da Uber em 2016, quando pessoas desenvolvedoras acidentalmente cometeram e subiram para um repositório GitHub privado credenciais de um sistema. Hackers aproveitaram essas credenciais e conseguiram acessar 57 milhões de contas de usuários e motoristas da Uber. Isso resultou em uma multa para a Uber e uma tentativa fracassada de recuperar esses dados, negociando com os hackers para que devolvessem e apagassem os dados. Esse incidente poderia ter sido evitado com um simples estágio no pipeline que detectasse essas credenciais no código, permitindo revogação rápida e rotação das credenciais.

Outro caso ocorreu em 2018, envolvendo CryptoJacking via Docker no Gerboid. Uma imagem Docker disponível na internet continha um software malicioso que, ao ser implantado em um servidor, começava a minerar a criptomoeda Monero. As consequências incluíram aumento do processamento dos servidores, o que, para quem trabalha com Cloud, representa um custo significativo. Algumas empresas não monitoram esse aumento e só percebem o problema quando recebem a conta no final do mês, identificando uma situação inesperada no ambiente.

Concluindo sobre a importância da segurança em CICD

Em resumo, a segurança não deve ser um estágio final, mas sim funcionar durante todo o processo de CICD. As automações e validações de segurança reduzem riscos e custos. A cultura DevSecOps é essencial para construir um software seguro e resiliente. A segurança em CICD é um investimento estratégico, não um obstáculo. É importante que essa ideia fique clara: segurança em CICD é um investimento estratégico, não um obstáculo. Discutiremos mais sobre isso nas próximas aulas, destacando a importância de entender esses conceitos para que possamos transmiti-los às lideranças, seja em empresas ou em projetos pessoais, demonstrando o valor de trabalhar com segurança em todo o processo de CICD, agregando valor ao produto final, mitigando riscos e reduzindo custos. Essa é a reflexão que deixamos para a próxima aula.

Introdução à segurança em CI/CD - Objetivos da segurança em CI-CD

Discutindo a automação e seus riscos

Olá, pessoal. Na última aula, discutimos como a automação do caminho do código, desde a máquina da pessoa desenvolvedora até o ambiente de produção, teste ou desenvolvimento, pode trazer grande eficiência. No entanto, essa automação também pode acarretar problemas de segurança. Imagine um pipeline mal configurado, semelhante a uma esteira de produção aberta. Qualquer falha no código, vulnerabilidade, dependência maliciosa ou segredo no código pode ser empacotado e enviado diretamente para a produção sem que ninguém perceba. Por isso, precisamos ter em mente alguns objetivos, que é o que vamos aprender na aula de hoje.

Quais são esses objetivos? São detecção precoce, feedback rápido e prevenção de deploy inseguro. A detecção precoce é a resposta rápida. Quanto antes encontrarmos essas falhas, melhor. Ou seja, o ideal é que as falhas sejam identificadas o mais cedo possível. Quanto antes detectarmos, menor será o impacto. Corrigir antes custa menos do que ter uma detecção tardia dessas vulnerabilidades. Isso evita que código inseguro chegue ao ambiente de produção e cause impactos, como vazamento de dados, instabilidade no ambiente de produção ou falhas.

Explicando a importância do feedback rápido

A integração contínua permite esse feedback em tempo real, trazendo mais agilidade e confiança no deploy. Por exemplo, se uma pessoa desenvolvedora comete, por engano, as credenciais de um bucket da AWS no código da aplicação, o pipeline pode detectar esse segredo em algum estágio de secret scan, utilizando ferramentas como o GitLinks, que discutiremos em aulas futuras. Isso bloqueia o build e evita que essas credenciais sejam enviadas para o ambiente de produção, desenvolvimento ou até de staging. O token é rotacionado automaticamente, mitigando o risco de vazamento dos dados dos clientes. Esse é um fluxo ideal.

Outro exemplo é quando uma pessoa desenvolvedora comete uma credencial de uma API em um repositório Git e deseja remover essa credencial do histórico do repositório. Note a dificuldade de remover do histórico. É necessário refatorar o repositório, o que pode causar problemas, até mesmo embaralhar o histórico do Git, trazendo problemas de inconformidade.

Comparando detecção precoce com situações do cotidiano

A detecção precoce é como perceber que esqueceu o passaporte antes de chegar ao aeroporto. Ainda é possível procurá-lo em casa, voltar, pegar o passaporte e ir para o aeroporto. Se já estiver no momento do check-in, quase embarcando, pode até perder o voo, causando um prejuízo muito maior.

Um feedback rápido é uma ação imediata. Se a pessoa desenvolvedora comete algum erro, ela precisa ser alertada o mais rápido possível. Assim, pode corrigir falhas enquanto o contexto ainda está fresco. Ainda está trabalhando naquele projeto e sabe que, ao mexer naquele código, pode impactar outras funcionalidades. Portanto, tem em mente todos os aspectos que pode considerar na correção dessa vulnerabilidade ou falha, evitando o acúmulo de vulnerabilidades ao longo do tempo.

Evitando o acúmulo de vulnerabilidades

Ou seja, não acumulamos vulnerabilidades, evitando passar uma centena delas para a pessoa desenvolvedora, que teria que ficar alocada por semanas apenas analisando vulnerabilidades. Em vez disso, detectamos aos poucos e fornecemos um feedback rápido, permitindo que a pessoa desenvolvedora corrija e continue com outras demandas. Isso possibilita que testes de segurança contínuos e automáticos reduzam o tempo de exposição a riscos. Com esse feedback rápido, detectamos, por exemplo, no commit, antes mesmo de chegar ao ambiente, permitindo a correção e reduzindo o tempo de exposição ao risco, mantendo o ritmo ágil sem comprometer a segurança.

Um exemplo: uma pessoa desenvolvedora adiciona uma biblioteca não autorizada e com vulnerabilidades ao projeto, sem consultar o time de segurança para uma análise inicial. Essa análise verifica se as dependências da biblioteca têm vulnerabilidades, se o código possui falhas, se o repositório está ativo ou descontinuado, se a biblioteca tem uma comunidade ativa, e se há questões de licença que possam gerar custos ou bloqueios. O scanner de dependências detecta que a biblioteca inserida possui seis vulnerabilidades críticas e bloqueia sua utilização. O time de segurança pode então fornecer feedback para a pessoa desenvolvedora, que realiza a troca da biblioteca enquanto ainda está familiarizada com o contexto do projeto, tornando o processo mais simples do que se tivesse passado meses no desenvolvimento da aplicação.

Prevenindo deploy inseguro

A prevenção de deploy inseguro, ou risco em produção, não se limita a detectar o problema; é necessário bloqueá-lo antes que chegue à produção. Isso evita a exposição de falhas em tempo real, garante que o código validado e testado chegue à produção e cria barreiras automáticas para bloquear códigos vulneráveis. Aumenta a confiança da equipe e dos usuários, além de reduzir custos com multas e prejuízos à reputação.

Por exemplo, uma pessoa desenvolvedora comitou um código que construiu uma Query SQL com concatenação de parâmetros. O SAST, rodando no CI, detectou a possibilidade de um SQL Injection e bloqueou o commit. A pessoa desenvolvedora corrigiu a vulnerabilidade e, em questão de minutos, o código estava pronto para produção.

Concluindo sobre a importância da segurança no fluxo de desenvolvimento

Em resumo, a segurança não é opcional; é parte do fluxo. A detecção precoce evita retrabalho e reduz custos, o feedback rápido acelera correções e melhora a qualidade, e a prevenção de deploy inseguro protege o ambiente e o negócio. O que realmente traz segurança é um conjunto de iniciativas e ações em conjunto. Não basta ter um estágio que detecta bibliotecas vulneráveis; é necessário um fluxo de feedback rápido para a pessoa desenvolvedora. Todos esses caminhos devem andar juntos para entregar o melhor fluxo para o pipeline. Caso contrário, podemos ter uma falsa sensação de segurança, com estágios presentes, mas sem ações corretas durante o fluxo.

Até a próxima aula.

Introdução à segurança em CI/CD - Benefícios da segurança em CI-CD

Introduzindo a importância da segurança em CI&CD

Olá, pessoal! Na última aula, discutimos os objetivos da segurança em CI&CD e gostaríamos de relembrar nosso objetivo principal, que não se trata apenas da segurança do código, do repositório ou do ambiente, mas sim da segurança do nosso negócio. Quando mencionamos "nosso negócio", estamos nos referindo à empresa em que trabalhamos ou da qual somos proprietários. A segurança em CI&CD traz benefícios significativos, e é sobre isso que vamos tratar nesta aula.

Dividimos em alguns tópicos os benefícios que a segurança em CI&CD proporciona ao negócio: a redução de riscos, o aumento da velocidade com segurança e a cultura de segurança. Vamos explorar cada um desses tópicos agora.

Explorando a redução de riscos

A redução de riscos envolve a identificação precoce de vulnerabilidades. Como discutimos nas aulas anteriores, isso proporciona agilidade na correção e impede que esses riscos e vulnerabilidades cheguem ao ambiente de produção. Evita-se, assim, o vazamento de dados sensíveis, o que é um grande aliado na proteção do negócio. Atualmente, vemos frequentemente nas notícias sobre vazamentos de dados e o quanto isso impacta as empresas na mídia, afetando a imagem da empresa e reduzindo custos com correções emergenciais e mitigações de incidentes.

Quando enviamos um código para a produção, por exemplo, sempre corremos algum risco se não houver validação prévia. Descobrir problemas apenas no ambiente de produção representa um risco elevado. Nos outros ambientes também, mas no de produção, sabemos que normalmente se trabalha com dados reais e está exposto. Portanto, é isso que devemos evitar com estágios de segurança e o fortalecimento da segurança no CI&CD.

Aumentando a velocidade com segurança

O aumento da velocidade com segurança é alcançado por meio de automatizações seguras que agilizam as entregas.

O DevOps mais confiante é essencial para o lançamento de funcionalidades. Assim, o DevOps tem a segurança de que está entregando algo com qualidade, sem a preocupação de verificar questões que, muitas vezes, não são de sua responsabilidade. Isso economiza tempo e evita retrabalho e correções tardias. Como já discutimos, as correções tardias geralmente causam grande impacto, pois é necessário retornar ao início do desenvolvimento. Não se trata apenas do desenvolvimento em si, mas de todos os passos de testar funcionalidades, verificar a qualidade do código, envolvendo várias pessoas que, por vezes, já estão alocadas em outros projetos. Elas precisam voltar, relembrar tudo o que fizeram, todas as regras de negócios daquele projeto, e refazer todo o fluxo. Testar é praticamente como lançar um novo software na funcionalidade que foi impactada.

Promovendo a cultura de segurança

A cultura de segurança é vista como parte do ciclo natural de desenvolvimento. Observamos que isso aproxima a equipe de desenvolvimento. Passamos a entregar vulnerabilidades de forma mais parcelada para a equipe de desenvolvimento, ao invés de apresentar um pacote cheio de vulnerabilidades, bibliotecas e diversas questões, exigindo que tudo seja trocado em um prazo determinado. Isso promove uma cultura de segurança. A equipe de desenvolvimento se acostuma a lidar com essas questões e começa a envolver mais a equipe de segurança nas decisões, na escolha das ferramentas a serem usadas na aplicação, na comunicação com outras ferramentas e em diversas questões no código. Assim, essa cultura de segurança se dissemina na empresa, e logo percebemos que ela se espalha entre as pessoas desenvolvedoras, resultando em uma equipe dedicada a manter a segurança da empresa.

Obrigado e até a próxima aula.

Sobre o curso Segurança em Pipelines: Integrando práticas de segurança no CI/CD

O curso Segurança em Pipelines: Integrando práticas de segurança no CI/CD possui 255 minutos de vídeos, em um total de 67 atividades. Gostou? Conheça nossos outros cursos de Segurança em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Introdução à segurança em CI/CD
• Protegendo o ambiente de CI/CD
• Gestão de segredos em CI/CD
• SAST e SCA em pipelines
• DAST e testes de segurança em pipelines
• Security Gates e gestão de resultados