0 
0 Vulnerabilidades em componentes de código aberto – como as falhas generalizadas reveladas há 10 meses no Log4j 2.0 – forçaram os cientistas de dados a reavaliar o código aberto frequentemente usado em análises e na criação de modelos de aprendizado de máquina.
De acordo com um relatório da Anaconda, uma empresa de plataforma de ciência de dados, no ano passado, 40% dos cientistas de dados, analistas de negócios e estudantes pesquisados reduziram o uso de componentes de código aberto, enquanto um terço permaneceu estável e apenas 7 % incorporou mais código-fonte aberto em seus projetos. A maioria dos entrevistados não se reporta ao departamento de tecnologia da informação (18%), mas trabalha dentro de seu próprio grupo de ciência de dados ou pesquisa e desenvolvimento (47%), de acordo com o relatório ” 2022 State of Data Science” da Anaconda , divulgado na semana passada. .
Embora os desenvolvedores de software e a TI já tenham começado a verificar o código seguro, as preocupações com a segurança no software de código aberto são uma tendência relativamente nova para o mundo da ciência de dados, diz Peter Wang, cofundador e CEO da Anaconda.
“Vemos uma enorme parcela de pessoas que estão em organizações onde a TI criou uma postura muito rígida em relação ao código aberto e ao Python”, diz ele. “Estes não são desenvolvedores especialistas… Eles são cientistas de dados e pessoas de aprendizado de máquina que podem não ser desenvolvedores muito experientes, usando qualquer coisa que pudessem baixar para fazer suas análises, e então entregaram isso para a TI.”
A segurança dos componentes de código aberto – e a cadeia de fornecimento de software, em geral – tornou-se uma consideração primordial entre desenvolvedores de software, empresas e governos nacionais nos últimos dois anos. Em maio, por exemplo, o Instituto Nacional de Padrões e Tecnologia dos EUA (NIST) emitiu orientações para lidar com os riscos da cadeia de suprimentos de software . Além disso, um número crescente de fornecedores de software se uniu à Open Software Security Foundation (OpenSSF) da Linux Foundation .
No geral, a maturidade dos esforços de segurança das organizações melhorou. Cerca de metade das empresas tem uma política de segurança de código aberto em vigor, o que leva a um melhor desempenho nas medidas de prontidão de segurança, de acordo com a pesquisa de junho . Além disso, os esforços para controlar o risco de código aberto aumentaram 51% nos últimos 12 meses, segundo um estudo de maturidade de segurança divulgado em 21 de setembro.
“Com a atenção dada às cadeias de fornecimento de software, a maioria das organizações corporativas está adotando uma abordagem baseada em risco para a segurança de aplicativos”, disse Jason Schmitt, gerente geral do Synopsys Software Integrity Group, em comunicado anunciando o estudo. “Tal abordagem reconhece que a segurança não se limita à base de código; ela inclui o processo de desenvolvimento de software em que as revisões e testes de segurança ‘mudam para todos os lugares’ para melhorar continuamente os resultados de segurança.”
Desenvolvedores expandem o uso de código aberto
As empresas de software não estão vendo nenhum tipo de diminuição no uso de código aberto, de acordo com outros dados. Em vez disso, as organizações de desenvolvimento estão se concentrando em melhorar a segurança do software de código aberto e usando a segurança como guia principal na seleção de componentes.
No relatório ” 2021 State of the Software Supply Chain” , por exemplo, a Sonatype descobriu que os quatro principais ecossistemas de código aberto – o Maven Central Repository (Java), Node.js (JavaScript), o Python Package Index (Python) e a galeria NuGet (.NET) — abrigava 37 milhões de projetos e componentes de código aberto, um aumento de 20% ano a ano. A demanda por esses componentes também está aumentando: mais de 2,2 trilhões de componentes foram baixados, um aumento anual de 73%.
Um afastamento auto-relatado dos pacotes de código aberto pela comunidade de ciência de dados provavelmente indica uma maior conscientização sobre questões de segurança e menos sobre o abandono de componentes de código aberto em desenvolvimento, diz Tracy Miranda, chefe de código aberto da Chainguard.
Embora as equipes de ciência de dados e as equipes de desenvolvimento possam ter reagido de maneira diferente aos principais problemas de segurança – como o Log4j 2.0 – as empresas têm pouco recurso ao se afastar de um pacote de código aberto do que adotar um pacote diferente cujos mantenedores deram maior ênfase à segurança, ela diz.
“As empresas aproveitam o código aberto como uma forma de aumentar sua velocidade, portanto, se estão reduzindo, para que estão reduzindo? Escrevendo código internamente? Usando versões de terceiros empacotadas?” Miranda diz, acrescentando que, em vez disso, “acho que podemos esperar que as empresas sejam mais criteriosas sobre a qualidade do código aberto que usam, especialmente em relação aos recursos de segurança”.
Os cientistas de dados estão tentando recuperar o atraso
A desconexão entre os dois lados provavelmente se deve aos diferentes públicos nas várias pesquisas. A pesquisa da Anaconda se concentrou em profissionais de ciência de dados, como pode ser visto na escolha de linguagens de programação de seus entrevistados – 58% usavam Python e 42% usavam SQL, enquanto apenas 26% usavam JavaScript.
Uma medida melhor dos sentimentos dos desenvolvedores de software é a ” 2022 Developer Survey ” do StackOverflow , que descobriu que, enquanto 58% das ‘pessoas aprendendo a codificar’ usam Python, apenas 44% dos desenvolvedores profissionais codificam nessa linguagem. Por outro lado, 68% dos desenvolvedores profissionais usam JavaScript, de acordo com a pesquisa do StackOverflow.
Além disso, enquanto os profissionais de ciência de dados trabalham em empresas que predominantemente (87%) permitem software de código aberto, cerca de um quarto (26%) tem supervisão mínima do departamento de TI de suas escolhas de código aberto, afirmou o relatório da Anaconda. Em outros 18% das empresas, o departamento de TI especifica apenas cerca de metade dos componentes de código aberto disponíveis.
Os mantenedores dos projetos mais críticos — dos quais existem centenas, senão milhares — precisam usar dependências seguras, testar seu próprio código e validar a confiabilidade dos colaboradores. Os mantenedores também devem publicar um scorecard de segurança – uma iniciativa criada pelo Google agora gerenciada pela Open Source Security Foundation (OpenSSF) , que dá uma nota de segurança a um projeto com base em quase 20 critérios diferentes.
Embora a conscientização esteja aumentando, não há solução rápida, diz Miranda.
“A realidade é que as opções mais seguras não existiam anteriormente”, diz ela. “Aparar dependências desnecessárias para reduzir a superfície de ataque é sensato, mas é difícil fazer isso quando a árvore de dependências cresce”.
FONTE: DARK READING