Como garantir a segurança do DevOps

Ataques à cadeia de suprimentos por meio de repositórios públicos têm se tornado mais frequentes recentemente. Veja como lidar com eles.

Há algum tempo o RubyGems, o canal oficial para distribuição de bibliotecas para a linguagem de programação Ruby, foi envenenado. Um invasor carregou pacotes falsos contendo um script malicioso, assim os programadores que usaram o código em seus projetos infectaram inadvertidamente os computadores dos usuários com malware que alterava endereços de carteiras de criptomoeda.

Não foi o primeiro ataque à cadeia de suprimentos a explorar um repositório público. Mas esse tipo de cenário parece estar ganhando popularidade, o que não é surpresa; um ataque bem-sucedido pode comprometer dezenas ou centenas de milhares de usuários. Tudo depende da popularidade do software desenvolvido com o código do repositório envenenado.

Como os pacotes maliciosos entram nos repositórios?

No caso do RubyGems, o cibercriminoso criou muitos projetos no repositório com nomes semelhantes a pacotes legítimos populares. Conhecida como typosquatting, a técnica depende de desenvolvedores inserirem incorretamente o nome de um pacote e baixarem um malicioso por engano ou, após obterem uma lista de nomes em uma consulta de pesquisa, não saberem qual é genuíno. A tática, geralmente considerada a mais comum para o envenenamento cibernético, foi implantada em ataques por meio do Índice de Pacotes Python e no upload de imagens falsas para o Docker Hub.

No incidente da carteira de criptomoeda Copay, os invasores usaram uma biblioteca cujo repositório estava hospedado no GitHub. Seu criador perdeu o interesse e cedeu os direitos de administrador, comprometendo a popular biblioteca, que muitos desenvolvedores utilizavam em seus produtos.

Às vezes, os cibercriminosos conseguem usar a conta de um desenvolvedor legítimo sem o conhecimento deste e substituir pacotes reais por falsos. Isso aconteceu no caso da ESLint, cujas bibliotecas estavam hospedadas no banco de dados online npm (Node Package Manager).

Comprometimento do ambiente de compilação

As empresas que desenvolvem produtos de software também são alvos potencialmente interessantes para hackers. Os casos em que os clientes dessas empresas são alvos atraem periodicamente a atenção de especialistas em segurança:

  • Em agosto de 2017, cibercriminosos equiparam o software criado pela NetSarang com módulos maliciosos. De acordo com os investigadores, os invasores podem ter comprometido os servidores do software.
  • Em 2018, infectaram o servidor de compilação do aplicativo Piriform. Com isso, compilações do programa CCleaner com código-fonte limpo foram transformadas em malware.
  • Em 2019, nossos especialistas descobriram a campanha APT ShadowHammer, durante a qual malfeitores embutiram uma porta dos fundos em software de várias empresas. De acordo com os resultados da investigação, invasores tiveram acesso ao código-fonte ou introduziram código malicioso na fase de compilação.

O comprometimento do ambiente de compilação não apenas permite a “infecção” do produto final, mas também leva à distribuição de malware como arma contendo uma assinatura digital legítima de um desenvolvedor confiável. É por isso que o processo de desenvolvimento precisa de proteção aprimorada contra interferências externas.

A raiz do problema

Na verdade, o perigo não está no uso de repositórios públicos, mas em uma falha na abordagem moderna de desenvolvimento de software – a metodologia DevOps. Trata-se de um conjunto de práticas destinadas a encurtar o ciclo de desenvolvimento do programa. O desenvolvimento sempre deve equilibrar segurança e usabilidade. Para se manter competitivo no ambiente de hoje, os desenvolvedores precisam lançar novas versões de programas o mais rápido possível, mas melhorar a usabilidade tende a causar uma queda na qualidade ou um TTM mais longo. Como resultado, os desenvolvedores estão sempre tentando minimizar ou contornar completamente a intervenção do pessoal de segurança em suas atividades.

Como resultado, a segurança da informação praticamente não tem controle dessa parte da infraestrutura. Mas o desenvolvimento, a TI e a segurança estão todos trabalhando em direção a um objetivo comum: um produto de qualidade e seguro entregue em tempo hábil. Uma atualização não é boa se contiver um backdoor ou módulo espião. Portanto, em nossa opinião, a indústria deve migrar para uma metodologia DevSecOps.

O DevSecOps é uma tentativa de preencher a lacuna entre a segurança e o DevOps, introduzindo uma cultura de segurança cibernética e a aplicação prática de verificações em todos os estágios do processo de desenvolvimento de software sem comprometer a flexibilidade e a velocidade. Oferecemos ferramentas para auxiliar a parte técnica desse processo.

Nossa solução

O mercado carece de ferramentas que protejam especificamente o processo de desenvolvimento de software. Portanto, ao atualizar nosso Kaspersky Hybrid Cloud Security, levamos em consideração as necessidades dos programadores, equipando os componentes da solução com tecnologias para integrar as ferramentas de segurança no processo de desenvolvimento sem afetar o desempenho. Essas são tecnologias principalmente para escanear repositórios, imagens e contêineres – as coisas certas para prevenir ataques à cadeia de suprimentos.

O Kaspersky Hybrid Cloud Security tem interfaces para interoperabilidade com plataformas de integração contínua (CI) e entrega contínua (CD), como TeamCity e Jenkins. Nossa solução pode ser integrada ao processo de desenvolvimento por meio da linha de comando ou de uma interface de programação de aplicativo.

Essa não é a única inovação em nossa solução, é claro. Clique aqui para mais informações sobre o Kaspersky Hybrid Cloud Security e sobre a proteção do processo DevOps.

Dicas

Como proteger a segurança doméstica

As empresas de segurança oferecem tecnologias inteligentes, principalmente câmeras, para proteger a casa contra roubos, incêndios e outros incidentes. Mas que tal proteger esses sistemas de segurança contra intrusos? É o que faremos para preencher essa lacuna.