0
0
O ataque à cadeia de suprimentos à SolarWinds no final do ano passado enviou uma onda de choque pela comunidade de segurança e fez com que muitos CISOs e líderes de segurança perguntassem: “Minha cadeia de suprimentos de software é segura?”
Após meses de análise, sabemos que muitas (algumas podem argumentar a maioria) organizações são vulneráveis a ataques à cadeia de suprimentos. Em um mundo de negócios no qual todos nós temos tantas dependências de terceiros, nenhuma organização é uma ilha e ninguém está imune. O incidente SolarWinds é um exemplo de um ataque à cadeia de suprimentos de software no qual o código comprometido foi enviado para ser executado em ambientes de clientes. 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 é: Como posso me defender melhor contra esse tipo de incidente? O ponto de partida da proteção é o conhecimento. Saiba o que está no seu software mapeando suas cadeias de suprimentos de software. Como parte dessa visibilidade e compreensão, outra questão premente que as equipes CISOs e DevSecOps precisam abordar é suas dependências de componentes de código aberto no pipeline de desenvolvimento.
O código aberto é a “fruta baixa pendurada” para criminosos
Componentes de código aberto se tornaram uma parte essencial do desenvolvimento por razões óbvias. Componentes de código aberto existem em todos os tipos de software hoje – até mesmo 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 impulsionar a inovação e impulsionar novos códigos.
Na verdade, o relatório State of Software Supply Chain 2021 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 introduziram 723.570 novos projetos no ano passado. O relatório afirma que essas comunidades agora contêm 37.451.682 versões diferentes combinadas de componentes, representando um crescimento de 20% ano após ano (YoY) na oferta global. Mas esse crescimento também significa que, à medida que o código aberto se torna mais difundido, o mesmo acontece com o interesse criminoso em tentar explorá-lo. O relatório Sonatype descobre que os ataques destinados a se infiltrar ativamente no código-fonte aberto aumentaram 430%.
“[Os membros] da comunidade de código aberto do mundo 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 na natureza—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. Não gerenciados, sem supervisão clara, os repositórios de código aberto podem ser comprometidos. E a indústria de software atualmente não rastreia a fonte de todo o código, nem classifica o nível de padrões de segurança aplicados nessas fábricas internacionais de código. Qualquer pessoa com intenção boa ou maliciosa pode inserir facilmente seu código em um repositório. Como o software de código aberto geralmente contém vulnerabilidades, os ataques aumentaram a essa “fruta mais baixa”.
Acompanhar as 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, contêineres e infraestrutura empacotados de código aberto e de terceiros como código.
Como as empresas podem gerenciar melhor o risco das cadeias de suprimentos de código aberto?
Do topo de uma organização e de toda a TI, todos devem 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 do código aberto:
1. Crie e mantenha uma lista de materiais de software (SBOM)
Recentemente mandatada pelo governo Biden para organizações que querem trabalhar com agências federais, a SBOM é uma ferramenta que todas as organizações devem incorporar em sua estratégia de segurança. Uma SBOM é o equivalente a uma lista de ingredientes de software em seu ambiente.
2. Mapeie
Você não pode garantir o que não pode ver. As empresas precisam realizar o mapeamento de proveniência determinando 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 pedaço de código para determinar de forma mais eficaz 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.
Paralelos podem ser desenhados com o processo 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 classificar repositórios de código aberto. Conhecido como pontuação de repositório, o Google classificou mais de 200.000 repositórios de código-fonte aberto de um a 10 usando o programa Google Scorecard para determinar a higiene de segurança dessas “fábricas de código”. Esses dados podem ser usados para entender o risco de proveniência de todos os componentes da 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 desenvolvedores e equipes de segurança. Aproveitar esses fantásticos dados do Google Scorecard em escala é uma tarefa hercúlea: para cada um dos milhões de pedaços de código na SBOM do seu ambiente, você teria que:
- Identifique sua proveniência (de qual repositório ele veio)
- Analise este repositório com o Google Scorecard, bem como todos os repositórios dos quais ele depende.
Os desenvolvedores querem inovar, construir e enviar código, enquanto a equipe de segurança quer garantir que o código esteja seguro. Automatizar o processo DevSecOps pode remover muitas das etapas manuais necessárias para proteger o código. Ele constrói automaticamente a SBOM, entendendo a proveniência, e pode ser facilmente usado para incluir classificações de segurança sobre os locais de proveniência para a SBOM.
Padronização, colaboração e transparência
Esses primeiros passos do Google são apenas o começo do que a indústria precisa fazer. Como uma indústria coletiva de software, precisamos nos perguntar como podemos criar e documentar padrões para repositórios de código e torná-los acessíveis ao público, para que o risco do código seja claro para qualquer empresa que queira usá-lo.
Esse processo deve incluir a criação dos padrões de segurança, uma escala de classificação alinhada com os padrões e um mecanismo público para ser transparente sobre o grau. Esses frameworks são uma necessidade, pois o programa Scorecard do Google não cobre todo o universo de código-fonte aberto, sem mencionar repositórios fechados usados pelos fornecedores para desenvolver seu próprio código.
Quanto mais empresas, grandes e pequenas, iniciarem esse processo promoverão uma maior colaboração no setor, aumentarão a confiança na integridade da cadeia de suprimentos de código e deverão ser uma força positiva para reduzir grandes ataques cibernéticos.
FONTE: HELPNET SECURITY