{"id":24913,"date":"2026-04-17T09:00:06","date_gmt":"2026-04-17T12:00:06","guid":{"rendered":"https:\/\/www.kaspersky.com.br\/blog\/?p=24913"},"modified":"2026-04-16T10:01:23","modified_gmt":"2026-04-16T13:01:23","slug":"managing-open-source-vulnerabilities","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.br\/blog\/managing-open-source-vulnerabilities\/24913\/","title":{"rendered":"Arquitetura de gerenciamento de vulnerabilidades de c\u00f3digo aberto"},"content":{"rendered":"<p>Como j\u00e1 comentamos <a href=\"https:\/\/www.kaspersky.com.br\/blog\/open-source-vulnerabilities-in-ai-era\/24906\/\" target=\"_blank\" rel=\"noopener\">em uma postagem anterior<\/a>, o desenvolvimento de produtos de software modernos \u00e9 praticamente imposs\u00edvel sem o uso de componentes de c\u00f3digo aberto. Mas, nos \u00faltimos anos, os riscos associados a isso tornaram-se cada vez mais diversos, complexos e numerosos. Devemos considerar que, primeiro, as vulnerabilidades afetam a infraestrutura e o c\u00f3digo de uma empresa mais rapidamente do que s\u00e3o corrigidas; segundo, os dados s\u00e3o incompletos e pouco confi\u00e1veis; e, terceiro, malware pode estar escondido em componentes populares. Portanto, n\u00e3o basta simplesmente verificar os n\u00fameros de vers\u00e3o e solicitar que a equipe de TI corrija os problemas. O gerenciamento de vulnerabilidades deve ser expandido para abranger pol\u00edticas de download de software, prote\u00e7\u00f5es para assistentes de IA e todo o pipeline de cria\u00e7\u00e3o de software.<\/p>\n<h1>Um conjunto confi\u00e1vel de componentes de c\u00f3digo aberto<\/h1>\n<p>A principal caracter\u00edstica de uma solu\u00e7\u00e3o \u00e9 impedir o uso de c\u00f3digo vulner\u00e1vel e malicioso. As seguintes medidas devem ser implementadas:<\/p>\n<ul>\n<li>Ter um reposit\u00f3rio interno de artefatos. A fonte \u00fanica de componentes para desenvolvimento interno precisa ser um reposit\u00f3rio unificado no qual os componentes s\u00e3o admitidos somente ap\u00f3s uma s\u00e9rie de verifica\u00e7\u00f5es.<\/li>\n<li>Fazer uma triagem rigorosa dos componentes. Isso inclui verifica\u00e7\u00f5es de vers\u00f5es conhecidas do componente, vers\u00f5es vulner\u00e1veis e maliciosas conhecidas, data de publica\u00e7\u00e3o, hist\u00f3rico de atividades e reputa\u00e7\u00e3o do pacote e de seus autores. \u00c9 obrigat\u00f3rio verificar todo o conte\u00fado do pacote, incluindo instru\u00e7\u00f5es de compila\u00e7\u00e3o, casos de teste e outros dados auxiliares. Para filtrar o registro durante a ingest\u00e3o, use verificadores de c\u00f3digo aberto especializados ou uma <a href=\"https:\/\/www.kaspersky.com.br\/enterprise-security\/cloud-workload-security?icid=br_kdailyplacehold_acq_ona_smm__onl_b2b_kdaily_wpplaceholder_sm-team_______b50faf3ca5366575\" target=\"_blank\" rel=\"noopener\">solu\u00e7\u00e3o de seguran\u00e7a abrangente de carga de trabalho na nuvem<\/a>.<\/li>\n<li>Fixar vers\u00f5es de depend\u00eancias. Os processos de compila\u00e7\u00e3o, as ferramentas de IA e os desenvolvedores n\u00e3o devem usar modelos (como \u201co mais recente\u201d) ao especificar vers\u00f5es. As compila\u00e7\u00f5es do projeto precisam ser baseadas em vers\u00f5es verificadas. Ao mesmo tempo, as depend\u00eancias com vers\u00f5es fixas devem ser atualizadas com frequ\u00eancia para as vers\u00f5es verificadas mais recentes que mant\u00eam a compatibilidade e n\u00e3o cont\u00eam vulnerabilidades conhecidas. Isso reduz significativamente o risco de <a href=\"https:\/\/www.kaspersky.com\/blog\/npm-packages-trojanized\/54280\/\" target=\"_blank\" rel=\"noopener nofollow\">ataques \u00e0 cadeia de suprimentos por meio do comprometimento de um pacote conhecido<\/a>.<\/li>\n<\/ul>\n<h1>Aperfei\u00e7oamento dos dados de vulnerabilidades<\/h1>\n<p>Para identificar vulnerabilidades com mais efic\u00e1cia e <a href=\"https:\/\/www.kaspersky.com.br\/blog\/cvss-rbvm-vulnerability-management\/24033\/\" target=\"_blank\" rel=\"noopener\">prioriz\u00e1-las<\/a> de forma adequada, uma organiza\u00e7\u00e3o precisa estabelecer v\u00e1rios processos de TI e seguran\u00e7a:<\/p>\n<ul>\n<li>Enriquecimento de dados de vulnerabilidade. Dependendo das necessidades da organiza\u00e7\u00e3o, isso \u00e9 necess\u00e1rio para enriquecer as informa\u00e7\u00f5es combinando dados do NVD, EUVD, BDU, GitHub Advisory Database e osv.dev, ou para comprar um feed de intelig\u00eancia de vulnerabilidades comercial no qual os dados j\u00e1 est\u00e3o agregados e enriquecidos. Em ambos os casos, tamb\u00e9m vale a pena monitorar os feeds de intelig\u00eancia de amea\u00e7as para rastrear tend\u00eancias de explora\u00e7\u00e3o reais e obter um entendimento do perfil dos invasores que visam vulnerabilidades espec\u00edficas. A Kaspersky fornece um <a href=\"https:\/\/www.kaspersky.com\/open-source-feed?icid=br_kdailyplacehold_acq_ona_smm__onl_b2b_blo_wpplaceholder________8c9c26f46d093c2c\" target=\"_blank\" rel=\"noopener nofollow\">feed de dados especializado especificamente focado em componentes de c\u00f3digo aberto<\/a>.<\/li>\n<li>An\u00e1lise detalhada da composi\u00e7\u00e3o do software. As ferramentas especializadas de an\u00e1lise de composi\u00e7\u00e3o de software (SCA) permitem o mapeamento correto da cadeia de depend\u00eancias no c\u00f3digo-fonte aberto para realizar o invent\u00e1rio completo das bibliotecas que est\u00e3o sendo usadas e descobrir componentes desatualizados ou sem suporte. Os dados sobre componentes \u00edntegros tamb\u00e9m s\u00e3o \u00fateis para enriquecer o registro de artefatos.<\/li>\n<li>Identifica\u00e7\u00e3o do abandonware. Mesmo que um componente n\u00e3o apresente vulnerabilidades formais e o encerramento do suporte ainda n\u00e3o tenha sido declarado oficialmente, o processo de verifica\u00e7\u00e3o deve sinalizar os componentes que n\u00e3o receberam atualiza\u00e7\u00f5es h\u00e1 mais de um ano. Isso garante uma an\u00e1lise separada e uma poss\u00edvel substitui\u00e7\u00e3o, assim como ocorre com os componentes em EOL (fim da vida \u00fatil).<\/li>\n<\/ul>\n<h1>Prote\u00e7\u00e3o do c\u00f3digo e dos agentes de IA<\/h1>\n<p>As atividades dos sistemas de IA usados na codifica\u00e7\u00e3o devem ser agrupadas em um conjunto abrangente de medidas de seguran\u00e7a: desde a filtragem de dados de entrada at\u00e9 o treinamento do usu\u00e1rio:<\/p>\n<ul>\n<li>Restri\u00e7\u00f5es de recomenda\u00e7\u00f5es de depend\u00eancias. Configure o ambiente de desenvolvimento para garantir que os agentes e assistentes de IA consultem apenas componentes e bibliotecas do registro de artefatos confi\u00e1vel. Se eles n\u00e3o contiverem as ferramentas corretas, o modelo deve acionar uma solicita\u00e7\u00e3o para incluir a depend\u00eancia no registro em vez de extrair algo do PyPI que apenas corresponda \u00e0 descri\u00e7\u00e3o.<\/li>\n<li>Filtragem das sa\u00eddas do modelo. Apesar dessas restri\u00e7\u00f5es, tudo o que for gerado pelo modelo tamb\u00e9m deve ser verificado para garantir que o c\u00f3digo de IA n\u00e3o contenha depend\u00eancias desatualizadas, sem suporte, vulner\u00e1veis ou inventadas. Essa verifica\u00e7\u00e3o deve ser integrada diretamente no processo de aceita\u00e7\u00e3o do c\u00f3digo ou no est\u00e1gio de prepara\u00e7\u00e3o da compila\u00e7\u00e3o. Ela n\u00e3o substitui o processo de an\u00e1lise est\u00e1tica tradicional: as ferramentas SAST ainda devem ser incorporadas no pipeline de CI\/CD.<\/li>\n<li>Treinamento do desenvolvedor. As equipes de TI e de seguran\u00e7a devem estar extremamente familiarizadas com as caracter\u00edsticas dos sistemas de IA, seus princ\u00edpios operacionais e erros comuns. Para conseguir isso, os funcion\u00e1rios devem completar um <a href=\"https:\/\/xtraining.kaspersky.com\/courses\/large-language-models-security\/?icid=br_kdailyplacehold_acq_ona_smm__onl_b2b_kdaily_wpplaceholder_sm-team___xtraining____5c5f6c7fae6ff572\" target=\"_blank\" rel=\"noopener\">curso de treinamento especializado<\/a>, adaptados \u00e0s suas fun\u00e7\u00f5es espec\u00edficas.<\/li>\n<\/ul>\n<h1>Remo\u00e7\u00e3o sistem\u00e1tica de componentes em EOL<\/h1>\n<p>Se os sistemas de uma empresa utilizarem componentes de c\u00f3digo aberto desatualizados, deve-se adotar uma abordagem sistem\u00e1tica e consistente para lidar com as vulnerabilidades. Existem tr\u00eas m\u00e9todos principais para fazer isso:<\/p>\n<ul>\n<li>Migra\u00e7\u00e3o. Este \u00e9 o m\u00e9todo mais complexo e caro para uma organiza\u00e7\u00e3o, pois envolve a substitui\u00e7\u00e3o total de um componente, seguida pela adapta\u00e7\u00e3o, reescrita ou substitui\u00e7\u00e3o dos aplicativos constru\u00eddos sobre ele. Decidir sobre uma migra\u00e7\u00e3o \u00e9 muito mais dif\u00edcil quando se exige uma revis\u00e3o geral de todo o c\u00f3digo interno. Isso costuma afetar os componentes principais: \u00e9 imposs\u00edvel migrar facilmente do Node.js 14 ou do Python 2.<\/li>\n<li>Suporte de longo prazo (LTS). Existe um mercado de servi\u00e7os de suporte dedicado para projetos legados de larga escala. \u00c0s vezes, isso envolve uma bifurca\u00e7\u00e3o do sistema legado mantido por desenvolvedores de terceiros; em outros casos, equipes especializadas fazem o backport de patches que corrigem vulnerabilidades espec\u00edficas em vers\u00f5es mais antigas e sem suporte. A transi\u00e7\u00e3o para o LTS geralmente exige custos de suporte cont\u00ednuos, mas, em muitos casos, isso ainda pode ser mais econ\u00f4mico do que uma migra\u00e7\u00e3o completa.<\/li>\n<li>Controles compensat\u00f3rios. Com base nos resultados de an\u00e1lises detalhadas, \u00e9 poss\u00edvel criar um <a href=\"https:\/\/www.kaspersky.com\/blog\/legacy-it-update-troubles-and-mitigations\/48692\/\" target=\"_blank\" rel=\"noopener nofollow\">conjunto de medidas de seguran\u00e7a abrangentes para mitigar o risco de explora\u00e7\u00e3o das vulnerabilidades de um produto legado<\/a>. Tanto a efic\u00e1cia quanto a viabilidade econ\u00f4mica dessa abordagem dependem da fun\u00e7\u00e3o do software na organiza\u00e7\u00e3o.<\/li>\n<\/ul>\n<p>Os departamentos de seguran\u00e7a, TI e neg\u00f3cios devem trabalhar juntos para escolher um desses tr\u00eas m\u00e9todos para cada componente abandonado ou com EOL documentado e refletir a escolha feita nos registros de ativos e SBOMs da empresa.<\/p>\n<h1>Gerenciamento de vulnerabilidades de c\u00f3digo aberto baseado em risco<\/h1>\n<p>Todos os m\u00e9todos listados acima reduzem o volume de softwares e componentes vulner\u00e1veis que entram na organiza\u00e7\u00e3o, o que simplifica a detec\u00e7\u00e3o e a corre\u00e7\u00e3o de falhas. Apesar disso, \u00e9 imposs\u00edvel eliminar todos os defeitos: o n\u00famero de aplicativos e componentes est\u00e1 crescendo muito r\u00e1pido.<\/p>\n<p>Portanto, \u00e9 essencial <a href=\"https:\/\/www.kaspersky.com.br\/blog\/cvss-rbvm-vulnerability-management\/24033\/\" target=\"_blank\" rel=\"noopener\">priorizar as vulnerabilidades com base nos riscos reais que elas representam<\/a>. O modelo de avalia\u00e7\u00e3o de risco deve ser expandido para considerar as caracter\u00edsticas do c\u00f3digo aberto, al\u00e9m de responder \u00e0s seguintes perguntas:<\/p>\n<ul>\n<li>A ramifica\u00e7\u00e3o do c\u00f3digo vulner\u00e1vel \u00e9 realmente executada no ambiente da organiza\u00e7\u00e3o? Deve-se realizar uma an\u00e1lise de acessibilidade das vulnerabilidades descobertas. Muitos snippets de c\u00f3digo defeituosos nunca s\u00e3o realmente executados na implementa\u00e7\u00e3o espec\u00edfica da organiza\u00e7\u00e3o, fazendo com que seja imposs\u00edvel explorar a vulnerabilidade. Certas solu\u00e7\u00f5es de SCA podem realizar esta an\u00e1lise. Esse mesmo processo permite avaliar um cen\u00e1rio alternativo: o que acontece se os procedimentos ou componentes vulner\u00e1veis forem removidos completamente do projeto? \u00c0s vezes, esse m\u00e9todo de remedia\u00e7\u00e3o \u00e9 surpreendentemente indolor.<\/li>\n<li>O defeito est\u00e1 sendo explorado em ataques reais? H\u00e1 um PoC dispon\u00edvel? As respostas a essas perguntas fazem parte de estruturas de prioriza\u00e7\u00e3o padr\u00e3o, como EPSS, mas o rastreamento deve ser realizado em um conjunto muito mais amplo de fontes de intelig\u00eancia.<\/li>\n<li>A atividade de criminosos cibern\u00e9ticos foi relatada nesse registro de depend\u00eancia ou em componentes relacionados e semelhantes? Estes s\u00e3o fatores adicionais para a prioriza\u00e7\u00e3o.<\/li>\n<\/ul>\n<p>A considera\u00e7\u00e3o desses fatores permite que a equipe aloque recursos de forma eficaz e corrija os defeitos mais perigosos primeiro.<\/p>\n<h1>A transpar\u00eancia nunca sai de moda<\/h1>\n<p>O padr\u00e3o de seguran\u00e7a para softwares de c\u00f3digo aberto s\u00f3 vai continuar subindo. As empresas que desenvolvem aplicativos, mesmo que para uso interno, enfrentar\u00e3o press\u00f5es regulat\u00f3rias que exigem seguran\u00e7a cibern\u00e9tica documentada e verific\u00e1vel nos seus sistemas. De acordo com as <a href=\"https:\/\/www.sonatype.com\/state-of-the-software-supply-chain\/introduction\" target=\"_blank\" rel=\"noopener nofollow\">estimativas dos especialistas da Sonatype<\/a>, 90% das empresas em todo o mundo j\u00e1 se enquadram em um ou mais requisitos que as obrigam a fornecer provas da confiabilidade do software que usam. Portanto, os especialistas consideram a transpar\u00eancia \u201co pilar fundamental da seguran\u00e7a da cadeia de suprimento de software\u201d.<\/p>\n<p>Ao controlar o uso de componentes e aplicativos de c\u00f3digo aberto, enriquecer a intelig\u00eancia contra amea\u00e7as e fazer o monitoramento rigoroso dos sistemas de desenvolvimento orientados por IA, as organiza\u00e7\u00f5es podem introduzir as inova\u00e7\u00f5es que tanto desejam, ao mesmo tempo em que atingem o padr\u00e3o elevado definido por reguladores e clientes.<\/p>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"mdr\"><input type=\"hidden\" class=\"placeholder_for_banner\" data-cat_id=\"mdr\" value=\"24869\">\n","protected":false},"excerpt":{"rendered":"<p>Como gerenciar vulnerabilidades ao desenvolver ou usar software de c\u00f3digo aberto.<\/p>\n","protected":false},"author":2722,"featured_media":24914,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1119,1655],"tags":[3417,2114,3363,3078,1342,73,3314,267],"class_list":{"0":"post-24913","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-agentes-de-ia","10":"tag-codigo-aberto","11":"tag-cvss","12":"tag-estrategia","13":"tag-ia","14":"tag-patches","15":"tag-vulnerabilidade-de-dia-zero","16":"tag-vulnerabilidades"},"hreflang":[{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/managing-open-source-vulnerabilities\/24913\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/managing-open-source-vulnerabilities\/30368\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/managing-open-source-vulnerabilities\/25418\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/managing-open-source-vulnerabilities\/30215\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/managing-open-source-vulnerabilities\/41643\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/managing-open-source-vulnerabilities\/55554\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/managing-open-source-vulnerabilities\/30484\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/managing-open-source-vulnerabilities\/36103\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/managing-open-source-vulnerabilities\/35755\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com.br\/blog\/tag\/vulnerabilidade-de-dia-zero\/","name":"vulnerabilidade de dia zero"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/24913","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/comments?post=24913"}],"version-history":[{"count":3,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/24913\/revisions"}],"predecessor-version":[{"id":24918,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/24913\/revisions\/24918"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media\/24914"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media?parent=24913"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/categories?post=24913"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/tags?post=24913"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}