Skip to main content

5 riscos potenciais do software de código aberto

Escrito por
blog hero software supply chain security

29 de junho de 2021

0 minutos de leitura

Os argumentos a favor do software de código aberto são convincentes. Tanto que ele já se tornou parte padrão do processo de desenvolvimento de aplicações.

O acesso a bibliotecas, frameworks e processos disponíveis gratuitamente poupa às empresas modernas o tempo e o custo de criar toda uma pilha de aplicações do zero, ajudando a acelerar o desenvolvimento e impulsionar a inovação.

Ao contrário do software proprietário, o código aberto não é ofuscado. Por isso, também é fácil adaptar a base de código às necessidades específicas da sua empresa. Além disso, qualquer pessoa pode encontrar bugs e sugerir correções para problemas no código. Isso faz com que os problemas sejam identificados com mais rapidez e, em alguns casos, torna o software de código aberto mais robusto e seguro do que as alternativas proprietárias.

Riscos do software de código aberto

Ainda assim, há alguns riscos do software de código aberto que devem ser considerados ao escolher projetos para sua pilha.

Por exemplo, algumas implantações podem ser difíceis de configurar e usar por causa da imaturidade do projeto ou da falta de documentação. Também podem surgir problemas de compatibilidade com hardware devido à falta de robustez. Em alguns casos, você talvez precise contratar um provedor de suporte terceirizado e caro para obter assistência técnica.

Neste artigo, analisamos cinco áreas de preocupação que representam os riscos mais significativos do uso de software de código aberto.

  1. Qualidade do software

  2. Sustentabilidade a longo prazo

  3. Licenciamento de software

  4. Violação de direitos autorais

  5. Segurança de software

1. Qualidade do software

Os projetos de código aberto geralmente são iniciativas comunitárias, em que o software é desenvolvido, testado e aprimorado por meio da colaboração. Por isso, costumam ser considerados mais confiáveis do que as alternativas proprietárias.

No entanto, nada é garantido — especialmente quando os projetos são mantidos por apenas algumas pessoas.

Além disso, os colaboradores têm diferentes níveis de conhecimento, habilidades e experiência. Alguns não conseguem dedicar tanto tempo quanto outros. Assim, como acontece em qualquer projeto com recursos insuficientes, a qualidade acaba sendo prejudicada.

Uma forma de avaliar um projeto de código aberto é analisar métricas como manutenção e segurança. Avaliar esses parâmetros e comparar projetos semelhantes ajuda você a tomar decisões mais bem embasadas. Com o Snyk Open Source Advisor, é fácil encontrar e avaliar o melhor pacote de código aberto para seu projeto. A ferramenta abrange mais de 1 milhão de pacotes de código aberto.

Visão geral do Snyk Advisor para o pacote npm React v17.0.2, mostrando uma pontuação de saúde de 95/100, status de segurança, downloads e gráficos de manutenção.
Visão geral da integridade do pacote open source React no Snyk Advisor

E, ao contrário dos softwares comerciais, que geralmente contam com algum tipo de garantia, poucas licenças de código aberto oferecem essa proteção caso o software não funcione como esperado.

2. Sustentabilidade a longo prazo

Muitos tipos de software de código aberto são desenvolvidos por um pequeno grupo de colaboradores. Como voluntários, eles frequentemente se veem pressionados a manter seus projetos enquanto trabalham em tempo integral.

Isso pode levar ao esgotamento na comunidade de código aberto, quando um projeto fica estagnado porque os colaboradores não conseguem manter o compromisso — até acabar sendo descontinuado.

Se você depender de componentes de código aberto que não são mais mantidos, poderá ter de corrigir vulnerabilidades e outros defeitos no código. Por isso, acompanhe a frequência com que os projetos recebem atualizações.

3. Licenciamento de software

Embora a maioria dos softwares de código aberto seja gratuita, praticamente todos têm algum tipo de licença.

Atualmente, há mais de 100 licenças de código aberto aprovadas pela OSI. Por isso, uma pilha de aplicações ou um ambiente de desenvolvimento complexo pode estar sujeito a uma variedade confusa de contratos de licença de código aberto — alguns deles bastante complexos e detalhados.

Infográfico que compara cinco tipos de licença de software — de domínio público a proprietária — em uma escala de restrições crescentes.
Os 5 tipos de licença de software

As licenças de código aberto geralmente se enquadram em duas grandes categorias: licenças permissivas e licenças copyleft.

  • Licenças permissivas, como a licença MIT, geralmente permitem que você use o código como quiser. Além disso, você pode incorporar o código em suas próprias aplicações proprietárias e distribuir o software derivado, desde que reconheça o criador original.

  • Licenças copyleft, como a GNU General Public License e a Server Side Public License (SSPL), também permitem que você modifique o código à vontade. No entanto, se quiser reutilizá-lo e distribuí-lo, você deverá disponibilizar gratuitamente o novo código-fonte. Isso pode ser especialmente problemático se você quiser integrar componentes licenciados sob copyleft ao seu software proprietário, pois talvez precise abrir seu próprio código para cumprir a licença de software.

Uma forma de evitar problemas com licenças é criar uma lista de componentes de código aberto aprovados e manter um inventário dos softwares de código aberto usados nos seus sistemas. As políticas de código aberto são outra forma de garantir o cumprimento das licenças.

Ao mesmo tempo, antes de decidir quais componentes de código aberto usar, considere questões técnicas, como a interação entre diferentes aplicações e serviços. Lembre-se também de que, mesmo que suas aplicações sejam para uso interno, você pode decidir lançá-las no futuro.

Atenção:

Uma grande parte dos softwares disponibilizados gratuitamente em plataformas de desenvolvimento, como o GitHub, não tem nenhuma licença.

No entanto, em muitos países, o código de aplicações recebe automaticamente proteção exclusiva de direitos autorais. Portanto, o fato de estar disponível publicamente não significa que você tenha o direito de usá-lo. Em outras palavras, evite usar esse tipo de software sem permissão.

4. Violação de direitos autorais

Muitos desenvolvedores de código aberto são entusiastas. Com frequência, trabalham por conta própria e talvez não compreendam — ou respeitem — o conceito de propriedade intelectual protegida.

Isso cria o risco de violação de direitos autorais, pois um programador inexperiente ou negligente pode acabar incluindo código proprietário (ou copyleft) em um projeto. Por isso, as licenças de código aberto não assumem responsabilidade por violações de direitos autorais ou de outros direitos de propriedade intelectual.

Portanto, faça uma análise cuidadosa antes de adotar qualquer software de código aberto, para ajudar a evitar possíveis ações judiciais e pedidos de indenização.

5. Segurança de software

Por sua natureza colaborativa e transparente, o código aberto geralmente tem uma reputação melhor em relação à segurança de software do que o software proprietário.

Quando uma falha de segurança surge em uma aplicação comercial, você precisa esperar o fornecedor agir. Já no software de código aberto, muitas vezes alguém está disponível para corrigi-la imediatamente.

No entanto, nem sempre é assim — principalmente em projetos de menor porte.

Além disso, quase metade de todos os projetos de código aberto ainda não conta com procedimentos de auditoria de segurança.

Por isso, não confie simplesmente na ideia de que todas as pessoas da comunidade de código aberto estão sempre revisando seus projetos em busca de problemas de segurança do código aberto.

Além disso, acompanhar as atualizações de software mais recentes, os patches e as vulnerabilidades ainda não resolvidas é um grande desafio.

Por exemplo, você pode assinar os feeds de vários bancos de dados de vulnerabilidades conhecidas, incluindo o banco de dados de vulnerabilidades da Snyk. Mas nem mesmo os serviços maiores e mais completos, como o National Vulnerability Database (NVD), listam todos os problemas reportados.

Você também deve saber que esses serviços costumam adiar as atualizações por várias semanas para dar aos desenvolvedores de código aberto tempo para discutir, corrigir e testar a vulnerabilidade antes de torná-la pública.

Embora essa abordagem faça sentido, ela dá mais tempo para que qualquer invasor com informações privilegiadas planeje e lance um ataque. E, mesmo quando os usuários são notificados sobre uma vulnerabilidade, alguns demoram demais para aplicar o patch — ou, pior ainda, podem nem saber que usam o componente afetado.

State of Open Source Security 2022

A look at software supply chain complexity and risk in collaboration with the Linux Foundation.

Esteja sempre um passo à frente

Apesar dos benefícios amplamente reconhecidos do software de código aberto, você ainda precisa pesquisar para garantir que escolheu a solução certa para sua organização.

Mas você também precisa adotar ferramentas que ajudem a gerenciar suas implantações. Elas devem oferecer visibilidade clara do seu inventário de código aberto. Assim, você pode acompanhar todos os frameworks e bibliotecas usados nas suas aplicações e cumprir os requisitos das licenças de código aberto.

Procure também soluções que ajudem você a acompanhar a segurança de aplicações, detectando vulnerabilidades de código aberto com antecedência, antes que os invasores tenham a chance de explorá-las.

Gerenciar cuidadosamente o uso de código aberto, com atenção especial aos possíveis riscos de segurança e jurídicos, ajuda você a aproveitar todas as vantagens desse modelo com o mínimo de risco de enfrentar problemas caros no futuro.

No entanto, sem o apoio de ferramentas de segurança automatizada e governança, você terá muito trabalho manual para acompanhar a conformidade das licenças e as vulnerabilidades dos pacotes mais recentes.

Comece a resolver desafios de capture the flag

Aprenda a resolver desafios de capture the flag assistindo sob demanda ao nosso workshop virtual introdutório.