Como os desenvolvedores estão sob pressão crescente para entregar projetos rapidamente, há um nível crescente de conflito entre as equipes de desenvolvimento e segurança. E os invasores estão aproveitando esse conflito para atingir as cadeias de suprimentos de software.
Então, que tipo de ameaças as empresas enfrentam e o que elas podem fazer para se proteger? Conversamos com Pete Morgan, cofundador e CSO da empresa de segurança da cadeia de suprimentos Phylum para descobrir.
BN: Por que a cadeia de suprimentos de software é um alvo tão atraente para invasores?
PM: Existem três razões principais pelas quais os agentes mal-intencionados visam as cadeias de suprimentos de software:
Os desenvolvedores são os novos de alto valor alvos: Os invasores conhecem os alvos de um suprimento comprometimento da cadeia são desenvolvedores de software ou infraestrutura privilegiada. O comprometimento de qualquer um dos alvos gera chaves de acesso à nuvem, chaves SSH, chaves de assinatura e outros segredos. Essas chaves geralmente permanecem por longos períodos de tempo, o que significa que um comprometimento não detectado permite aos invasores muito acesso e tempo para planejar os próximos estágios com cuidado. Há vários pontos cegos a serem explorados: A cadeia de suprimentos de software é um conceito em constante mudança. Pacotes de código aberto são usados em 85%-95% dos aplicativos e são criados e mantidos por estranhos na Internet. Os desenvolvedores usam esses pacotes sem supervisão ou controles da equipe de segurança. Mapear a verdadeira superfície de ataque para a cadeia de suprimentos de software de uma organização é complicado e varia de acordo com a organização, deixando muitas lacunas. Mantê-lo constantemente ao longo do tempo é ainda mais difícil, oferecendo várias oportunidades para os invasores. A defesa tem que ser perfeita, os atacantes só precisam vencer uma vez. Baixos investimentos para grandes retornos: O custo para atacar a cadeia de suprimentos de software é extremamente baixo e muitas vezes gratuito. Alguns ataques requerem apenas a execução de um script e espera. Até que as organizações melhorem seus programas de segurança da cadeia de suprimentos de software, os invasores sabem que não precisam trabalhar tanto ou usar ataques sofisticados para obter sucesso.
BN: Quais são os principais pontos de atrito entre as equipes de desenvolvimento e segurança?
PM: As equipes de segurança querem mais visibilidade e controle sobre o processo de desenvolvimento, e os desenvolvedores querem menos possíveis obstáculos à inovação. Quando metas, políticas e processos não estão bem alinhados, ou neste caso muitas vezes conflitantes, naturalmente haverá atrito.
BN: Como a segurança pode melhorar o relacionamento com as equipes de desenvolvimento?
PM: A empatia é um grande fator para encontrar pontos em comum entre essas duas equipes, e é essencial que essas duas equipes trabalhem em harmonia para atingir os objetivos críticos de negócios. As equipes de segurança devem incorporar os desenvolvedores nos estágios iniciais da tomada de decisões de segurança e facilitar a adoção de políticas, e os desenvolvedores devem manter a mente aberta quando solicitados a incorporar práticas de segurança em seus processos. Abrir linhas de comunicação, compartilhar feedback regular sobre o que está funcionando e o que não está e adotar tecnologia que automatize a aplicação de políticas e contextualize os problemas sem interromper o processo de desenvolvimento levará a uma cooperação mais eficaz.
BN: Por quê? o malware em pacotes de código aberto é tão perigoso?
PM: Oh, por onde começar! Os pacotes maliciosos são diferentes do malware tradicional, pois a maioria dos pacotes maliciosos não precisa explorar nenhuma vulnerabilidade ou induzir o usuário a executá-los. Um desenvolvedor que instala o pacote errado ou instala um pacote que tem a dependência errada pode ser comprometido e, em 99% das vezes, nunca saberá.
A maioria dos desenvolvedores simplesmente não tem tempo ou ferramentas para analisar o risco das embalagens que usam. Os pacotes têm dependências que têm dependências, e essa cadeia pode ser de 20 a 30 níveis, abrangendo dezenas de milhares de pacotes de código aberto. A maioria das organizações ainda está apenas verificando vulnerabilidades e uso indevido de licenças, de modo que o malware passa facilmente despercebido: é um quebra-e-pega de chaves e segredos para, em seguida, montar novos ataques.
BN: Quais são alguns outros riscos associados ao código-fonte aberto que geralmente são negligenciados?
PM: Existem muitos, mas um que se destaca é a transição do mantenedor. Não é uma vulnerabilidade de software ou pacote malicioso; é um dos muitos riscos de autor que decorrem de práticas comuns no ecossistema de código aberto. Às vezes, um desenvolvedor não tem mais interesse ou tempo para manter um pacote popular de código aberto. Freqüentemente, eles desejam mantê-lo funcional para os usuários que dependem dele, portanto, transferem a manutenção para outro indivíduo ou grupo. É incrivelmente difícil examinar os motivos e incentivos do novo mantenedor, então o controle desses pacotes é simplesmente colocado nas mãos de um estranho diferente da Internet. Se um autor mal-intencionado assumir o controle de um pacote usado em um aplicativo, isso introduz um novo risco que não foi considerado na compilação inicial.
BN: Qual a importância de estar ciente disso e gerenciar dependências?
PM: Devemos ser críticos em relação às dependências porque a inclusão de longo prazo de cada pacote expande drasticamente a superfície de ataque. Precisamos entender o risco de reutilizar código que muda constantemente para defender o software com eficácia. Caso contrário, as organizações continuarão a reutilizar códigos de estranhos na Internet com a estratégia de apenas esperar o melhor. Esta é a razão pela qual a cadeia de suprimentos de software está tanto nas notícias agora.
BN: Como os SBOMs podem ajudar com visibilidade e segurança?
PM: Os SBOMs são um passo na direção certa, mas temo que os regulamentos e mandatos para adotar o processo SBOM por atacado resultem em muito movimento sem melhorias significativas na segurança do software. As ideias de obter visibilidade dos componentes de um projeto de software são óbvias, mas o processo SBOM que vejo é lamentavelmente insuficiente, pois fornece apenas instantâneos incompletos no tempo.
As informações fornecidas pelo SBOM é insuficiente para cobrir a superfície de ataque da cadeia de suprimentos de software, e as implicações para fornecedores e organizações de consumidores adotarem o processo de uso do SBOM assumem uma realidade em que os orçamentos de segurança de aplicativos e/ou segurança de produtos são efetivamente ilimitados. Os formatos e processos do SBOM precisam evoluir significativamente antes de poderem ser adotados de maneira significativa.
BN: Quais padrões, normas ou comportamentos precisam mudar para que as organizações protejam melhor suas cadeias de suprimentos de software?
PM: É necessária uma mudança fundamental de mentalidade. As empresas precisam entender que estão expostas a riscos significativos na cadeia de suprimentos de software agora, e provavelmente há muito tempo. A segurança da cadeia de suprimentos de software está em sua infância, então os ataques estão evoluindo diariamente e as defesas foram criadas apenas nos últimos dois anos. Suponha que seus desenvolvedores estejam sendo ativamente visados e que você tenha uma exposição não realizada ao risco da cadeia de suprimentos de software. Depois de romper a falsa sensação de segurança, você pode começar de um lugar honesto para criar um programa eficaz que pode ser dimensionado com base em suas necessidades exclusivas.
Crédito da imagem: Manczurov/Shutterstock