Como escolher soluções de código aberto para sua organização

Como avaliar todas as complexidades da integração de aplicativos de código aberto com antecedência e escolher as soluções mais eficientes.

De acordo com o relatório State of Open Source de 2025, 96% das empresas pesquisadas usam aplicativos de código aberto. Sua ampla seleção, opções de personalização e custos de licenciamento zero são altamente atraentes. No entanto, mais da metade das empresas pesquisadas enfrenta desafios significativos com a manutenção contínua de aplicativos de código aberto. Surpreendentes 63% têm dificuldade para manter as soluções atualizadas e aplicar patches. Logo atrás estão os problemas com segurança cibernética, conformidade regulatória e a presença de aplicativos de código aberto em fim de vida útil (EoL), o que significa que eles não são mais compatíveis. Então, como é possível minimizar a probabilidade desses problemas e o que você deve procurar ao selecionar o software de código aberto (OSS) para implementação?

Atualizações e patches

Como a atualização do código aberto (OSS) em tempo hábil é o problema mais comum, examine com muito cuidado os candidatos a OSS e considerando essa perspectiva. É fácil verificar a frequência e o escopo das atualizações, bem como seu conteúdo, diretamente no repositório público do aplicativo. Preste atenção à qualidade da documentação das atualizações; que tipos de problemas elas resolvem; quais novos recursos elas adicionam; com que frequência correções secundárias são lançadas alguns dias ou semanas após uma versão principal; e a rapidez com que as solicitações relacionadas a bugs são atendidas.

Ferramentas padrão como Git Insights, além de serviços complementares como Is it maintained?, Repology e Libraries.io, podem ajudar a responder a essas perguntas. O Libraries.io mostra imediatamente quais dependências desatualizadas estão sendo usadas na versão atual.

Preste atenção especial às atualizações relacionadas à segurança. Elas são lançadas separadamente ou são empacotados com atualizações de funcionalidades? Normalmente, os desenvolvedores escolhem o último caminho. Nesse caso, você precisa entender por quanto tempo as atualizações de segurança podem estar aguardando o lançamento.

Além disso, avalie a complexidade do processo de instalação de atualizações. Suporte e documentação oficiais podem ser um ponto de partida, mas não são suficientes. A análise completa dos comentários da comunidade de usuários provavelmente será mais útil aqui.

Tudo isso ajudará você a entender quanto esforço será necessário para manter o produto. Você precisará alocar recursos internos para suporte. Não basta simplesmente atribuir responsabilidades; horas de trabalho dedicado serão necessárias para essas e outras tarefas relacionadas.

Vulnerabilidades

Para prever com precisão com que frequência você enfrentará problemas de segurança cibernética, é melhor avaliar a cultura de engenharia do produto e a higiene da segurança cibernética desde o início. Embora esse processo possa ser trabalhoso, é possível usar ferramentas automatizadas para executar uma análise inicial de alto nível.

Para produtos e pacotes populares, uma boa abordagem é verificar os resultados da avaliação heurística já existentes de ferramentas como o OpenSSF Scorecard. Essa ferramenta fornece uma variedade de dados de higiene de segurança cibernética, desde o número de vulnerabilidades não corrigidas e a presença de políticas de segurança até o uso de fuzzing e fixação de dependências.

Além disso, examine bancos de dados públicos de vulnerabilidades, como NVD e GitHub advisories, para entender quantas falhas foram descobertas no projeto, sua gravidade e a rapidez com que foram corrigidas. Um número elevado de vulnerabilidades por si só pode indicar a popularidade do projeto em vez de práticas de desenvolvimento ruins. No entanto, os tipos de defeitos e como os desenvolvedores responderam a eles são o que é realmente importante.

Dependências e cadeia de suprimentos

Quase todos os projetos de OSS dependem de componentes de código aberto de terceiros, que geralmente não são documentados. Esses componentes são atualizados de acordo com seus próprios cronogramas e podem conter bugs, vulnerabilidades e até mesmo código malicioso. A questão principal aqui é a rapidez com que as atualizações de componentes com patches chegam ao projeto que você está considerando.

Para avaliar isso, você precisará das ferramentas SBOM (lista de materiais do software) ou SCA (análise de composição do software). As soluções de código aberto disponíveis, como o Dependency-Check da OWASP ou o Syft, podem criar a árvore de dependências de um projeto. Contudo, geralmente estas são desenvolvidas para projetos já em operação, implementados em seus próprios repositórios ou imagens de contêiner. Portanto, uma análise aprofundada da dependência é mais adequada para um produto que já passou na avaliação preliminar e é um forte candidato a integrar sua infraestrutura.

Examine a lista de dependências minuciosamente para determinar se elas são provenientes de repositórios confiáveis e bem verificados, se são populares e se têm assinaturas digitais. Essencialmente, você vai avaliar os riscos de elas estarem comprometidas.

Embora você possa, em tese, verificar vulnerabilidades nas dependências manualmente, se um projeto de código aberto (OSS) já estiver implementado em um ambiente de teste, é muito mais simples usar ferramentas como o Grype.

Um grande desafio oculto é monitorar as atualizações. Em teoria, cada atualização de dependência de um projeto precisa ser verificada de forma recorrente. Na prática, isso só é possível com verificadores automatizados; outras abordagens são simplesmente muito caras.

Se um projeto usa dependências desatualizadas e, em geral, não é ideal do ponto de vista da segurança cibernética, obviamente é melhor procurar uma alternativa. Mas e se a empresa insistir em uma solução específica devido à sua funcionalidade principal? A resposta é a mesma de sempre: conduza uma análise de risco mais profunda, desenvolva controles compensatórios e, o mais importante, aloque recursos significativos para a manutenção contínua. Os recursos internos geralmente são insuficientes, portanto, é aconselhável avaliar as opções de suporte técnico profissional para esse produto específico desde o início.

Conformidade com os requisitos internos e regulamentares

Se as políticas regulatórias aplicáveis à sua empresa envolverem o software escolhido e os dados contidos nele, desenvolva um plano para auditorias de conformidade imediatamente. Aplicativos de código aberto de nível empresarial muito grandes às vezes vêm com documentação de suporte que pode simplificar determinados tipos de auditorias. Caso contrário, você terá que desenvolver tudo sozinho, o que novamente significa alocar tempo e recursos significativos.

Quase todos os softwares em todos os setores exigirão uma auditoria de conformidade de licença. Alguns componentes e aplicativos de código aberto são distribuídos sob licenças restritivas, como AGPL, que limitam como você pode distribuir e usar o software. Graças à análise de SBOM/SCA, você pode inventariar todas as licenças para o software e suas dependências e, em seguida, verificar se seu caso de uso não viola nenhuma delas. Esses processos podem ser amplamente automatizados com ferramentas especializadas, como o OSS Review Toolkit, mas a automação exigirá políticas claras e esforço de sua equipe de desenvolvimento.

Custos de suporte

Depois de analisar todos esses aspectos, você deverá ter uma visão clara que permita comparar diferentes abordagens de suporte ao aplicativo. Para o suporte de uma equipe interna, você precisará alocar horas de especialistas relevantes. Se sua equipe não tiver a experiência necessária, você terá que contratar alguém. Os principais responsáveis pelo suporte e a segurança do OSS também precisarão de tempo e orçamento para o desenvolvimento profissional constante e contínuo.

Se os recursos de sua equipe interna forem insuficientes para o suporte (devido a limitação de pessoal ou experiência), há pelo menos dois tipos de suporte técnico terceirizado profissional: empresas como a Red Hat, que se especializam em operações de aplicativos, e provedores de hospedagem gerenciada para aplicativos específicos (Kube Clusters, MongoDB Atlas e similares).

Além do tempo e da experiência, o custo e a complexidade do suporte técnico também são influenciados pela preparação geral da organização para a ampla adoção do código aberto:

  • Sua equipe de segurança cibernética tem verificadores de vulnerabilidades e ferramentas de gerenciamento de risco bem adaptadas ao código aberto (OSS)?
  • Suas ferramentas de rastreamento e monitoramento de ativos de TI são compatíveis com projetos e componentes de código aberto (OSS)?
  • Para equipes de desenvolvimento internas, a imagem, o repositório e outros processos de verificação da fonte de código estão incluídos em seu pipeline de CI/CD? Soluções de segurança especializadas, como o Kaspersky Hybrid Cloud Security, podem automatizar esse aspecto.
  • Sua empresa desenvolveu uma política que regula o uso de OSS e há um entendimento claro de quem toma decisões e quem é responsável por questões operacionais?

Além disso, é crucial considerar o amplo espectro de riscos do código aberto, incluindo a descontinuação abrupta do projeto, a proliferação de dependências menores e outros riscos à cadeia de suprimentos.

Dicas