Recentemente, a publicação de um novo relatório da empresa de segurança para desenvolvedores Snyk e da Linux Foundation, sobre sua pesquisa conjunta sobre o estado da segurança do software de código aberto.
Em sua postagem detalham que os resultados não são animadores para as empresas, tão há uma grande variedade de riscos de segurança significativos resultante do uso generalizado de software de código aberto no desenvolvimento de aplicativos modernos, bem como quantas organizações estão atualmente despreparadas para gerenciar esses riscos de forma eficaz.
Especificamente, o relatório encontrou:
Mais de quatro em cada dez (41%) organizações não confiam muito na segurança de seu software de código aberto;
O projeto médio de desenvolvimento de aplicativos tem 49 vulnerabilidades e 80 dependências diretas (código-fonte aberto chamado por um projeto); Y,
O tempo necessário para corrigir vulnerabilidades em projetos de código aberto tem aumentado constantemente, mais que dobrando de 49 dias em 2018 para 110 dias em 2021.
É mencionado que geralmente um projeto desenvolvimento de aplicações tem uma média de 49 vulnerabilidades e 80 dependências diretas. Além disso, o tempo necessário para corrigir vulnerabilidades em projetos de código aberto aumentou constantemente, mais que dobrando de 49 dias em 2018 para 110 dias em 2021.
» Os desenvolvedores de software de hoje têm suas próprias cadeias de suprimentos: em vez de montar peças de carros, eles montam código juntando componentes de código aberto existentes com seu código exclusivo. Se isso levar ao aumento da produtividade e inovação”, explica Matt Jarvis, Diretor de Relações com Desenvolvedores da Snyk. Juntamente com a Linux Foundation, planejamos desenvolver essas descobertas para educar e equipar ainda mais os desenvolvedores em todo o mundo, permitindo que eles continuem construindo rapidamente, mantendo-se seguros."
Entre outros resultados, apenas 49% das organizações têm uma política de segurança para o desenvolvimento ou uso de software livre (e esse número é de apenas 27% para médias e grandes empresas). Enquanto 30% das organizações sem uma política de segurança de software livre reconhecem abertamente que ninguém em sua equipe lida diretamente com segurança de software livre.
A complexidade da cadeia de suprimentos também é um problema, com mais de um quarto dos entrevistados indicando que estão preocupados com o impacto na segurança de suas dependências diretas. Apenas 18% dizem estar confiantes nos controles que realizam.
Até aqui, É importante destacar duas situações, a primeira deles é no momento em que os desenvolvedores adicionam um componente código aberto em seus aplicativos, você é imediatamente tornar-se dependente desse componente e correm risco se esse componente contiver vulnerabilidades.
A outra e que tem se visto com frequência nos últimos anos é que esse risco também é agravado pelas dependências indiretas ou transitivas, que são as dependências das "outras dependências", aqui muitos desenvolvedores nem sabem dessas dependências, o que torna ainda mais mais difícil de rastrear e proteger.
Com isso, podemos entender um pouco que o relatório mostra o quão real é esse risco, com dezenas de vulnerabilidades descobertas em muitas dependências diretas em cada aplicação avaliada. Dito isso, até certo ponto, os entrevistados estão cientes das complexidades de segurança criadas pelo código aberto na cadeia de suprimentos de software atual:
Mais de um quarto dos entrevistados disseram estar preocupados com o impacto de segurança de suas dependências diretas; apenas 18% dos entrevistados disseram confiar nos controles que possuem para suas dependências transitivas; e Quarenta por cento de todas as vulnerabilidades foram encontradas em dependências transitivas.
Também é importante mencionar que se essas empresas ou desenvolvedores não estiverem "seguros" com o software que utilizam, muitos de nós pensarão no mais lógico, para que "paguem" ou "apoiem o desenvolvimento, seja alocando recursos ou desenvolvedores", mas aqui nesse ponto é que entra um dos grandes debates do software open source, onde se open source deve ser “pago”.
Como tal, existem muitos exemplos de software de código aberto que lida com duas versões, que são pagas e gratuitas, e até mesmo pagas, mas o código-fonte está disponível.
Por outro lado, também houve movimentos de desenvolvedores e grandes empresas, em que decidem mudar o modelo de distribuição ou passar para um modelo de pagamento, por exemplo QT.
Sim mas, para quem se interessar em saber mais sobre isso sobre a nota, você pode consultar os detalhes em o seguinte link.