7 riscos apresentados pelo software de código aberto e como se defender

O que é software de código aberto?

Muitas empresas e produtos, 90% segundo algumas estimativas, usam pelo menos um componente de código aberto - mesmo que não estejam cientes disso. O software de código aberto é um software cujo código está disponível para inspeção pública, modificação e aprimoramento. Normalmente, esse software é criado por meio da colaboração da comunidade e é mantido e atualizado de forma voluntária.

O software de código aberto pode ser usado de acordo com uma variedade de licenças, dependendo do que os criadores implementaram. O sistema operacional Linux, o Apache Web Server, o WordPress e o Mozilla Firefox são apenas alguns dos softwares disponíveis mais comumente usados.

Riscos do uso de software de código aberto

Devido à sua construção comunitária e distribuição amplamente não regulamentada, uma variedade de riscos - incluindo alguns riscos de segurança cibernética - vem com o uso de software de código aberto.

1. As vulnerabilidades são de conhecimento público

As vulnerabilidades em softwares de código aberto são tornadas públicas pelos próprios colaboradores, bem como por organizações como o Open Web Application Security Project (OWASP) e o National Vulnerability Database (NVD).

Se você faz parte da comunidade de um projeto específico, geralmente recebe um aviso prévio antes que ele se torne público para grupos como OWASP e NVD, mas o mesmo acontece com qualquer outra pessoa que faça parte da comunidade. Isso significa que, se você for negligente na manutenção das versões mais recentes ou na atualização de componentes, estará se expondo a riscos, pois as vulnerabilidades são frequentemente identificadas e exploradas por criminosos cibernéticos.

2. Falta de segurança

O software de código aberto não vem com reivindicações ou obrigações legais de segurança e pode faltar suporte da comunidade que informe como implementá-lo com segurança. Os desenvolvedores responsáveis pela criação do software geralmente não são especialistas em segurança e podem não entender como implementar as melhores práticas.

Embora recursos como a lista OWASP Top 10 de vulnerabilidades estejam disponíveis publicamente e sejam direcionados a comunidades de código aberto, eles nem sempre fornecem instruções sobre como implementar recursos de segurança para se proteger contra essas falhas.

Muitas vezes, o software de código aberto inclui ou exige o uso de bibliotecas de terceiros, extraídas dos gerenciadores de pacotes sem inspeção. A natureza de caixa-preta dessas bibliotecas torna mais difícil e demorada a identificação e a correção de quaisquer vulnerabilidades que elas possam injetar.

3. Questões de Propriedade Intelectual

Existem mais de 200 tipos de licenças que podem ser aplicadas a softwares de código aberto, incluindo Apache, GPL e MIT. Muitas dessas licenças são incompatíveis entre si, o que significa que certos componentes não podem ser usados ​​em conjunto, já que é preciso cumprir todos os termos ao usar software de código aberto. Quanto mais componentes você usa, mais difícil se torna rastrear e comparar todas as estipulações das licenças.

Algumas licenças incluem cláusulas de "copyleft" que exigem que você libere qualquer software criado com os componentes cobertos como código aberto, em sua totalidade. Isso torna impossível o uso em software proprietário e menos atraente para uso em fins comerciais.

4. Falta de garantia

O software de código aberto não vem com nenhuma garantia quanto à sua segurança, suporte ou conteúdo. Embora muitos projetos sejam suportados, eles são feitos por voluntários e o desenvolvimento deles pode ser interrompido sem aviso prévio.

Os membros da comunidade normalmente avaliam o software quanto a problemas de segurança e fornecem suporte por meio de fóruns abertos, mas não são obrigados a fazer isso nem são responsáveis por orientações incorretas.

Como o software de código aberto é criado por comunidades de colaboradores, às vezes anônimos, é difícil verificar se o código que está sendo contribuído é original e não foi retirado de uma fonte de terceiros com direitos de propriedade intelectual estabelecidos. O que isso significa na prática é que se você usar um software de código aberto que contenha código com direitos violados, você pode ser responsabilizado pela violação.

5. Supervisão de integrações relaxada

As equipes geralmente têm processos de revisão insuficientes ou inexistentes quando se trata de quais componentes de código aberto estão sendo usados. Várias versões do mesmo componente podem ser usadas por equipes diferentes ou os desenvolvedores podem não estar cientes de funcionalidades ou licenças conflitantes.

Esses problemas podem ocorrer devido à falta de conhecimento do software ou da funcionalidade de segurança, falta de comunicação entre as equipes ou membros da equipe, ou protocolos de rastreamento e documentação insuficientes ou ausentes.

Ao contrário do software proprietário de terceiros, que possui controles integrados para evitar o uso de versões múltiplas ou incompatíveis, os componentes de código aberto normalmente dependem do usuário para verificar o uso adequado.

6. Insuficiências operacionais

O uso de componentes de código aberto pode criar muito trabalho adicional para equipes que já estão com o tempo apertado e, muitas vezes, não fica claro quem é responsável por esse trabalho. É preciso manter o controle de quais componentes são usados, qual é a versão deles, onde são usados e como eles podem interagir com outros componentes em uso.

Além disso, é necessário comparar o licenciamento e monitorar as atualizações e os patches à medida que são disponibilizados, incluindo os impactos que podem ter sobre a funcionalidade. Se os componentes usados contiverem funcionalidades desnecessárias, eles podem aumentar a complexidade de seu sistema sem nenhum benefício.

7. Práticas ruins do desenvolvedor

Os desenvolvedores podem aumentar inadvertidamente os riscos se copiarem e colarem trechos de código de softwares de código aberto em vez de integrarem componentes completos. Isso impossibilita o rastreamento desse código do ponto de vista de licenciamento ou segurança.

Ao colaborar com outros membros da equipe, os desenvolvedores podem transferir componentes por e-mail em vez de usar um gerenciador de repositório binário ou um local de rede compartilhado. Esse método pode deixar o código vulnerável à manipulação durante a transferência, permitindo a inserção de falhas de segurança ou funcionalidades maliciosas.

Como proteger a si mesmo e a sua organização

Use ferramentas adequadas

A implementação de equipes DevSec pode ajudar a integrar a segurança mais cedo no ciclo de vida de desenvolvimento de software (SDLC) e a integrar software de código aberto de forma segura desde o início. Os membros da equipe de segurança podem avaliar com mais facilidade os componentes que os desenvolvedores desejam usar e fornecer orientações sobre como mitigar riscos ou desenvolver correções.

As ferramentas de automação podem fornecer um enorme valor para o rastreamento de componentes de código aberto e seu status, bem como para a avaliação de componentes. O código-fonte aberto pode ser verificado antes e durante o uso por meio de ferramentas de Teste de Segurança de Aplicação Dinâmica (DAST) ou Teste de Segurança de Aplicação Estática (SAST).

Criar políticas abrangentes

As políticas devem exigir a consideração do histórico de um componente de código aberto, como a densidade de problemas conhecidos, a frequência de lançamento de versões e a latência entre a identificação do problema e o patch. É importante saber quão robusta é a comunidade envolvida em um projeto e antecipar que tipo de suporte ela pode ou não fornecer.

As políticas precisam ditar quais fontes e tipos de licença são aceitáveis para uso e devem ajudar os desenvolvedores a decidir se devem usar componentes individuais ou uma base de código inteira.

Conclusão

Muitas empresas se beneficiam do uso de software de código aberto e não há razão para que você não se beneficie também. No entanto, conhecer os riscos apresentados pelo software de código aberto - durante o processo de desenvolvimento - o ajudará a evitar as armadilhas associadas ao compartilhamento de código de fonte coletiva. Ao levar em conta os riscos descritos neste blog e implementar estratégias de proteção, além de outras necessárias para proteger seus sistemas, você pode ajudar a garantir o uso seguro do software de código aberto.