Os pipelines de CI/CD são notoriamente opacos quanto ao que exatamente acontece dentro deles. Mesmo que tenha sido você quem escreveu o arquivo de configuração YAML (a lista de instruções do pipeline), como pode ter certeza de que tudo acontecerá exatamente como descrito? Pior ainda, a maioria dos pipelines são completamente efêmeros, portanto, mesmo que algo ruim aconteça, não restam vestígios depois.
Simplificando, um pipeline é uma forma automatizada de testar, construir e publicar seu software, aplicativo ou artefato. Esses pipelines estão se tornando cada vez mais comuns e complicados. Pipelines funcionam muito bem para fazer com que as equipes trabalhem com mais rapidez, para fornecer resultados mais consistentes e previsíveis ao produzir seu artefato de software. A importância de automatizar estes processos torna-se ainda mais clara quando se considera que empresas maiores podem ter centenas de pipelines orquestrados que dependem uns dos outros, por isso é vital que tudo esteja a funcionar sem problemas e sem falhas.
Como elo final no processo de desenvolvimento entre os desenvolvedores e o usuário ou cliente final, sinto que não há foco suficiente em como esses processos automatizados poderiam ser usados como potenciais vetores de ataque. Acessar um pipeline de construção poderia permitir que atores mal-intencionados não apenas penetrassem no sistema da empresa produtora, mas também modificassem potencialmente o artefato resultante de forma a afetar todos os usuários futuros, criando assim um enorme raio de explosão, muitas vezes descrito como um ataque à cadeia de fornecimento de software.
Em um artigo anterior, discutimos os princípios que devem orientá-lo em protegendo seu pipeline de CI/CD. Neste artigo, abordarei alguns dos possíveis pontos fracos mais comuns em um pipeline de CI/CD e oferecerei algumas opções de correção. Para nossos propósitos, não importa quais ferramentas ou sistemas de automação você está usando – os princípios de segurança ainda são válidos, você só precisa encontrar a ferramenta certa para o trabalho de proteger aquela seção do seu pipeline.
Dominando a arte do CI/CD: os elementos-chave que você não pode ignorar
Pipelines diferentes possuem elementos diferentes e usam ferramentas diferentes. Os elementos que escolhi focar são relevantes para quase todos os pipelines, portanto, proteger esses elementos pode ser considerado uma prática recomendada, independentemente do seu SCM, ferramentas ou configuração de segurança existente.
Gerenciamento de segredo – segredos geralmente são strings ou tokens usados para conectar seu software ou pipeline a outros recursos. Um exemplo comum são as chaves de API usadas para conectar seu código aos recursos da AWS, como um bucket S3. A maioria das pessoas já sabe que deve manter esses segredos ocultos e não incluí-los como texto simples em um repositório aberto. As coisas são um pouco mais complicadas dentro de um pipeline de CI/CD. Normalmente, o pipeline precisa de acesso a esses segredos para acessar os recursos e as informações que eles representam. Isso significa que qualquer pessoa com acesso ao que está acontecendo dentro do seu pipeline poderá ver e copiar seus segredos. Uma maneira de manter seus segredos seguros, mesmo dentro do pipeline, é usar uma ferramenta de gerenciamento de segredos como Cofre da Hashicorp. Essas ferramentas podem não apenas ofuscar seus segredos, mesmo dentro do pipeline, mas também tornam muito mais fácil a rotação de seus segredos, para que você possa alterá-los regularmente, tornando inútil o roubo de segredos de um pipeline. Independentemente da ferramenta de gerenciamento de segredos que você escolher, a rotação regular de seus segredos pode ser considerada uma boa prática de segurança.
Execução de pipeline envenenado (PPE) - A execução de pipeline envenenado (PPE) é uma técnica que permite que os atores da ameaça 'envenenem' o pipeline de CI – na verdade, alterem as etapas do pipeline ou sua ordem, conforme definido no arquivo de instruções do pipeline. A técnica abusa de permissões em repositórios de gerenciamento de código-fonte (SCM) para manipular o processo de construção. Ele permite injetar códigos ou comandos maliciosos na configuração do pipeline de construção, envenenando o pipeline para executar código malicioso durante o processo de construção. A menos que você verifique o arquivo de instruções do pipeline antes de cada compilação, você provavelmente não saberá que suas compilações não estão mais sendo executadas conforme especificado. Mesmo uma mudança minúscula, como chamar uma biblioteca em vez de outra, pode ter efeitos de longo alcance, como incluir backdoors ou criptomineradores no produto final.
Uma das maneiras de evitar o PPE é verificar se o arquivo de instruções do pipeline não foi modificado. Você pode assinar criptograficamente o arquivo e adicionar a verificação de assinatura como a primeira etapa de cada pipeline. Uma ferramenta que você pode usar para assinar e verificar arquivos é Valint, uma ferramenta publicada pela Scribe Security. Qualquer que seja a ferramenta de verificação de sinal que você usar, a ideia é garantir que a integridade do arquivo de instruções permaneça intacta.
Envenenamento de cache/dependências – Fluxos de trabalho de pipeline de CI/CD são frequentemente usados para especificar ações específicas que devem ser executadas. Cada fluxo de trabalho é composto por uma série de um ou mais trabalhos, que se caracterizam como uma sequência de ações. A maioria dos fluxos de trabalho não compartilha recursos por motivos de segurança. Existem, no entanto, soluções alternativas para quando for necessário compartilhar recursos. Um cache que todos os fluxos de trabalho possam acessar igualmente é uma dessas soluções alternativas. Como o cache é compartilhado por vários fluxos de trabalho, basta uma infração em um fluxo de trabalho com autoridade para alterá-lo para que o cache se torne venenoso para todos os usos subsequentes do fluxo de trabalho. Um único esconderijo envenenado pode estar ativo por muito tempo, afetando inúmeras iterações de compilações de software em execução nesse pipeline, visto que o cache só é atualizado quando há um novo artefato ou pacote para baixar.
Assim como na verificação do arquivo de instruções do pipeline, você pode usar Valint para assinar e posteriormente verificar seu cache ou uma pasta contendo todas as dependências pré-aprovadas que seu pipeline exige. Se você é do tipo paranóico, permitir que seu pipeline se conecte de forma independente à Internet e baixe todas as bibliotecas que considerar necessárias é uma maneira infalível de obter mais vulnerabilidades e possíveis explorações em sua construção final.
Chaves SSH – Uma chave SSH é uma credencial de acesso para o protocolo de rede SSH (secure shell). Este protocolo de rede é usado para comunicação remota entre máquinas em um rede aberta insegura. SSH é usado para transferência remota de arquivos, gerenciamento de rede e acesso remoto ao sistema operacional. Com chaves SSH, por exemplo, você pode se conectar ao GitHub sem fornecer seu nome de usuário e token de acesso pessoal em cada visita. Você também pode usar uma chave SSH para assinar commits. Da mesma forma, você pode conectar outros aplicativos ao seu GitHub usando chaves SSH como BitBucket e GitLab.
Para manter a segurança da conta, você deve revisar regularmente sua lista de chaves SSH e revogar/excluir quaisquer chaves que sejam inválidas ou que tenham sido comprometidas. Para GitHub, você pode encontrar sua lista de chaves SSH na página a seguir:
Acesso a Configurações > Chaves SSH e GPG
Uma ferramenta que pode ajudá-lo a manter o controle de suas chaves SSH é um relatório de postura de segurança de código aberto chamado GitGat. O relatório GitGat irá alertá-lo se alguma das chaves SSH configuradas tiver expirado ou for inválida. Além de ficar de olho em suas chaves e girá-las com frequência, o GitHub avisa que caso você veja uma chave SSH com a qual não esteja familiarizado, exclua-a imediatamente e entre em contato Suporte GitHub para obter mais ajuda. Uma chave pública não identificada pode indicar uma possível violação de segurança.
Proveniência SLSA como um registro de pipeline imutável - SLSA significa Supply Chain Levels for Software Artifacts, que é uma estrutura desenvolvida pelo Google e outros parceiros do setor para ajudar a melhorar a segurança e a integridade das cadeias de fornecimento de software.
SLSA define um conjunto de quatro níveis, cada um dos quais representa um nível mais elevado de confiança e garantia na cadeia de fornecimento de software. Cada nível é um incremento crescente de requisitos de segurança. Um requisito importante é a necessidade do arquivo de Procedência. Para a estrutura SLSA,
Procedência é a informação verificável sobre artefatos de software que descreve onde, quando e como algo foi produzido. Como a maior parte do propósito de um pipeline de CI/CD é produzir algo (geralmente uma compilação), ser capaz de rastrear exatamente quais arquivos entraram e o que aconteceu com eles é uma espécie de registro de máquina infalsificável do pipeline. Para isso, é importante que a proveniência do SLSA seja criada de forma independente de qualquer usuário. A integridade de qualquer coisa que um usuário possa interromper ou modificar pode ser suspeita.
Uma ferramenta que permite criar uma origem SLSA em seu pipeline para uma grande variedade de sistemas SCM é Valint (sim, a mesma ferramenta do Scribe – é uma ferramenta muito versátil). O link mostrará como conectar o Valint ao pipeline do GitHub para gerar uma origem SLSA para cada compilação executada nesse pipeline. Posteriormente, você pode acessar cada arquivo de proveniência e verificá-lo para ver se algo desagradável ou inesperado aconteceu. Aqui está um trecho desse arquivo de proveniência:
O arquivo de proveniência é apenas um arquivo JSON, mas como (ainda) não existem ferramentas automatizadas para ler arquivos de proveniência, a tarefa de lê-los e interpretá-los cabe a você.
Protegendo seu resultado final – Uma das violações mais conhecidas da cadeia de fornecimento de software na memória recente é a Incidente SolarWinds. Nele, os hackers modificaram alguns códigos no servidor de compilação para que cada compilação lançada pela empresa contivesse um backdoor secreto. Outro caso famoso de corrupção do resultado final pode ser visto no hack da Autoridade de Certificação do Governo Vietnamita (VGCA) em 2020, apelidado Operação SignSight. Os invasores se infiltraram no site da VGCA e redirecionaram links de download para sua própria versão do software, repleta de malware. Em ambos os casos, os usuários finais não tinham como verificar se o software que obtiveram era o software que a empresa produtora pretendia lançar.
Um ataque mais simples poderia ser substituir a imagem final construída no final do pipeline por uma imagem maliciosa e carregar a imagem ruim para onde ela for necessária. Como na maioria desses ataques a imagem supostamente vem da empresa produtora, mesmo que essa empresa esteja protegida por um certificado válido, isso não é suficiente. Isso apenas tornaria a falsificação muito mais verossímil.
Mais uma vez, a solução é assinar criptograficamente qualquer que seja o artefato final produzido pelo pipeline e permitir que o usuário final verifique essa assinatura.
Como já mencionei Valint Vou sugerir o uso do código aberto Fiador da Sigstore. A Cosign visa facilitar a assinatura, eliminando a necessidade de infraestrutura chave. Ele permite que o usuário use sua identidade verificada online (como Google, GitHub, Microsoft ou AWS) como chave. Você pode usar o Cosign para assinar e verificar imagens, tornando-o ideal para a assinatura e posterior verificação da imagem final construída de um pipeline.
Independentemente de você optar por usar Valint ou Cosign, permitir que seus usuários verifiquem uma assinatura criptográfica em seu artefato final para ter certeza de que estão recebendo exatamente o que você pretende entregar é uma ideia que tenho certeza que a maioria dos usuários finais apreciaria.
Segurança de pipeline no futuro
Existem, é claro, outros elementos envolvidos em um pipeline de construção que poderiam se beneficiar de segurança adicional. Neste artigo, optei por examinar alguns dos elementos de pipeline mais óbvios e mais vulneráveis.
Qualquer que seja a ferramenta ou infraestrutura de pipeline que você esteja usando, mantenha os olhos abertos para a possibilidade de uma violação. Nunca confie cegamente em qualquer sistema que diga que é totalmente seguro.
Considerando a crescente ameaça de roubo de identidade, spear phishing e outras formas de falsificação de acesso legítimo, acreditamos que o mecanismo de verificação de sinal é uma ferramenta boa e versátil para ter em sua caixa de ferramentas digital.
Se você precisa assinar uma imagem, arquivo ou pasta, convido você a dar uma olhada mais de perto no Valint da Scribe Security como uma ferramenta completa para tais necessidades.
Este conteúdo é oferecido a você pela Scribe Security, um fornecedor líder de soluções de segurança de cadeia de suprimentos de software ponta a ponta – fornecendo segurança de última geração para artefatos de código e processos de desenvolvimento e entrega de código em todas as cadeias de suprimentos de software. Saiba mais.
Artigos Relacionados
