{"id":23944,"date":"2025-07-03T12:57:17","date_gmt":"2025-07-03T15:57:17","guid":{"rendered":"https:\/\/www.kaspersky.com.br\/blog\/?p=23944"},"modified":"2025-07-03T12:57:17","modified_gmt":"2025-07-03T15:57:17","slug":"can-you-support-open-source-preliminary-assessment","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.br\/blog\/can-you-support-open-source-preliminary-assessment\/23944\/","title":{"rendered":"Como escolher solu\u00e7\u00f5es de c\u00f3digo aberto para sua organiza\u00e7\u00e3o"},"content":{"rendered":"

De acordo com o relat\u00f3rio State of Open Source de 2025<\/a>, 96% das empresas pesquisadas usam aplicativos de c\u00f3digo aberto. Sua ampla sele\u00e7\u00e3o, op\u00e7\u00f5es de personaliza\u00e7\u00e3o e custos de licenciamento zero s\u00e3o altamente atraentes. No entanto, mais da metade das empresas pesquisadas enfrenta desafios significativos com a manuten\u00e7\u00e3o cont\u00ednua de aplicativos de c\u00f3digo aberto. Surpreendentes 63% t\u00eam dificuldade para manter as solu\u00e7\u00f5es atualizadas e aplicar patches. Logo atr\u00e1s est\u00e3o os problemas com seguran\u00e7a cibern\u00e9tica, conformidade regulat\u00f3ria e a presen\u00e7a de aplicativos de c\u00f3digo aberto em fim de vida \u00fatil (EoL), o que significa que eles n\u00e3o s\u00e3o mais compat\u00edveis. Ent\u00e3o, como \u00e9 poss\u00edvel minimizar a probabilidade desses problemas e o que voc\u00ea deve procurar ao selecionar o software de c\u00f3digo aberto (OSS) para implementa\u00e7\u00e3o?<\/p>\n

Atualiza\u00e7\u00f5es e patches<\/h2>\n

Como a atualiza\u00e7\u00e3o do c\u00f3digo aberto (OSS) em tempo h\u00e1bil \u00e9 o problema mais comum, examine com muito cuidado os candidatos a OSS e considerando essa perspectiva. \u00c9 f\u00e1cil verificar a frequ\u00eancia e o escopo das atualiza\u00e7\u00f5es, bem como seu conte\u00fado, diretamente no reposit\u00f3rio p\u00fablico do aplicativo. Preste aten\u00e7\u00e3o \u00e0 qualidade da documenta\u00e7\u00e3o das atualiza\u00e7\u00f5es; que tipos de problemas elas resolvem; quais novos recursos elas adicionam; com que frequ\u00eancia corre\u00e7\u00f5es secund\u00e1rias s\u00e3o lan\u00e7adas alguns dias ou semanas ap\u00f3s uma vers\u00e3o principal; e a rapidez com que as solicita\u00e7\u00f5es relacionadas a bugs s\u00e3o atendidas.<\/p>\n

Ferramentas padr\u00e3o como Git Insights<\/a>, al\u00e9m de servi\u00e7os complementares como Is it maintained?<\/a>, Repology<\/a> e Libraries.io<\/a>, podem ajudar a responder a essas perguntas. O Libraries.io mostra imediatamente quais depend\u00eancias desatualizadas est\u00e3o sendo usadas na vers\u00e3o atual.<\/p>\n

Preste aten\u00e7\u00e3o especial \u00e0s atualiza\u00e7\u00f5es relacionadas \u00e0 seguran\u00e7a. Elas s\u00e3o lan\u00e7adas separadamente ou s\u00e3o empacotados com atualiza\u00e7\u00f5es de funcionalidades? Normalmente, os desenvolvedores escolhem o \u00faltimo caminho. Nesse caso, voc\u00ea precisa entender por quanto tempo as atualiza\u00e7\u00f5es de seguran\u00e7a podem estar aguardando o lan\u00e7amento.<\/p>\n

Al\u00e9m disso, avalie a complexidade do processo de instala\u00e7\u00e3o de atualiza\u00e7\u00f5es. Suporte e documenta\u00e7\u00e3o oficiais podem ser um ponto de partida, mas n\u00e3o s\u00e3o suficientes. A an\u00e1lise completa dos coment\u00e1rios da comunidade de usu\u00e1rios provavelmente ser\u00e1 mais \u00fatil aqui.<\/p>\n

Tudo isso ajudar\u00e1 voc\u00ea a entender quanto esfor\u00e7o ser\u00e1 necess\u00e1rio para manter o produto. Voc\u00ea precisar\u00e1 alocar recursos internos para suporte. N\u00e3o basta simplesmente atribuir responsabilidades; horas de trabalho dedicado ser\u00e3o necess\u00e1rias para essas e outras tarefas relacionadas.<\/p>\n

Vulnerabilidades<\/h2>\n

Para prever com precis\u00e3o com que frequ\u00eancia voc\u00ea enfrentar\u00e1 problemas de seguran\u00e7a cibern\u00e9tica, \u00e9 melhor avaliar a cultura de engenharia do produto e a higiene da seguran\u00e7a cibern\u00e9tica desde o in\u00edcio. Embora esse processo possa ser trabalhoso, \u00e9 poss\u00edvel usar ferramentas automatizadas para executar uma an\u00e1lise inicial de alto n\u00edvel.<\/p>\n

Para produtos e pacotes populares, uma boa abordagem \u00e9 verificar os resultados da avalia\u00e7\u00e3o heur\u00edstica j\u00e1 existentes de ferramentas como o OpenSSF Scorecard<\/a>. Essa ferramenta fornece uma variedade de dados de higiene de seguran\u00e7a cibern\u00e9tica, desde o n\u00famero de vulnerabilidades n\u00e3o corrigidas e a presen\u00e7a de pol\u00edticas de seguran\u00e7a at\u00e9 o uso de fuzzing e fixa\u00e7\u00e3o de depend\u00eancias.<\/p>\n

Al\u00e9m disso, examine bancos de dados p\u00fablicos de vulnerabilidades, como NVD<\/a> e GitHub advisories<\/a>, para entender quantas falhas foram descobertas no projeto, sua gravidade e a rapidez com que foram corrigidas. Um n\u00famero elevado de vulnerabilidades por si s\u00f3 pode indicar a popularidade do projeto em vez de pr\u00e1ticas de desenvolvimento ruins. No entanto, os tipos de defeitos e como os desenvolvedores responderam a eles s\u00e3o o que \u00e9 realmente importante.<\/p>\n

Depend\u00eancias e cadeia de suprimentos<\/h2>\n

Quase todos os projetos de OSS dependem de componentes de c\u00f3digo aberto de terceiros, que geralmente n\u00e3o s\u00e3o documentados. Esses componentes s\u00e3o atualizados de acordo com seus pr\u00f3prios cronogramas e podem conter bugs, vulnerabilidades e at\u00e9 mesmo c\u00f3digo malicioso. A quest\u00e3o principal aqui \u00e9 a rapidez com que as atualiza\u00e7\u00f5es de componentes com patches chegam ao projeto que voc\u00ea est\u00e1 considerando.<\/p>\n

Para avaliar isso, voc\u00ea precisar\u00e1 das ferramentas SBOM (lista de materiais do software) ou SCA (an\u00e1lise de composi\u00e7\u00e3o do software). As solu\u00e7\u00f5es de c\u00f3digo aberto dispon\u00edveis, como o Dependency-Check<\/a> da OWASP ou o Syft<\/a>, podem criar a \u00e1rvore de depend\u00eancias de um projeto. Contudo, geralmente estas s\u00e3o desenvolvidas para projetos j\u00e1 em opera\u00e7\u00e3o, implementados em seus pr\u00f3prios reposit\u00f3rios ou imagens de cont\u00eainer. Portanto, uma an\u00e1lise aprofundada da depend\u00eancia \u00e9 mais adequada para um produto que j\u00e1 passou na avalia\u00e7\u00e3o preliminar e \u00e9 um forte candidato a integrar sua infraestrutura.<\/p>\n

Examine a lista de depend\u00eancias minuciosamente para determinar se elas s\u00e3o provenientes de reposit\u00f3rios confi\u00e1veis e bem verificados, se s\u00e3o populares e se t\u00eam assinaturas digitais. Essencialmente, voc\u00ea vai avaliar os riscos de elas estarem comprometidas.<\/p>\n

Embora voc\u00ea possa, em tese, verificar vulnerabilidades nas depend\u00eancias manualmente, se um projeto de c\u00f3digo aberto (OSS) j\u00e1 estiver implementado em um ambiente de teste, \u00e9 muito mais simples usar ferramentas como o Grype<\/a>.<\/p>\n

Um grande desafio oculto \u00e9 monitorar as atualiza\u00e7\u00f5es. Em teoria, cada atualiza\u00e7\u00e3o de depend\u00eancia de um projeto precisa ser verificada de forma recorrente. Na pr\u00e1tica, isso s\u00f3 \u00e9 poss\u00edvel com verificadores automatizados; outras abordagens s\u00e3o simplesmente muito caras.<\/p>\n

Se um projeto usa depend\u00eancias desatualizadas e, em geral, n\u00e3o \u00e9 ideal do ponto de vista da seguran\u00e7a cibern\u00e9tica, obviamente \u00e9 melhor procurar uma alternativa. Mas e se a empresa insistir em uma solu\u00e7\u00e3o espec\u00edfica devido \u00e0 sua funcionalidade principal? A resposta \u00e9 a mesma de sempre: conduza uma an\u00e1lise de risco mais profunda, desenvolva controles compensat\u00f3rios e, o mais importante, aloque recursos significativos para a manuten\u00e7\u00e3o cont\u00ednua. Os recursos internos geralmente s\u00e3o insuficientes, portanto, \u00e9 aconselh\u00e1vel avaliar as op\u00e7\u00f5es de suporte t\u00e9cnico profissional para esse produto espec\u00edfico desde o in\u00edcio.<\/p>\n

Conformidade com os requisitos internos e regulamentares<\/h2>\n

Se as pol\u00edticas regulat\u00f3rias aplic\u00e1veis \u00e0 sua empresa envolverem o software escolhido e os dados contidos nele, desenvolva um plano para auditorias de conformidade imediatamente. Aplicativos de c\u00f3digo aberto de n\u00edvel empresarial muito grandes \u00e0s vezes v\u00eam com documenta\u00e7\u00e3o de suporte que pode simplificar determinados tipos de auditorias. Caso contr\u00e1rio, voc\u00ea ter\u00e1 que desenvolver tudo sozinho, o que novamente significa alocar tempo e recursos significativos.<\/p>\n

Quase todos os softwares em todos os setores exigir\u00e3o uma auditoria de conformidade de licen\u00e7a. Alguns componentes e aplicativos de c\u00f3digo aberto s\u00e3o distribu\u00eddos sob licen\u00e7as restritivas, como AGPL<\/a>, que limitam como voc\u00ea pode distribuir e usar o software. Gra\u00e7as \u00e0 an\u00e1lise de SBOM\/SCA, voc\u00ea pode inventariar todas as licen\u00e7as para o software e suas depend\u00eancias e, em seguida, verificar se seu caso de uso n\u00e3o viola nenhuma delas. Esses processos podem ser amplamente automatizados com ferramentas especializadas, como o OSS Review Toolkit<\/a>, mas a automa\u00e7\u00e3o exigir\u00e1 pol\u00edticas claras e esfor\u00e7o de sua equipe de desenvolvimento.<\/p>\n

Custos de suporte<\/h2>\n

Depois de analisar todos esses aspectos, voc\u00ea dever\u00e1 ter uma vis\u00e3o clara que permita comparar diferentes abordagens de suporte ao aplicativo. Para o suporte de uma equipe interna, voc\u00ea precisar\u00e1 alocar horas de especialistas relevantes. Se sua equipe n\u00e3o tiver a experi\u00eancia necess\u00e1ria, voc\u00ea ter\u00e1 que contratar algu\u00e9m. Os principais respons\u00e1veis pelo suporte e a seguran\u00e7a do OSS tamb\u00e9m precisar\u00e3o de tempo e or\u00e7amento para o desenvolvimento profissional constante e cont\u00ednuo.<\/p>\n

Se os recursos de sua equipe interna forem insuficientes para o suporte (devido a limita\u00e7\u00e3o de pessoal ou experi\u00eancia), h\u00e1 pelo menos dois tipos de suporte t\u00e9cnico terceirizado profissional: empresas como a Red Hat, que se especializam em opera\u00e7\u00f5es de aplicativos, e provedores de hospedagem gerenciada para aplicativos espec\u00edficos (Kube Clusters, MongoDB Atlas e similares).<\/p>\n

Al\u00e9m do tempo e da experi\u00eancia, o custo e a complexidade do suporte t\u00e9cnico tamb\u00e9m s\u00e3o influenciados pela prepara\u00e7\u00e3o geral da organiza\u00e7\u00e3o para a ampla ado\u00e7\u00e3o do c\u00f3digo aberto:<\/p>\n