Linux Foundation identifica os componentes de software de código aberto mais importantes e seus problemas

Para criar esse trabalho, a CII e a LISH fizeram parceria com a Software Composition Analysis (SCAs) e empresas de segurança de aplicativos como Snyk e Synopsys Cybersecurity Research Center. Eles combinaram dados de uso privado com conjuntos de dados disponíveis ao público para identificar mais de 200 dos projetos de software de código aberto mais usados.

Estes não são os programas – Apache, MySQL, Linux – que provavelmente vêm à sua mente. Por toda a sua importância fundamental, são os pequenos programas de blocos de construção que são mais amplamente utilizados.

Eles podem ser pequenos, às vezes menos de cem linhas de código (LoC), mas são vitais. Como Frank Nagle, professor da Harvard Business School e co-diretor do projeto Census II, disse:

A FOSS era vista como o domínio de entusiastas. No entanto, agora se tornou um componente integrante da economia moderna e é um elemento fundamental das tecnologias cotidianas, como smartphones, carros, Internet das Coisas e inúmeras peças de infraestrutura crítica. O entendimento de quais componentes são mais amplamente usados e mais vulneráveis nos permitirá ajudar a garantir a saúde continuada do ecossistema e da economia digital.

Pequenos programas

São aqueles pequenos programas ocultos que, se você não ficar de olho neles, podem causar problemas. Por exemplo, com o bug de segurança OpenSSL Heartbleed, o verdadeiro problema não estava no relativamente conhecido programa de segurança OpenSSH, mas em sua biblioteca criptográfica de nível mais básico e mais obscura, o OpenSSL.

Uma vez que esses componentes de código aberto entram em um programa voltado para o usuário, eles não serão lançados.

Muitos desses subprogramas estão em JavaScript. Em grande parte, isso ocorre porque eles são pequenos – 112 LoC – e geralmente executam apenas uma única função. Por outro lado, o módulo Python médio no repositório PyPI possui mais de 2.200 LoC. Portanto, quando você mede programas por dependências, o JavaScript aparece com muito mais frequência.

OS PROGRAMAS JAVASCRIPT MAIS USADOS

Async: um módulo utilitário que fornece funções para trabalhar com JavaScript assíncrono. Embora tenha sido originalmente projetado para uso com Node.js e instalável via npm install async, ele também pode ser usado diretamente no navegador.
Inherits: ‘herança amigável’ ao navegador totalmente compatível com o node.js padrão inherits.
Isarray: matriz para navegadores mais antigos e versões obsoletas do Node.js.
Kind-of: obtenha o tipo JavaScript nativo de um valor.
Lodash: uma moderna biblioteca de utilitários JavaScript que oferece modularidade, desempenho e extras.
Minimist: analisa as opções de argumento. Este módulo é o centro do analisador de argumentos do otimista sem toda a decoração fantasiosa.
Natives: chama os módulos JavaScript nativos do Node.js.
Qs: Uma biblioteca de análise e string de string de consulta com alguma segurança adicional
Readable-stream: fluxos principais do Node.js. para a terra do usuário.
String_decoder: string_decoder do núcleo do nó para a terra do usuário.

OS COMPONENTES DE SOFTWARE NÃO JAVASCRIPT MAIS USADOS

Com.fasterxml.jackson.core: jackson-core: parte principal do Jackson , um processador JavaScript Object Notation (JSON) que define a API de Streaming, bem como abstrações compartilhadas básicas.
Com.fasterxml.jackson.core: jackson-databind: Pacote geral de ligação de dados para Jackson (2.x): funciona em implementações de API de streaming.
Com.google.guava: guava: bibliotecas principais do Google para Java.
Commons-codec: O software Apache Commons-Codec fornece implementações de codificadores e decodificadores comuns, como Base64, Hex, Phonetic e URLs.
Commons-io: O Commons IO é uma biblioteca de utilitários para ajudar no desenvolvimento da funcionalidade de IO.
Httpcomponents-client: O projeto Apache HttpComponents é um conjunto de ferramentas de componentes Java de baixo nível focados em HTTP e protocolos associados.
Httpcomponents-core: O projeto Apache HttpComponents é um conjunto de ferramentas de componentes Java de baixo nível focados em HTTP e protocolos associados.
Logback-core: a estrutura de log confiável, genérica, rápida e flexível para Java.
Org.apache.commons: commons-lang3: um pacote de classes de utilitários Java para as classes que estão na hierarquia de java.lang ou são consideradas tão padrão que justificam a existência em java.lang.
Slf4j: Fachada de log simples para Java.

Ao longo do caminho, os pesquisadores descobriram que o mito do desenvolvedor de código aberto solitário que trabalha por amor à codificação no porão de seus pais é exatamente isso: um mito. Um programador pode começar em casa, mas não fica lá – a menos que goste do escritório em casa.

Em vez disso, a pesquisa encontrou uma alta correlação entre ser empregado e ser o principal colaborador dos pacotes FOSS mais populares. Uma análise dos dados do GitHub de 2017 descobriu que alguns dos desenvolvedores mais ativos do FOSS contribuíram para projetos nos endereços de email de funcionários da Microsoft, Google, IBM ou Intel. A CII e os parceiros investigarão mais exatamente quem são os desenvolvedores de código aberto de hoje e para quem trabalham em um estudo futuro.

Os pesquisadores também encontraram vários problemas comuns com componentes de código aberto.

A primeira é que há pouca rima ou razão para a nomeação de programas. A falta de um esquema de nomeação padronizado para componentes de software torna o rastreamento desses programas uma grande dor. Isso não é exclusivo do software de código aberto. O Instituto Nacional de Padrões e Tecnologia (NIST) e a Administração Nacional de Telecomunicações e Informação (NTIA) lidam com esse problema há décadas.

A Linux Foundation e os parceiros acham que há uma “necessidade crítica de um esquema padronizado de nomeação de componentes de software”. Eles não estão errados. “Até que exista, as estratégias de segurança, transparência e muito mais terão efeito limitado. As organizações permanecerão categoricamente incapazes de se comunicar”, e “dada a crescente frequência e sofisticação dos incidentes de cibersegurança nos quais a cadeia de fornecimento de software desempenha um papel importante. parte “, este é um problema real.

Outro problema que você pode não ter considerado – mas é muito comum nos círculos de código aberto – é que muitos desses programas ainda vivem em contas individuais de desenvolvedor. “Dos dez principais pacotes de software mais usados em nossa análise, a equipe da CII descobriu que sete estavam hospedados em contas de desenvolvedor individuais”. O que acontece se uma dessas contas for invadida? Você, mais abaixo na cadeia de suprimentos de software, sabe?

Você pode. Se, por exemplo, um programa Node.j minúsculo e obscuro, chamado teclado esquerdo, foi removido por seu desenvolvedor. Isso aconteceu e causou a falha de milhares de programas JavaScript npm.

Ou, novamente, você pode não saber. Em outro exemplo, um hacker obteve acesso à popular biblioteca JavaScript Event-Stream e colocou um backdoor no código. Ele então adicionou código malicioso à biblioteca, o que o permitiu roubar o Bitcoin. Quanto? Nós não sabemos. Nós podemos nunca saber.

Claramente, as contas de desenvolvedor individuais precisam de mais proteção do que estão recebendo. O programa de crachá CII da Linux Foundation e a Trust and Security Initiative incorporam a segurança da conta do desenvolvedor em seus controles para mitigar esses riscos.

O problema final é que o código aberto não escapou da maldição do software legado. Os desenvolvedores passam para programas mais novos ou versões mais recentes de seus programas antigos, mas os programadores posteriores ainda dependem do programa antigo. Esses desenvolvedores relutam em mudar quando o novo pacote de substituição geralmente faz o mesmo trabalho. Isso é especialmente verdadeiro quando o novo componente vem, como costuma acontecer, com erros de compatibilidade. Além disso, existem os custos financeiros e de tempo associados à mudança para o novo software quando não há garantia de nenhum benefício adicional. Ao mesmo tempo, porém, como o programa mais antigo, mas ainda amplamente utilizado, não está sendo atualizado, podem ser descobertas falhas de segurança e deixadas sem correção.

Em resumo, os desenvolvedores de código aberto devem começar a resolver os problemas do software legado. Manter o código nunca é tão divertido quanto desenvolver um novo código, mas é um trabalho necessário.

Por falar em trabalho, este relatório em si é apenas o começo. Como Jim Zemlin, diretor executivo da Linux Foundation, disse:

“O relatório começa a fornecer um inventário do software compartilhado mais importante e das vulnerabilidades em potencial e é o primeiro passo para entender mais sobre esses projetos, para que possamos criar ferramentas e padrões que resultem em confiança e transparência no software”.

Tim Mackey, principal estrategista de segurança do Synopsys Cybersecurity Research Center, acrescentou:

“Identificar os componentes FOSS mais difundidos nos ecossistemas comerciais de software, combinado com um entendimento claro de sua postura de segurança e das comunidades que os mantêm, é um primeiro passo crítico. Além disso, as organizações comerciais podem fazer sua parte realizando análises internas de seus uso de código aberto e envolvimento ativo com as comunidades de código aberto apropriadas para garantir a segurança e a longevidade dos componentes dos quais eles dependem “.

Zemlin concluiu:

“O código aberto é uma parte inegável e crítica da economia atual, fornecendo os fundamentos para a maior parte do nosso comércio global. Centenas de milhares de pacotes de software de código aberto estão em aplicativos de produção em toda a cadeia de suprimentos, para entender o que precisamos avaliar quanto a vulnerabilidades é o primeiro passo para garantir segurança e sustentabilidade a longo prazo do software de código aberto “.

zdnet

Assuntos