À medida que o ciclo de vida da cadeia de suprimentos de software progride do código-fonte para artefatos executáveis, o estágio de construção se apresenta como uma junção crítica. No entanto, essa fase transformadora também é suscetível a uma série de ameaças que podem comprometer a integridade do software e build security. Essas ameaças podem se infiltrar no processo de construção por meio de vários métodos, incluindo contornar o estabelecido CI/CD pipeline, modificando o controle pós-fonte do código, comprometendo o próprio processo de construção ou manipulando repositórios de artefatos. Nesta postagem do blog, nos aprofundamos nessas ameaças e examinamos os ataques mais comuns à criação de cadeias de suprimentos de software. Este conteúdo continua nossa série de blogs explorando software supply chain security em todo o SDLC.
O estágio de construção no ciclo de vida de desenvolvimento de software
O estágio de construção do ciclo de vida da cadeia de suprimentos de software abrange o processo de transformação do código-fonte em artefatos de software executáveis. Esta etapa envolve compilar, vincular e empacotar o código-fonte, bem como gerar pacotes de instalação e arquivos de configuração.
Build security ameaças são vulnerabilidades que podem permitir que um adversário introduza alterações não autorizadas no software durante o processo de construção sem alterar o código-fonte. Essas ameaças podem ser introduzidas por vários métodos, como comprometer o ambiente de construção ou explorar vulnerabilidades em ferramentas de construção.
Ameaças mais comuns à cadeia de suprimentos de software – ataques de construção
Ignorar CI/CD
Isto se refere à prática de contornar o estabelecido CI/CD (integração contínua e entrega contínua) pipeline construir e publicar software diretamente, sem passar por processos rigorosos de testes, verificação e auditoria que normalmente são aplicados pelo órgão oficial pipeline. Isso pode ser feito construindo manualmente o software fora do CI/CD ambiente ou usando ferramentas ou scripts que permitem modificações não autorizadas no processo de construção. Um exemplo desse tipo de ataque de vetor foi o Ataque Jenkins. Em 2022, hackers se infiltraram na construção pipeline de um projeto popular de software de código aberto chamado Jenkins. Os hackers injetaram código malicioso em um Jenkinsfile, que é um script que define o processo de construção. O código malicioso permitiu que os hackers ignorassem o CI/CD pipelineverificações de segurança e injetar seu código no processo de construção. Esse código é então executado nos sistemas das organizações que instalaram o software.
Modifique o código após o controle de origem
Esta prática envolve fazer alterações não autorizadas no código-fonte após ele ter sido commitconectado a um sistema de controle de origem confiável (SCS) e, em seguida, construindo o software usando esse código modificado. Isso pode ser feito modificando diretamente o código na estação de trabalho de um desenvolvedor ou usando ferramentas ou scripts externos para injetar código malicioso no processo de construção. Um exemplo desse ataque vetorial foi o Ataque GitLab em 2022. Hackers se infiltraram na construção pipeline of GitLab. Os hackers injetaram código malicioso no GitLab CI/CD pipeline, que é uma ferramenta que automatiza o build security processo. O código malicioso permitiu que os hackers modificassem o código depois que ele foi verificado no controle de origem. Isso permitiu que eles injetassem seu código no software, que foi então executado nos sistemas das organizações que instalaram o software.
Comprometer o processo de construção
Isso envolve manipular ou alterar o próprio processo de construção, seja por meio de acesso direto ao ambiente de construção ou pela exploração de vulnerabilidades em ferramentas de construção ou dependências de terceiros. Isso pode ser feito para introduzir código malicioso na saída do build, adulterar a origem do build ou interromper completamente o processo de build. O exemplo mais famoso desse ataque vetorial foi o Ataque SolarWinds. Um invasor obteve acesso não autorizado à plataforma de construção da SolarWinds, um sistema usado para compilar e empacotar o software SolarWinds Orion. Este script injetou código malicioso no software SolarWinds Orion compilado. Quando os usuários instalavam o software comprometido, o código malicioso era executado em seus sistemas, dando ao invasor acesso não autorizado aos seus sistemas. O invasor também conseguiu roubar dados confidenciais de seus sistemas, como credenciais, propriedade intelectual e informações de clientes.
Comprometer repositório de artefatos
Refere-se ao acesso ou manipulação não autorizado de um repositório de artefatos, onde pacotes de software e binários são armazenados para distribuição a usuários internos ou externos. Os invasores podem explorar essa vulnerabilidade para introduzir código malicioso, adulterar a autenticidade do software ou interromper o processo de implantação. Um exemplo deste ataque vetorial foi As RubyGems em 2022. Hackers se infiltraram no repositório de artefatos RubyGems. Os hackers substituíram um artefato legítimo por um malicioso, que foi então baixado por milhares de organizações que construíam software com Ruby on Rails. O artefato malicioso permitiu que os hackers executassem códigos arbitrários nos sistemas das organizações que instalaram o software. Isso poderia permitir que eles roubassem dados, instalassem malware ou interrompessem operações.
Considerações finais
À medida que as organizações continuam a adotar práticas de desenvolvimento de software que enfatizam a automação e a entrega contínua, a importância de proteger o processo de construção de software nunca foi tão grande. Ao implementar medidas de segurança robustas durante todo o estágio de construção, as organizações podem reduzir significativamente o risco de serem vítimas de ataques maliciosos que podem comprometer a integridade e a segurança do seu software.
As estratégias descritas nesta postagem do blog e os exemplos fornecidos servem como um lembrete de que o estágio de construção é um ponto vulnerável na cadeia de fornecimento de software. As organizações devem prestar atenção a estas ameaças e implementar as medidas de segurança necessárias para proteger o seu software contra ataques. Ao fazer isso, eles podem garantir a integridade, segurança e confiabilidade de seu software para seus usuários e clientes.
Junte-se à nossa jornada em direção a um ecossistema de software seguro
Não perca esta oportunidade de ficar à frente da curva para evitar ameaças à cadeia de fornecimento de software. Assine nosso blog hoje e seja o primeiro a receber nossos insights mais recentes, garantindo que sua organização permaneça resiliente e segura em meio a ameaças em evolução. Juntos, podemos construir um ecossistema de software mais robusto e seguro para todos.
Assista ao nosso vídeo de demonstração
