O pipeline de build de software (a infraestrutura de CI/CD que transforma código-fonte em artefatos de software implantáveis) é a ponte de confiança crítica na cadeia de suprimentos de software. Um atacante capaz de modificar código ou injetar comandos no pipeline de build produz artefatos de software que contêm o código dele, construídos a partir do repositório de código-fonte do fornecedor, assinados com as credenciais do fornecedor e indistinguíveis de builds legítimos para qualquer consumidor a jusante que confie na chave de assinatura. O comprometimento do pipeline de build é o vetor de ataque que produziu a violação da SolarWinds, o ataque à cadeia de suprimentos da 3CX e inúmeros incidentes de menor escala na cadeia de suprimentos. É também o vetor de ataque que a maioria das avaliações de segurança de fornecedores não avalia.
A superfície de ataque do pipeline de build é substancialmente maior e menos bem governada do que a segurança das aplicações em produção. Um pipeline de CI/CD típico inclui: o repositório de código-fonte e suas regras de proteção de branches, a plataforma de CI/CD e seus arquivos de configuração, a infraestrutura de agentes de build e as credenciais que ela utiliza, as integrações de terceiros (linters, frameworks de teste, scanners de segurança, ferramentas de implantação) executadas dentro do pipeline, o registro de artefatos onde o software compilado é armazenado e os mecanismos de implantação que levam os artefatos do registro para a produção. Cada um desses itens é uma potencial superfície de ataque. Muitas empresas aplicam controles de segurança rigorosos às aplicações em produção, enquanto deixam os componentes do pipeline de build significativamente menos governados.
O problema da exposição de credenciais é a vulnerabilidade de pipeline explorável de forma mais imediata. Os pipelines de CI/CD exigem credenciais (tokens de repositório, chaves de acesso de provedores de nuvem, autenticação do registro de artefatos, credenciais do sistema de implantação) para funcionar. Essas credenciais costumam ser armazenadas como variáveis de ambiente ou segredos do pipeline. Quando as integrações do pipeline são executadas com permissões excessivas (credenciais de nível de produção em vez do mínimo necessário para sua função), o comprometimento de qualquer integração dá ao atacante todo o escopo das credenciais que essa integração utilizava. Uma ferramenta de cobertura de código executada com credenciais de implantação em produção é um potencial vetor de movimentação lateral do ambiente de build para a produção.
Por que isso importa
A integridade do pipeline de build é relevante para TPRM porque o fornecedor de software cujo pipeline é comprometido produz software comprometido, por mais fortes que sejam seus controles de segurança em produção. A empresa que avalia a segurança do ambiente de produção de um fornecedor sem avaliar a segurança do seu pipeline de build avaliou o alvo que o atacante vai contornar, e não o caminho que ele vai usar.
- Pipeline de build fora do escopo da avaliação: segurança de produção avaliada sem a segurança do build
- Integrações de terceiros do pipeline não avaliadas quanto à postura de segurança
- Credenciais do pipeline não avaliadas quanto ao privilégio mínimo
- Isolamento do pipeline em relação ao ambiente de produção não avaliado
- Verificação da integridade do build ausente do processo de entrega de software
Como é uma boa prática
Programas maduros de segurança de pipelines de build implementam a minimização de credenciais específica do pipeline, auditam as integrações de terceiros do pipeline quanto à postura de segurança e ao escopo de acesso às credenciais, implementam o isolamento do ambiente de build, geram e verificam a proveniência SLSA dos resultados do build e incluem a segurança do pipeline de build nas avaliações de fornecedores, juntamente com a segurança do ambiente de produção.
- Credenciais de pipeline com privilégio mínimo: as integrações utilizam apenas as permissões necessárias
- Auditoria das integrações de terceiros: postura de segurança e escopo de credenciais de cada uma
- Isolamento do ambiente de build: acesso restrito à rede e ao sistema de arquivos durante os builds
- Geração de proveniência SLSA: atestação verificável da integridade do build
- Configuração do pipeline como código, com requisitos de revisão: nenhuma modificação improvisada no pipeline
Ferramentas
Segurança de pipelines: Palo Alto Prisma Cloud para a segurança de CI/CD; Legit Security, Ox Security para a gestão da postura dos pipelines
Plataformas de gestão da postura de segurança de CI/CD avaliam a configuração do pipeline de build, a exposição de credenciais, a segurança das integrações de terceiros e o isolamento entre o pipeline e a produção, oferecendo a visão da segurança do pipeline de build que as ferramentas de segurança de aplicações em produção não abordam. Para profissionais de TPRM, perguntar se o fornecedor usa gestão da postura de segurança de CI/CD junto com a varredura de segurança de aplicações é uma pergunta específica de avaliação do pipeline de build.
Proveniência: ações geradoras de SLSA e Tekton Chains para a geração de proveniência de build
Ferramentas de geração de proveniência de build integradas a pipelines de CI/CD produzem atestações assinadas da integridade do build, confirmando que o artefato foi construído a partir do código-fonte especificado pelo sistema de build autenticado. Para fornecedores de software críticos, solicitar atestações de proveniência fornece a verificação da integridade do build para a qual a avaliação de segurança do pipeline estabelece a estrutura.
Desafios de governança
O desafio de governança da segurança do pipeline de build é a lacuna de responsabilidade entre DevOps e segurança. Os pipelines de build normalmente pertencem a equipes de DevOps ou de engenharia de plataforma e são mantidos por elas, com frameworks de gestão de riscos diferentes dos usados pelas equipes de segurança que conduzem as avaliações de fornecedores. A solução de governança é incluir a segurança do pipeline de build no escopo da avaliação de fornecedores, junto com a segurança de aplicações, perguntando explicitamente sobre a gestão de credenciais do pipeline, a segurança das integrações de terceiros e o isolamento do ambiente de build.
- Inclua o pipeline de build no escopo da avaliação de fornecedores
- Pergunte sobre o privilégio mínimo das credenciais do pipeline: que permissões as integrações usam
- Pergunte sobre a segurança das integrações de terceiros no pipeline: como as integrações são avaliadas
- Pergunte sobre o isolamento do ambiente de build: restrições de acesso à rede durante os builds
- Solicite a proveniência SLSA como verificação da integridade do build
Se você faz parte de uma equipe pequena
Para os seus três fornecedores de software mais críticos, faça duas perguntas sobre o pipeline de build que o questionário de segurança padrão deles não aborda. Primeira: quais ferramentas ou integrações de terceiros são executadas no seu pipeline de CI/CD e quais credenciais elas utilizam? Segunda: as credenciais do seu pipeline estão restritas às permissões mínimas necessárias, ou alguma integração do pipeline utiliza acesso de nível de produção? Essas duas perguntas revelam as duas falhas de segurança mais comuns em pipelines de build: integrações de terceiros não revisadas e escopo excessivo de credenciais.
- Pergunte quais ferramentas de terceiros são executadas no pipeline de CI/CD e quais credenciais elas utilizam
- Pergunte se as credenciais do pipeline seguem o privilégio mínimo
- Inclua o pipeline de build no escopo da avaliação de segurança de fornecedores
- Solicite a proveniência SLSA para versões críticas de software
O que exigir
Pergunte diretamente:
"Quais integrações de terceiros são executadas no seu pipeline de CI/CD, e vocês podem confirmar que essas integrações utilizam credenciais de privilégio mínimo em vez de acesso de nível de produção? E vocês geram atestações de proveniência SLSA para as versões do seu software?"
O que esperar como evidência
- Inventário de integrações de terceiros de CI/CD com o escopo das credenciais
- Confirmação de credenciais de pipeline com privilégio mínimo
- Descrição do isolamento do ambiente de build
- Geração e nível de proveniência SLSA
Um fornecedor que confirma a segurança do ambiente de produção deve ser questionado sobre a segurança do pipeline de build. Os controles do ambiente de produção protegem o que está em execução. Os controles do pipeline de build protegem a forma como isso foi construído. O ataque à SolarWinds contornou os primeiros ao comprometer os segundos.
Como comprovar
- Registros da avaliação do pipeline de build
- Verificação do escopo das credenciais do pipeline
- Revisão de segurança das integrações de terceiros
- Verificação da proveniência SLSA para software crítico
Principal conclusão
Ambiente de produção: protegido. Pipeline de CI/CD: 12 integrações de terceiros, 7 executadas com credenciais de produção, 1 com contorno de autenticação. O ambiente de produção tinha controles rigorosos. O pipeline que construiu tudo o que era executado nele tinha um contorno de autenticação em uma integração de terceiros com credenciais de produção. A segurança do pipeline de build não é um subconjunto da segurança de aplicações: é a superfície de ataque situada a montante dos controles de segurança de aplicações que ela produz. Avaliar a segurança da produção sem avaliar a segurança do pipeline de build é avaliar o alvo que o atacante contorna, não o caminho que ele utiliza.