0 
0 Introdução
De muitas maneiras, a cadeia de suprimentos de software é semelhante à de produtos manufaturados, que todos sabemos que foram amplamente impactados por uma pandemia global e escassez de matérias-primas.
No entanto, no mundo da TI, não são as carências ou pandemias que têm sido os principais obstáculos a superar nos últimos anos, mas sim os ataques que visam usá-los para prejudicar centenas ou mesmo milhares de vítimas simultaneamente. Se você ouviu falar de um ataque cibernético entre 2020 e hoje, é provável que a cadeia de suprimentos de software tenha desempenhado um papel.
Quando falamos de um ataque na cadeia de fornecimento de software, estamos nos referindo a dois ataques sucessivos: um que visa um fornecedor e outro que visa um ou mais usuários a jusante da cadeia, usando o primeiro como veículo.
Neste artigo, vamos mergulhar nos mecanismos e riscos da cadeia de suprimentos de software observando uma vulnerabilidade típica do ciclo de desenvolvimento moderno: a presença de informações de identificação pessoal, ou “segredos”, nos ativos digitais das empresas. Também veremos como as empresas estão se adaptando a essa nova situação, aproveitando os ciclos de melhoria contínua.
A cadeia de suprimentos, no centro do ciclo de desenvolvimento de TI
O que é a cadeia de suprimentos?
Hoje, é extremamente raro ver empresas produzindo software 100% internamente. Sejam bibliotecas de código aberto, ferramentas de desenvolvedor, sistemas de implantação e entrega no local ou baseados em nuvem ou serviços de software como serviço (SaaS), esses blocos de construção se tornaram essenciais na fábrica de software moderna.
Cada um desses “tijolos” é o produto de uma longa cadeia de suprimentos, tornando a cadeia de suprimentos de software um conceito que abrange todas as facetas da TI: do hardware ao código-fonte escrito por desenvolvedores, a ferramentas e plataformas de terceiros, mas também armazenamento de dados e todas as infra-estruturas criadas para desenvolver, testar e distribuir o software.
A cadeia de suprimentos é uma estrutura em camadas que permite às empresas implementar fábricas de software altamente flexíveis, que são o motor de sua transformação digital.
A reutilização em massa de componentes e bibliotecas de código aberto acelerou drasticamente o ciclo de desenvolvimento e a capacidade de fornecer funcionalidade de acordo com as expectativas do cliente. Mas a contrapartida desse ganho impressionante foi a perda de controle sobre a origem do código que entra nos produtos das empresas. Essa cadeia de dependências expõe as organizações e seus clientes a vulnerabilidades introduzidas por mudanças fora de seu controle direto.
Este é obviamente um grande problema de segurança cibernética, e que só está aumentando à medida que a cadeia de suprimentos se torna cada vez mais complexa ano após ano. Portanto, não é surpresa que ataques cibernéticos em larga escala tenham sido capazes de explorá-lo em seu benefício recentemente.
O risco do elo fraco
Para os hackers, a cadeia de suprimentos de software das empresas representa um alvo interessante por vários motivos. Em primeiro lugar, devido à sua complexidade e ao número de “tijolos” que interagem no coração da fábrica de software, sua superfície de ataque é muito grande. Em segundo lugar, a segurança do aplicativo, que historicamente se concentrava em proteger o aplicativo em produção (ou seja, exposto ao público), geralmente carece de visibilidade e ferramentas para proteger efetivamente os servidores internos de compilação e outras partes do pipeline de CI/CD.
Além disso, é importante entender que a cadeia de desenvolvimento hoje está em constante evolução, adicionando novas ferramentas constantemente. Essa é uma das características definidoras do movimento DevOps, que confundiu enormemente a linha entre desenvolvimento e operações, deixando os desenvolvedores livres para entregar recursos para seus clientes o mais rápido possível.
Essas escolhas, no entanto, são frequentemente implementadas sem supervisão e podem ser muito diferentes de uma equipe para outra, mesmo dentro do mesmo departamento. A acumulação de ferramentas, bibliotecas e plataformas ligeiramente diferentes torna muito difícil criar inventários precisos que são a base de uma gestão de segurança eficaz.
Finalmente, ao explorar a cadeia de suprimentos, os hackers encontram maneiras de maximizar o impacto e, portanto, o rendimento de um ataque. Para entender isso, devemos considerar que os produtos e serviços da cadeia de suprimentos de uma empresa de serviços de software são os blocos de construção de outras cadeias de suprimentos. Um invasor que se infiltrou com sucesso em um elo de uma cadeia pode comprometer toda a base de usuários, o que pode ter consequências desastrosas.
O aumento dos ataques à cadeia de suprimentos
No ataque da SolarWinds, entre março e junho de 2020, aproximadamente 18.000 clientes da plataforma Orion, incluindo várias agências governamentais dos EUA, baixaram atualizações com código malicioso injetado neles. Este código concedeu acesso backdoor não autorizado a sistemas e redes privadas. A SolarWinds não descobriu a violação até dezembro de 2020. Seguiu-se um escândalo internacional.
Algumas semanas depois, em janeiro de 2021, um invasor obteve credenciais usadas na criação de imagens do Docker envolvendo o software Codecov, devido a um erro no processo de compilação. Essas credenciais permitiram ao invasor sequestrar o Codecov, um software para testar a cobertura de código dos desenvolvedores, e transformá-lo em um verdadeiro cavalo de Tróia: como o software é usado em ambientes de integração contínua (CI), ele tem acesso às credenciais secretas da compilação processos (voltaremos a isso).
O invasor conseguiu, assim, desviar centenas de credenciais de usuários do Codecov, permitindo que ele acessasse o maior número possível de sistemas seguros. A empresa só detectou a violação alguns meses depois, em abril.
Em 2 de julho de 2021, cerca de noventa dias depois, um sofisticado grupo de ransomware explorou uma vulnerabilidade nos servidores Kaseya Virtual System Administrator (VSA) – afetando aproximadamente 1.500 pequenas empresas. A Kaseya é uma desenvolvedora de software de gerenciamento de rede, sistema e infraestrutura usado por provedores de serviços gerenciados (MSPs) e outros contratados de TI. Embora um ataque de ransomware tenha assumido o controle dos sistemas dos clientes, o ataque foi contido e derrotado após alguns dias.
Mas essa não é a maior vulnerabilidade da cadeia de suprimentos de 2021. Em dezembro de 2021, alguns meses após o incidente da Kaseya, ocorreu o que é sem dúvida o ataque mais simples, mas mais difundido, à cadeia de suprimentos de software. Depois que uma prova de conceito (POC) inicial foi divulgada, os invasores começaram uma exploração massiva de uma vulnerabilidade que afeta o Apache Log4j, uma biblioteca de log de código aberto extremamente popular no ecossistema Java.
Embora uma atualização corrigindo o problema tenha sido proposta de forma relativamente rápida, o fato dessa biblioteca, mantida por apenas um punhado de pessoas, ser usada em grande escala em todo o mundo e raramente de maneira transparente, criou uma enorme superfície de ataque que levará anos para resolver: a Agência de Segurança Cibernética e Infraestrutura dos EUA (CISA) acaba de descrevê-lo como ” endêmico “, o que significa que provavelmente ressurgirá na próxima década.
Apesar de sua magnitude, essa vulnerabilidade está longe de ser um caso isolado: o número de ataques usando o ecossistema de código aberto como vetor de propagação para atingir as cadeias de suprimentos aumentou 650% entre 2020 e 2021 . A Agência Europeia de Cibersegurança (ENISA) prevê que os ataques à cadeia de abastecimento quadruplicarão até 2022 .
Todos esses ataques e vulnerabilidades destacaram a falta de visibilidade e ferramentas para proteger efetivamente a cadeia de suprimentos, sejam sistemas para inventariar o uso de componentes de código aberto, verificar sua integridade ou impedir o vazamento de informações confidenciais. Sobre este último ponto, é importante dar um passo atrás e olhar mais de perto para este elemento-chave da segurança.
A chave para a cadeia de suprimentos: segredos
Obter credenciais não criptografadas é a maneira perfeita de um hacker girar e descer a cadeia de suprimentos de um fornecedor para seus clientes: com credenciais válidas, os invasores operam como usuários autorizados e a detecção pós-intrusão se torna muito mais difícil.
Do ponto de vista defensivo, os segredos codificados são um tipo único de vulnerabilidade. O código-fonte é um ativo com muitos vazamentos porque, por natureza, é destinado a ser clonado e distribuído com frequência em várias máquinas. Na verdade, os segredos do código-fonte viajam com ele. Mas ainda mais problemático é que o código também tem uma ‘memória’.
Hoje qualquer repositório de código é gerenciado através de um sistema de controle de versão (VCS), geralmente Git , que mantém uma linha do tempo perfeita de todas as alterações que foram feitas nos arquivos na base de código, às vezes ao longo de décadas. O problema é que segredos ainda válidos podem se esconder em qualquer lugar nessa linha do tempo, abrindo uma nova dimensão, desta vez histórica, para a superfície de ataque de software.
Infelizmente, a maioria das verificações de segurança limita-se a verificar o estado atual, implantado ou prestes a ser implantado do código-fonte de um aplicativo. Em outras palavras, quando se trata de segredos enterrados em um commit antigo ou mesmo em um branch nunca implantado, as ferramentas tradicionais são completamente cegas.
Somente no ano passado, mais de 6 milhões de segredos foram publicados em repositórios públicos apenas no GitHUb: em média, 3 commits de cada 1.000 continham um segredo. Isso representa um aumento de cinquenta por cento em relação ao ano anterior.
Um grande número desses segredos deu acesso a recursos corporativos. É importante entender que mesmo que a maioria dos projetos de código aberto hospedados no GitHub sejam repositórios pessoais, é muito fácil para um desenvolvedor profissional publicar inadvertidamente código dando acesso a recursos corporativos. Acontece regularmente!
Portanto, não é de surpreender que um agente malicioso que pretenda realizar um ataque à cadeia de fornecimento de software observe atentamente os repositórios públicos no GitHub: eles teriam uma boa chance de descobrir falhas à mão, principalmente segredos presentes na fonte código que lhe permitiria autenticar-se em um sistema sem levantar qualquer suspeita.
Uma vez que um segredo é publicado, ele deve ser imediatamente considerado como comprometido: um experimento simples consiste em publicar voluntariamente um ” token canário “, ou seja, um código que tem a aparência de um segredo válido, com um mecanismo de alerta acionado quando é usado. O tempo entre a publicação e o alerta é de 4 segundos em média! Este espaço é monitorado de perto e explorado ativamente.
Para neutralizar o risco de invasão o mais rápido possível, há apenas uma solução: a revogação imediata do segredo. Mas, por pânico ou falta de conhecimento técnico, algumas pessoas tentam encobrir o erro adicionando um commit que apaga o segredo, o que não mitiga em nada a falha de segurança: de fato, o Git acompanha todo o histórico de código adicionado, modificado ou apagado ao longo do tempo. Na prática, isso significa que é difícil apagar todos os vestígios de um erro passado. Isso também significa que, em muitos casos, o segredo permanecerá disponível online mesmo depois de ter sido removido do estado “final” do código.
Mas os problemas não param por aí. Em nosso cenário, como o arquivo que contém o segredo é substituído por um arquivo “limpo”, o segredo não será mais detectável durante a revisão manual do código por um colega (uma prática comum) ou por ferramentas tradicionais de segurança de aplicativos, como scanners, que também consideram apenas a versão mais recente do código-fonte. Pior, a falha será duplicada toda vez que o código for clonado e, portanto, corre o risco de ser propagado silenciosamente por muito tempo. Em outras palavras, uma dádiva de Deus para os hackers.
Em 3 de julho, o CEO da gigante de criptomoedas Binance alertou sobre uma violação massiva que supostamente vazou “1 bilhão de registros de residentes [chineses]” pertencentes à polícia de Xangai, incluindo “nome, endereço, identidade nacional, telefone celular, polícia e registros médicos.” A causa? Um fragmento de código-fonte contendo o segredo para se conectar a um banco de dados titânico de informações pessoais foi supostamente copiado e colado em um blog por desenvolvedores do CSDN chinês .
Repos privados também foram afetados
Sem surpresa, esta é apenas a ponta do iceberg. Os repositórios privados escondem muito mais segredos do que os seus homólogos públicos. Trabalhar em um ambiente fechado fornece uma falsa sensação de segurança, tornando os colaboradores um pouco menos suspeitos e, portanto, estatisticamente mais propensos a “deixar um segredo vazar”. Tolerar a presença de segredos em repositórios não expostos publicamente seria um grande erro.
De fato, não importa quão privados sejam esses repositórios, os segredos que eles contêm podem ser usados como alavanca em um ataque, permitindo que os adversários que tiveram acesso ao repositório mudem para outros sistemas ou elevem seus privilégios. Existem muitos cenários de hackers, mas todos eles têm uma coisa em comum: usar quaisquer segredos encontrados para maximizar o impacto de um ataque.
As equipes de segurança de aplicativos estão bem cientes do problema. Infelizmente, a quantidade de trabalho envolvida na investigação, revogação e rotação de segredos toda semana é simplesmente esmagadora, quanto mais cavar anos de código inexplorado.
As equipes de segurança cibernética estão levando muito a sério os segredos codificados no código-fonte e os riscos que eles trazem. Eles estão classificados em 15º lugar entre as vulnerabilidades mais “comuns e impactantes” na famosa lista CWE Top 25 2022 (Common Weakness Enumeration).
Uma diferença fundamental, muitas vezes esquecida, que separa essa vulnerabilidade de todas as outras, como os exemplos anteriores nos mostraram, é que os segredos encontrados no código-fonte podem ser explorados sem que o software esteja em produção! Em outras palavras, é o próprio código que carrega uma vulnerabilidade, não a lógica subjacente.
Vimos, portanto, como os segredos representam um elemento crítico na segurança da cadeia de suprimentos. Vejamos agora como as organizações estão respondendo a essa nova ameaça no ciclo de desenvolvimento.
A resposta das organizações: trazer segurança para o ciclo de desenvolvimento
O surgimento do DevSecOps
As cadeias de suprimentos de software têm muitas áreas cinzentas que não são abordadas pelos métodos tradicionais de segurança. As organizações perceberam a necessidade de introduzir segurança no ciclo de vida de desenvolvimento que atinja o equilíbrio certo entre produtividade e resiliência.
Assim nasceu o movimento DevSecOps. DevSecOps consiste em inserir segurança nas práticas de DevOps. Como lembrete, DevOps é uma filosofia de desenvolvimento que reúne processos e tecnologias que permitem aos desenvolvedores cooperar de forma mais eficaz com as equipes operacionais. Costumamos falar sobre o pipeline de DevOps (a espinha dorsal da cadeia de suprimentos de software) que se caracteriza por sua continuidade: trata-se de poder integrar, testar, validar e entregar código em pré-produção, de forma contínua.
As abordagens de segurança tradicionais estavam em desacordo com a filosofia do DevOps: entregar cada vez mais rápido e adaptar-se à medida que avança. Houve atrito significativo entre as equipes de segurança de aplicativos e as equipes de desenvolvedores, com culturas, conhecimentos e métodos muito diferentes. Essa divisão, fonte de muitos mal-entendidos, acabou contribuindo para a fragilidade do ciclo de desenvolvimento.
Para os gerentes de segurança, o desafio era manter a velocidade do DevOps enquanto reforçava a postura de segurança aprimorada: incluindo regras de segurança desde os estágios iniciais do ciclo de desenvolvimento (planejamento, design), disseminando as melhores práticas e reduzindo o tempo médio de correção (MTTR) capturando mais falhas “benignas” mais cedo.
Mais do que um método, é sobretudo um ideal pelo qual as empresas desejam lutar. O caminho não é longo: as diferenças culturais são tenazes e muitas vezes levam anos para desaparecer. Vários caminhos foram propostos para promover essa transição.
A primeira avenida é contar com ferramentas modernas. Os desenvolvedores adotam ferramentas intuitivas que se integram perfeitamente com seus ambientes de trabalho: a linha de comando, API, IDE (Integrated Development Environment), ou até mesmo seu sistema de controle de versão (VCS). Até recentemente, as ferramentas típicas do analista de segurança estavam muito distantes deste mundo, com jargão muito específico e muitas vezes impenetrável. Os fornecedores de software de segurança fizeram grandes avanços nessa área, oferecendo aos desenvolvedores a oportunidade de se familiarizarem com os conceitos de segurança e se tornarem autossuficientes em uma ampla área.
A automação também é fundamental para permitir a criação de sistemas de segurança eficazes. Engenheiros de software são especialistas em automação, então realmente não fazia sentido que eles não pudessem implementar, ou mesmo entender, as regras de segurança impostas a eles para proteger a cadeia de suprimentos. Eles também são os mais bem informados sobre os sistemas que precisam ser defendidos. A combinação de seu conhecimento com a experiência dos engenheiros de segurança permite o melhor uso dos recursos disponíveis e equipes mais felizes.
Talvez o elemento mais importante do DevDecOps seja a ideia de que a segurança deve fazer parte de todas as etapas do ciclo de desenvolvimento. Sua segurança não pode existir apenas como uma simples lista de verificação a ser marcada antes do lançamento de uma nova versão.
Para alcançar esse resultado, é fundamental abordar um conceito importante: a responsabilidade compartilhada.
Responsabilidade compartilhada e shift-left
O novo modelo de segurança significa compartilhar a responsabilidade entre todos os membros envolvidos no projeto. Compartilhamento dentro de equipes multifuncionais, em vez de em silos, como era historicamente o caso (uma única equipe independente responsável pela segurança, auditoria e garantia de qualidade).
O termo “shift left” é frequentemente usado para ilustrar esse desejo de tirar a segurança de seu silo para mover as operações de segurança mais cedo e economizar dinheiro na detecção e correção. No entanto, este termo, popularizado no início dos anos 2000 , descreve um resultado operacional desejado e não uma maneira real de alcançá-lo. Para uma organização que deseja embarcar em uma transformação DevSecOps, é melhor se concentrar em como induzir essa mudança para proteger efetivamente sua cadeia de suprimentos de software.
O empoderamento dos desenvolvedores é um fator essencial para isso. Como os primeiros artesãos do mundo digital, eles devem estar envolvidos nas decisões de segurança para levar em consideração suas necessidades e métodos de trabalho. Uma diretriz simples, mas poderosa, é sempre fazer do caminho mais curto também o mais seguro.
Assim, uma ferramenta para prevenir os erros mais comuns (como esquecer segredos no código-fonte) deve ser fácil de usar e não criar atrito com a forma como as equipes desenvolvem o código. Uma boa ferramenta deve provar sua utilidade e valor sem parecer que resultará em ‘bloqueio de fornecedor’. Também deve ser capaz de interagir com as equipes de segurança, que não vão desaparecer! Pelo contrário, as equipes de segurança, que tendem a ser menores do que as equipes de desenvolvimento correspondentes, devem ser mobilizadas rapidamente para os casos mais complexos.
No passado, a segurança de aplicativos era considerada uma área que precisava permanecer impenetrável para garantir sua eficácia, mas esses dias se foram. Hoje, há um desejo de que os testes de segurança sejam feitos ao longo do ciclo e que os resultados permitam a correção sem necessariamente escalar as equipes de segurança.
Promover a propriedade da segurança em cada etapa do ciclo requer um esforço geral de transparência entre todas as equipes. Esta é uma condição obrigatória para criar um ambiente de confiança e fomentar uma cultura que se recuse a usar a culpa como ferramenta de responsabilização.
De fato, mesmo funções mais distantes do domínio técnico devem fazer parte dessa transformação. Por exemplo, os gerentes de produto também devem levar em conta a segurança dos produtos que projetam em seu processo de tomada de decisão.
A resposta das empresas para enfrentar os novos riscos da cadeia de fornecimento de software será, portanto, técnica e organizacional . A colaboração entre as diferentes profissões que trabalham ao longo da cadeia de abastecimento é agora uma prioridade para a segurança dos sistemas de informação.
FONTE: THE HACKER NEWS