As especificidades do que acontece dentro dos pipelines de CI/CD são notoriamente opacas. Apesar de ter escrito o arquivo de configuração YAML, que é a lista de instruções do pipeline, como você pode ter certeza de que tudo acontece exatamente como está descrito? Pior ainda, a maioria dos pipelines são totalmente transitórios, portanto, mesmo no caso de um mau funcionamento, há poucas evidências além das registradas que podem ou não incluir os detalhes do problema.
O rápido desenvolvimento é alcançado por meio do uso de pipelines automatizados de Integração Contínua/Entrega Contínua (CI/CD). Ter gatilhos ou agendamento que compilem, construam, testem e enviem seu código automaticamente é fantástico. A maioria dos pipelines, entretanto, não é construída pensando na segurança, tendo sido projetada para velocidade e conveniência de uso. Como os pipelines normalmente exigem acesso à Internet para baixar dependências e arquivos, quando um pipeline é comprometido, o invasor tem diversas opções para interromper sua operação ou exfiltrar informações ou segredos.
Neste artigo, abordarei algumas das práticas recomendadas que você pode implementar para proteger seu pipeline de CI/CD. 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 proteger aquela seção do seu pipeline.
O que é o pipeline de CI/CD (integração contínua/entrega contínua)?
Um pipeline de CI/CD é um processo automatizado para construir, testar e publicar seu software, aplicativo ou artefato. Esses pipelines estão se tornando cada vez mais comuns e complexos. Pipelines são uma excelente ferramenta para aumentar a produtividade da equipe e produzir artefatos de software de forma mais consistente e previsível. A importância de automatizar estes procedimentos torna-se muito mais evidente quando se leva em conta que as empresas maiores podem ter centenas de pipelines interligados e coreografados, todos os quais dependem uns dos outros para funcionar bem.
Construir e testar alterações de código de forma automática e regular em um novo produto final é conhecido como integração contínua ou CI. As alterações de codificação são entregues, testadas e integradas como parte de um processo de duas etapas denominado entrega e/ou implantação contínua – CD. A implantação contínua entrega as atualizações automaticamente no ambiente de produção, enquanto a entrega contínua é interrompida logo antes da implantação automática de produção. Se o seu pipeline está usando um ou outro, depende totalmente de você e da maneira como seus ambientes e resultados são configurados.
A importância da segurança CI/CD para sua cadeia de fornecimento de software
A maioria das empresas depende Ferramentas CI / CD para automatizar seus pipelines. Isso significa que, como muitos outros ataques à cadeia de suprimentos de software, tudo o que os malfeitores precisam é violar um único alvo para obter um vasto raio de explosão. Um dos principais pontos fracos é a necessidade do pipeline baixar e integrar dependências ao produto ou artefato final. Mesmo uma dependência ruim é suficiente para dar a um elemento indesejado uma posição segura no pipeline. Como o pipeline tem acesso ao código-fonte e a vários outros elementos da sua infraestrutura (conforme necessário), uma escalação de privilégios pode acessar e posteriormente alterar ou exfiltrar quase qualquer parte do produto criado nesse pipeline específico.
Um exemplo simples pode ser encontrado em nossa explicação de um envenenamento de cache ou dependência.
Nos últimos anos, várias grandes empresas sofreram ataques à cadeia de fornecimento de software que tinham um pipeline de CI/CD como ponto de origem. Por exemplo, você pode olhar para Violação do CircleCI em janeiro de 2023, O compromisso do Argo CD em janeiro de 2022, e o Violação do Codecove em abril 2021.
As possíveis ramificações para tais ataques são graves, por isso faz sentido fazer o que puder para garantir que seus pipelines sejam tão seguros quanto possível.
Melhores práticas de segurança de CI/CD
Qualquer que seja a plataforma ou ferramentas de CI/CD que você esteja usando, há algumas coisas que você pode fazer para fortalecer sua segurança e diminuir os danos potenciais no caso improvável de um ator hostil conseguir obter acesso ao seu pipeline ou rede.
Monitoramento e alertas – Uma violação pode ocorrer mesmo que você tenha treinado seus engenheiros para serem cautelosos com phishing e outras fraudes de engenharia social. Como a maioria dos ambientes de pipeline são transitórios, uma vez concluído o trabalho, não haverá muitos rastros deixados para trás, a menos que você os registre ativamente. À medida que você trabalha em cada PR, mescla, cria e testa, certifique-se de que todas as modificações feitas no ambiente ou nos arquivos de configuração sejam registradas. Os dados do usuário também devem ser registrados junto com todos os outros dados para exame, se um problema exigir isso. Ser capaz de reconstruir uma violação e determinar o que deu errado e como deu errado é o objetivo aqui. Selecione antecipadamente os eventos que devem desencadear um alerta e certifique-se de que as partes apropriadas sejam informadas. Tome cuidado para não sobrecarregar os indivíduos com alertas inúteis ou excessivamente sensíveis; isto pode levar à fadiga dos alertas, o que simplesmente os faria ignorar os alertas ou reagir muito mais tarde do que seria prudente.
Use o princípio RBAC combinado com menos privilégios – Fornecer acesso aos recursos do sistema com base na função ou função designada de um usuário dentro de uma organização é a base do Controle de Acesso Baseado em Função ou RBAC. Os usuários recebem funções no RBAC que especificam seus direitos e permissões de acesso a diferentes recursos do sistema, como arquivos, pastas e programas. Por outro lado, o conceito de privilégio mínimo refere-se à prática de dar aos utilizadores a quantidade mínima de acesso e privilégios necessários para desempenhar as suas funções profissionais. Isso implica que os usuários estão limitados a usar os recursos necessários para concluir as tarefas atribuídas e nada mais. Mínimo Privilégio e RBAC são frequentemente aplicados em conjunto como conceitos de segurança complementares. O princípio do menor privilégio garante que os usuários tenham acesso apenas à quantidade mínima de recursos necessários para realizar suas tarefas específicas, e o RBAC atribui funções que fornecem aos usuários a quantidade certa de acesso aos recursos necessários para realizar suas funções de trabalho e nada mais . Quando combinadas, estas diretrizes ajudam a manter um sistema relativamente seguro e bem conservado. Você pode configurá-lo para exigir autorizações de vários usuários para ações essenciais do sistema como uma camada extra de segurança. Esta estratégia deve ser utilizada com cuidado, uma vez que pode atrasar visivelmente o processo de desenvolvimento.
Mantenha a proveniência do pipeline como um registro imutável – Informações verificáveis sobre artefatos de software que descrevem onde, quando e como algo foi criado são conhecidas como procedência. Saber precisamente quais arquivos foram inseridos e o que ocorreu com eles em um pipeline pode ser gerado como um arquivo de proveniência para formar um registro infalsificável desse pipeline. Para ser segura, a proveniência deve ser criada independentemente de qualquer usuário, pois qualquer coisa que um usuário possa interromper ou modificar não é totalmente confiável. Valint do Escriba permite que você estabelecer proveniência em seu pipeline para uma ampla variedade de sistemas SCM. Cada arquivo de proveniência (JSON) pode ser acessado posteriormente, portanto, você pode revisá-lo para determinar se ocorreu algo inesperado ou indesejável. A propósito, gerar e gerenciar arquivos de origem de todos os seus pipelines está no centro do processo. estrutura SLSA.
Utilize totalmente seu SBOM – Caso você tenha perdido alguns dos usos potenciais, um SBOM feito no final do pipeline poderia ajudar a listar todos os pacotes de código aberto usados. Comparar essa lista com CVEs conhecidos pode lhe dizer quais vulnerabilidades potenciais existem em seu produto final. Você também pode usar a lista para verificar se ainda está usando versões desatualizadas de pacotes de código aberto e até mesmo usar algo como o Pontuação do OpenSSF para verificar a 'integridade' dos pacotes que você está usando. Como novos CVEs surgem constantemente, você deve ter um serviço, ao contrário de um SAST único, que permite saber se um de seus pacotes existentes tem um novo CVE descoberto nele. O serviço do Scribe pode ajudá-lo a fazer tudo isso automaticamente.
Verifique a conformidade com suas políticas – Cada empresa, e às vezes cada pipeline, tem políticas que precisam ser implementadas para garantir que tudo esteja bem. Algumas políticas são genéricas (como garantir que haja um processo de verificação por duas pessoas) e outras são exclusivas (como garantir que Mike aprove a alteração mais recente antes de enviá-la para produção). Utilizando o mecanismo de verificação de sinal criptográfico e um arquivo de política exclusivo, agora você pode incluir as políticas necessárias em cada pipeline e verificar (para você mesmo e para outras pessoas) se elas ocorreram. É uma fraqueza humana que, quando estressada, pode fazer com que alguns requisitos sejam ignorados e algumas regras sejam alteradas para cumprir um prazo. Com esta medida em vigor, as pessoas não podem mais violar as regras, e isso deve ajudar a manter a segurança do seu pipeline contra ameaças internas e externas. A Scribe desenvolveu uma nova maneira de aplicar essas políticas e até mesmo permitir que você escreva as suas próprias. Confira SUA PARTICIPAÇÃO FAZ A DIFERENÇA.
Proteja o arquivo de instruções do pipeline – Os atores da ameaça podem “envenenar” o pipeline de CI usando uma técnica conhecida como execução de pipeline envenenada (PPE), que essencialmente modifica os estágios do pipeline ou sua sequência conforme especificado originalmente no arquivo de instruções do pipeline. O método manipula o processo de construção abusando de permissões em repositórios de gerenciamento de código-fonte (SCM). Ao inserir códigos ou comandos maliciosos nas configurações do pipeline de construção, é possível envenenar o pipeline e fazer com que código malicioso seja executado enquanto a construção está sendo concluída. Você não será capaz de dizer que suas compilações não estão funcionando da maneira desejada até ou a menos que você verifique o arquivo de instruções do pipeline. Para ter certeza de que seus pipelines estão sendo executados conforme planejado, verifique o arquivo de instruções antes de cada execução. Criptograficamente, assinar o arquivo e adicionar a verificação de assinatura como uma primeira etapa do pipeline é uma forma de obter essa segurança. Valint do Escriba assinar e verificar As funções são uma maneira de verificar se o arquivo de instruções permaneceu inalterado antes de iniciar qualquer nova execução do pipeline.
Garanta seu resultado final – Por que um invasor deveria trabalhar duro para interromper seu pipeline quando substituir seu produto final por uma versão fraudulenta é muito mais fácil? Como a empresa geradora parece ser a fonte da imagem neste tipo de ataques, não é suficiente que essa empresa tenha um certificado válido que a proteja. Dito de forma simples, aumentaria a credibilidade da falsificação. A solução é assinar criptograficamente qualquer que seja o artefato final produzido pelo pipeline e permitir que o usuário final verifique essa assinatura. Valint do Scribe pode ser usado para assinar e verificar uma grande variedade de artefatos, proporcionando segurança extra de que seus usuários estão obtendo exatamente o que você deseja que eles obtenham.
Olhando para o futuro
Ninguém vai desistir de usar técnicas de automação como CI/CD para agilizar seu trabalho. Muito pelo contrário, no mundo em que vivemos, estamos sempre a pressionar por iterações de atualização de software cada vez mais rápidas. Devemos, no mínimo, ter certeza de que abordamos a tarefa com cautela, tomando cuidado para não comprometer nosso ambiente de produção ou nosso código-fonte no processo.
O crucial é considerar as consequências potenciais de alguém obter acesso ilegal ao seu pipeline, ao seu ambiente ou ao seu código-fonte. Tenho certeza de que você será capaz de tomar as medidas apropriadas para interromper ou mitigar possíveis vazamentos assim que perceber o quão perigoso isso pode ser e onde seus pipelines e rede são mais suscetíveis.
Como os pipelines interconectados só aumentarão em complexidade, é vital manter a segurança geral do seu ambiente (rede segmentada, RBAC, confiança zero, etc.) como o primeiro passo para ajudar a proteger seus pipelines. Depois disso, procure criar evidências sólidas e infalsificáveis e empregue assinatura criptográfica e verificação de dados para tentar mitigar, tanto quanto possível, o potencial de um ataque à cadeia de fornecimento de software que possa envenenar seu pipeline ou o cache do pipeline. Ficar alerta e desconfiado pode poupar incalculáveis dores de cabeça à sua empresa.
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
