Skip to main content

Divulgação responsável: CEO e CTO da CodeCov compartilham aprendizados sobre a violação

Escrito por
The Secure Developer podcast

9 de dezembro de 2021

0 minutos de leitura

Em janeiro de 2021, a CodeCov sofreu um ataque à cadeia de suprimentos que expôs variáveis de ambiente de clientes. Nos meses seguintes, a comunidade de segurança de aplicações analisou detalhadamente as características da violação e seus aspectos técnicos para entender o que deu errado e como combater ataques semelhantes no futuro. Mas outro resultado interessante da violação foram os insights sobre um tema um pouco menos glamouroso: a divulgação responsável.

Em outubro de 2021, Jerrod Engelberg, CEO da CodeCov, e Eli Hooten, CTO, participaram do podcast The Secure Developer para compartilhar uma perspectiva interna sobre os acontecimentos. A conversa com Guy mostrou como é estar no centro de um incidente e levantou questões importantes sobre a melhor forma de responder a incidentes semelhantes.

Ouça o episódio completo hoje

O incidente de segurança da CodeCov

Antes de analisarmos as implicações desse episódio, vamos recapitular rapidamente. A CodeCov é uma ferramenta de cobertura de código que gera relatórios legíveis por máquina enquanto os desenvolvedores executam testes. Esses relatórios são processados pelo uploader da CodeCov, que fornece os dados de cobertura relevantes. Os relatórios legíveis por máquina chegam ao uploader da CodeCov por meio de um provedor de integração contínua, como Github, Gitlab ou Bitbucket, colocando a CodeCov no centro da cadeia de suprimentos de software.

Na época do incidente, a CodeCov usava um script curl|bash (também chamado de “curl pipe bash”, “curl bash piping” etc.) para enviar relatórios ao servidor, hospedado em um bucket CDN `private write, public read`. O invasor conseguiu extrair uma credencial de uma camada compactada da imagem Docker empresarial da CodeCov e acessar o bucket CDN, onde fez alterações maliciosas no script bash. O script alterado foi incorporado ao pipeline de CI de todos os clientes que fizeram uma solicitação pull ou merge entre a violação e a revogação das credenciais. Isso permitiu que os invasores se infiltrassem nos ambientes dos clientes onde a CI estava em execução, imprimissem as variáveis de ambiente e as enviassem a um servidor de terceiros para uso posterior.

O impacto desse ataque variou de um cliente para outro. Se o cliente gerenciava a CI em um repositório público, provavelmente não tinha nada relevante armazenado nas variáveis de ambiente. Já se usava um repositório privado, em que a CI interage intensamente com a pilha tecnológica e contém informações secretas, a violação era motivo de grande preocupação.

Como em qualquer ataque à cadeia de suprimentos, a única certeza era que as informações tinham sido vazadas. Não havia como saber o que os invasores pretendiam fazer com as variáveis de ambiente roubadas, o que significava que a equipe precisava agir com rapidez e determinação.

A resposta da CodeCov

Engelberg resumiu a premissa da CodeCov para a divulgação assim: “Se sequer um cliente não conseguir receber notícias nossas e não tomar as medidas necessárias, já será um cliente a mais.” Na prática, porém, esse princípio se tornou um desafio. Ao entrar na CodeCov, os clientes podem usar um endereço de e-mail ou um login social (como OAuth, Github ou Bitbucket), que mantém privadas suas informações de contato. Uma opção conveniente que, mais tarde, se tornou um fator crítico no processo de divulgação.

Para os clientes que criaram uma conta diretamente na CodeCov ou informaram seus dados de contato, a solução foi simples. Foram enviados avisos por e-mail a todos os endereços disponíveis, informando os clientes sobre a violação e incentivando-os a agir. Infelizmente, a maioria dos usuários da CodeCov não fazia parte desse grupo. Por isso, a equipe da CodeCov tomou todas as medidas possíveis para alcançar os demais clientes.

A CodeCov fez comunicados públicos depois de notificar as autoridades federais; anúncios detalhando a violação foram promovidos e amplificados pela mídia de tecnologia; e a empresa inundou a aplicação com notificações. Embora todas as medidas razoáveis tenham sido tomadas para garantir que sua base de usuários fosse informada, vale refletir sobre as circunstâncias que levaram a uma reação tão abrangente.

Se a CodeCov tivesse exigido que todos os usuários informassem dados pessoais, como um endereço de e-mail, teria sido simples entrar em contato com todos após a violação. Dar aos clientes a opção de usar um login social permitiu que mantivessem seus dados pessoais mais privados, mas também criou obstáculos sérios quando foi necessário se comunicar com urgência. O processo de divulgação da CodeCov teria sido diferente se avisar os usuários fosse tão simples quanto enviar um e-mail em massa? Provavelmente não. Como disse Hooten: “Acho que você sabe que está fazendo a coisa certa quando a resposta é óbvia, mesmo que o caminho a seguir seja doloroso ou difícil.” Os valores fundamentais da CodeCov teriam levado a equipe a ser transparente de qualquer forma.

Como minimizar o impacto nos negócios com transparência

Nenhuma empresa sai completamente ilesa de um incidente de segurança, mas a CodeCov conseguiu minimizar o impacto negativo com uma comunicação constante e transparente. Apesar de ter agido rapidamente, houve cancelamentos. Como explicou Engelberg, houve “clientes que disseram: ‘Ei, não podemos usar vocês neste momento.’ Ou defensores do nosso produto que disseram: ‘Adoro usar o produto de vocês, mas a suspensão foi determinada e não posso mais usá-lo’”. No entanto, a perda de clientes teria sido muito maior sem a transparência demonstrada pela equipe. É muito mais fácil corrigir vulnerabilidades do que reconstruir a confiança.

Assim como a Snyk, a CodeCov é uma aplicação feita para desenvolvedores — e desenvolvedores precisam de dados, não de conversa fiada. Ao se ater aos fatos e pedir ajuda à comunidade de segurança em geral, a CodeCov manteve sua credibilidade e seu compromisso com os desenvolvedores mesmo em meio a uma crise.

“A melhor coisa que você pode fazer pelo setor que ama e pelos desenvolvedores que busca atender é simplesmente seguir em frente sem medo.”

Jerrod Engelberg

CEO, CodeCov

Além da violação

A violação de segurança da CodeCov revelou verdades que vão muito além de um único incidente. A natureza do ataque destaca possíveis armadilhas que afetam todo o setor. A principal delas é um problema de distribuição básica. À medida que o software de código aberto se torna cada vez mais essencial ao ciclo de desenvolvimento, suas dependências vêm junto. Os benefícios do código aberto são inegáveis. O importante é descobrir como usá-lo com segurança.

Para reforçar a segurança após a violação, a CodeCov adicionou medidas como somas de verificação SHA e verificação de assinaturas. Os usuários foram incentivados a aproveitar essas verificações para garantir que os scripts baixados viessem diretamente da CodeCov. No entanto, não há como exigir o uso dessas verificações. Como explicou Engelberg: “Até que isso seja zero trust [...], sempre haverá esse aperto de mãos, certo? Podemos torná-lo cada vez mais sofisticado, mas é algo em que penso bastante quando planejamos os próximos passos e o que pode vir a seguir.”

Podemos conscientizar os usuários sobre os possíveis riscos e oferecer ferramentas para auditar o código, mas não podemos obrigar ninguém a tomar medidas adicionais. O acordo de confiança entre empresa e cliente está profundamente enraizado na cultura do desenvolvimento. Nossa tarefa como setor é definir o melhor plano para mitigar riscos.

Quer saber mais sobre a violação da CodeCov e o que ela revelou sobre o setor? Acesse The Secure Developer para ouvir o podcast completo. Engelberg e Hooten abriram as portas da CodeCov e compartilharam sua experiência em primeira mão sobre preparação interna de segurança, conselhos para CEOs e CTOs, como a empatia mudou o rumo da crise e muito mais.