Proteger as cadeias de suprimentos de código-fonte aberto pode ajudar a prevenir o próximo grande ataque cibernético

Após meses de análise, sabemos que muitas (alguns podem argumentar que a maioria) organizações são vulneráveis ​​a ataques à cadeia de suprimentos. Em um mundo de negócios em que todos temos tantas dependências de terceiros, nenhuma organização é uma ilha e ninguém está imune. O incidente da SolarWinds é um exemplo de ataque à cadeia de suprimentos de software no qual o código comprometido foi empurrado para ser executado nos ambientes do cliente. Como resultado, muitos dos clientes da SolarWinds também foram afetados, incluindo várias empresas da Fortune 500. Este cenário é uma das poucas maneiras pelas quais um ataque à cadeia de suprimentos pode ocorrer.

Claro, a próxima pergunta lógica é: Qual a melhor maneira de me defender contra esse tipo de incidente? O ponto de partida da proteção é o conhecimento. Saiba o que está em seu software mapeando suas cadeias de suprimentos de software. Como parte dessa visibilidade e compreensão, outra questão urgente que as equipes de CISOs e DevSecOps precisam abordar são suas dependências de componentes de código aberto no pipeline de desenvolvimento.

O código aberto é o “fruto mais fácil” para os criminosos

Os componentes de código aberto tornaram-se parte essencial do desenvolvimento por razões óbvias. Atualmente, existem componentes de código aberto em todos os tipos de software – até mesmo em software proprietário. É simplesmente a natureza da besta de como o software é desenvolvido. As equipes de desenvolvimento estão continuamente usando pacotes e contêineres de código aberto para levar a inovação adiante e lançar novos códigos.

Na verdade, o relatório 2021 State of Software Supply Chain da Sonatype, IT Revolution e Muse.dev revela que os quatro principais ecossistemas de código aberto lançaram 6.302.733 novas versões combinadas e 723.570 novos projetos no ano passado. O relatório afirma que essas comunidades agora contêm 37.451.682 versões diferentes de componentes, representando um crescimento de 20% ano a ano (ano a ano) no fornecimento global. Mas esse crescimento também significa que, à medida que o código aberto se torna mais difundido, também aumenta o interesse criminoso em tentar explorá-lo. O relatório Sonatype descobriu que os ataques que visam se infiltrar ativamente em código aberto aumentaram 430%.

“[Membros] da comunidade de código aberto mundial estão enfrentando uma ameaça nova e em rápida expansão que não tem nada a ver com adversários passivos explorando vulnerabilidades conhecidas em liberdade – e tudo a ver com atacantes agressivos implantando malware diretamente em projetos de código aberto, ”Afirmam os autores do relatório na pesquisa.

É a própria natureza do que torna o código aberto tão valioso que também o torna explorável. Repositórios não gerenciados, sem supervisão clara, podem ser comprometidos. E a indústria de software atualmente não rastreia a fonte de todos os códigos, nem avalia o nível dos padrões de segurança aplicados nessas fábricas de códigos internacionais. Qualquer pessoa com boas ou más intenções pode inserir facilmente seu código em um repositório. Como o software de código-fonte aberto geralmente contém vulnerabilidades, os ataques aumentaram neste “fruto mais fácil”.

Manter o controle das dependências de código aberto é uma tarefa incompreensível. Mas os líderes de segurança devem saber onde os desenvolvedores estão obtendo seu código aberto e de terceiros embalados, contêineres e infraestrutura como código.

Como as empresas podem gerenciar melhor os riscos das cadeias de suprimentos de código aberto?

Do topo de uma organização e de toda a TI, todos devem se perguntar sobre o nível de segurança do código-fonte aberto que está sendo usado no desenvolvimento. As três etapas principais a seguir podem ajudar a dar às empresas mais visibilidade sobre o código aberto:

1. Crie e mantenha uma lista de materiais de software (SBOM)

Exigido recentemente pelo governo Biden para organizações que desejam trabalhar com agências federais, o SBOM é uma ferramenta que todas as organizações devem incorporar em sua estratégia de segurança. Um SBOM é o equivalente a uma lista de ingredientes de software em seu ambiente.

2. Mapeie

Você não pode proteger o que você não pode ver. As empresas precisam realizar um mapeamento de proveniência para determinar o nível de segurança de onde o código foi criado.

3. Use um sistema de classificação de segurança de software

Estabeleça uma escala de classificação para classificar cada parte do código para determinar com mais eficácia o risco que uma empresa está herdando do código. Isso é essencial para obter um nível de confiança no código que você está usando em seu ambiente.

Os paralelos podem ser traçados com o processo do FDA para aprovação de medicamentos, inspecionando os ingredientes e as fábricas onde um medicamento foi feito.

O Google dá o primeiro passo

O Google deu um exemplo de qualidade para a classificação de repositórios de código-fonte aberto. Conhecido como repo scoring, o Google classificou mais de 200.000 repositórios de código aberto de um a 10 usando o programa Google Scorecard para determinar a higiene da segurança dessas “fábricas de código”. Esses dados podem ser usados ​​para entender o risco de proveniência de todos os componentes do SBOM.

No entanto, para uma empresa replicar os esforços do Google internamente em escala, são necessários recursos manuais significativos que aumentarão o atrito entre os desenvolvedores e as equipes de segurança. Aproveitar esses dados fantásticos do Google Scorecard em escala é uma tarefa hercúlea: para cada um dos milhões de códigos no SBOM de seu ambiente, você teria que:

• Identifique sua proveniência (de qual repositório ele veio)
• Examine este repositório com o Google Scorecard, bem como todos os repositórios dos quais ele depende.

Os desenvolvedores desejam inovar, construir e enviar código, enquanto a equipe de segurança deseja garantir que o código seja seguro. Automatizar o processo DevSecOps pode remover muitas das etapas manuais necessárias para proteger o código. Ele cria automaticamente o SBOM, entendendo a proveniência e pode ser facilmente usado para incluir classificações de segurança sobre os locais de proveniência para o SBOM.

Padronização, colaboração e transparência

Essas etapas iniciais do Google são apenas o começo do que o setor precisa fazer. Como uma indústria de software coletiva, precisamos nos perguntar como podemos criar e documentar padrões para repositórios de código e torná-los publicamente acessíveis, de forma que o risco do código seja claro para qualquer empresa que queira usá-lo.

Esse processo deve incluir a criação de padrões de segurança, uma escala de classificação alinhada com os padrões e um mecanismo público para ser transparente sobre a classificação. Essas estruturas são uma necessidade, pois o programa Scorecard do Google não cobre todo o universo do código-fonte aberto, sem mencionar os repositórios fechados usados ​​por fornecedores para desenvolver seu próprio código.

Quanto mais empresas, grandes e pequenas, começarem esse processo, isso promoverá uma maior colaboração no setor, aumentará a confiança na integridade da cadeia de suprimentos do código e deverá ser uma força positiva para a redução de grandes ataques cibernéticos.

Fonte: https://www.helpnetsecurity.com/