{"id":21153,"date":"2023-04-25T15:34:54","date_gmt":"2023-04-25T18:34:54","guid":{"rendered":"https:\/\/www.kaspersky.com.br\/blog\/?p=21153"},"modified":"2023-04-25T15:34:54","modified_gmt":"2023-04-25T18:34:54","slug":"open-source-top-10-risks","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.br\/blog\/open-source-top-10-risks\/21153\/","title":{"rendered":"C\u00f3digo aberto: os 10 principais riscos para os neg\u00f3cios"},"content":{"rendered":"

As empresas de TI foram as primeiras a adotar o c\u00f3digo aberto e muitas grandes empresas seguiram o exemplo. Afinal, a capacidade de reutilizar e modificar o c\u00f3digo independentemente, bem como corrigir bugs, estimula a inova\u00e7\u00e3o r\u00e1pida e a redu\u00e7\u00e3o de custos<\/a>.<\/p>\n

Mas o c\u00f3digo aberto tamb\u00e9m tem algumas caracter\u00edsticas negativas inerentes \u2013 devido \u00e0s responsabilidades confusas de criar e manter o c\u00f3digo. O Endor Labs, auxiliado por mais de 20 CISOs e CTOs de grandes empresas de TI, realizou uma an\u00e1lise sistem\u00e1tica para produzir esta lista dos 10 principais riscos<\/a>.<\/p>\n

Vulnerabilidades conhecidas<\/h2>\n

O risco mais significativo identificado foi a presen\u00e7a de vulnerabilidades tanto no pr\u00f3prio projeto de c\u00f3digo aberto quanto em suas depend\u00eancias \u2014 ou seja, componentes externos de c\u00f3digo aberto usados \u200b\u200bno projeto. Vulnerabilidades em depend\u00eancias podem causar problemas cr\u00edticos para dezenas de grandes suites de software comercial, como foi o caso da modesta biblioteca Apache Log4j (CVE-2021-44228<\/a>).<\/p>\n

Como se proteger<\/strong>: Examine regularmente seus aplicativos em busca de vulnerabilidades conhecidas \u2014 incluindo aquelas com depend\u00eancias diretas e indiretas. Aplique as corre\u00e7\u00f5es dispon\u00edveis prontamente. Para otimizar os recursos da empresa, as patches podem ser priorizadas com base na gravidade de uma determinada vulnerabilidade e na probabilidade de sua explora\u00e7\u00e3o no software utilizado.<\/p>\n

Pacotes leg\u00edtimos comprometidos<\/h2>\n

Como at\u00e9 80% do c\u00f3digo do projeto de c\u00f3digo aberto \u00e9 herdado de outros projetos na forma dessas depend\u00eancias, sempre h\u00e1 uma chance de que os componentes de terceiros usados \u200b\u200bem seu aplicativo tenham sido trojanizados. Isso pode acontecer quando o desenvolvedor desses componentes \u00e9 hackeado ou o sistema de distribui\u00e7\u00e3o de componentes (ou seja, o gerenciador de pacotes) cont\u00e9m uma vulnerabilidade que permite que o pacote seja falsificado. Nesse caso, um c\u00f3digo malicioso de terceiros aparece repentinamente em seu aplicativo, que na pr\u00e1tica \u00e9 frequentemente usado para roubar informa\u00e7\u00f5es<\/a> ou para v\u00e1rios esquemas il\u00edcitos de enriquecimento (spam, golpes de adware, minera\u00e7\u00e3o<\/a>).<\/p>\n

Como se proteger<\/strong>: Atualmente, n\u00e3o existe uma metodologia madura para proteger contra essa amea\u00e7a, portanto, uma combina\u00e7\u00e3o de medidas \u00e9 necess\u00e1ria: sistemas manuais e autom\u00e1ticos para an\u00e1lise de c\u00f3digo-fonte e monitoramento de reposit\u00f3rios<\/a>; armazenamento local de vers\u00f5es confi\u00e1veis \u200b\u200bde componentes; uso de Intelig\u00eancia contra amea\u00e7as<\/a> para detectar tais ataques em seus est\u00e1gios iniciais (antes que eles tenham tempo de afetar os pacotes usados \u200b\u200bnos aplicativos de c\u00f3digo aberto da empresa).<\/p>\n

Ataque dos \u201chom\u00f4nimos\u201d<\/h2>\n

Os invasores criam pacotes com nomes que lembram pacotes leg\u00edtimos ou copiam os nomes de pacotes verdadeiros desenvolvidos em outras linguagens de programa\u00e7\u00e3o ou publicados em diferentes plataformas de distribui\u00e7\u00e3o. Isso cria o risco de que seus desenvolvedores de c\u00f3digo aberto possam integrar um pacote malicioso \u201chom\u00f4nimo\u201d em vez do genu\u00edno.<\/p>\n

Como se proteger<\/strong>: instrua os desenvolvedores a ficarem vigilantes. Como parte de um procedimento padr\u00e3o, antes do uso, os desenvolvedores precisam verificar o c\u00f3digo-fonte dos pacotes quanto a peculiaridades, como fragmentos criptografados no c\u00f3digo, sequestro de fun\u00e7\u00f5es e afins. E \u00e9 aconselh\u00e1vel verificar as assinaturas digitais dos pacotes (se houver).<\/p>\n

C\u00f3digo n\u00e3o suportado<\/h2>\n

Os desenvolvedores de componentes, pacotes e aplicativos de c\u00f3digo aberto podem obter suporte para eles a qualquer momento e por qualquer motivo. Isso geralmente acontece com pequenos pacotes desenvolvidos por uma ou duas pessoas. Se isso acontecer, n\u00e3o h\u00e1 quem atualize o pacote para compatibilidade com novas tecnologias ou elimine riscos de seguran\u00e7a da informa\u00e7\u00e3o.<\/p>\n

Como se proteger<\/strong>: Avalie o n\u00edvel de maturidade do projeto e as perspectivas de desenvolvimento\/suporte antes de integr\u00e1-lo aos processos de neg\u00f3cios e ao seu pr\u00f3prio c\u00f3digo. Preste aten\u00e7\u00e3o ao n\u00famero de desenvolvedores que mant\u00eam o projeto e \u00e0 frequ\u00eancia dos lan\u00e7amentos. Verifique os lan\u00e7amentos de suporte de longo prazo (LTS, na sigla em ingl\u00eas) e quando eles foram lan\u00e7ados. Para alguns projetos est\u00e1veis, no entanto, \u00e9 normal que os lan\u00e7amentos sejam pouco frequentes e apenas corrijam bugs.<\/p>\n

Software desatualizado<\/h2>\n

O uso de vers\u00f5es antigas de componentes em projetos torna a corre\u00e7\u00e3o muito mais dif\u00edcil. Esse problema \u00e9 especialmente cr\u00edtico no caso do risco n\u00famero um: vulnerabilidades em componentes. Normalmente, um problema com depend\u00eancias obsoletas surge quando uma nova vers\u00e3o de um componente difere significativamente das itera\u00e7\u00f5es anteriores em termos de sintaxe ou sem\u00e2ntica. Nesse cen\u00e1rio, uma vers\u00e3o desatualizada pode permanecer em uso por muitos anos sem nenhuma atualiza\u00e7\u00e3o de seguran\u00e7a.<\/p>\n

Como se proteger<\/strong>: d\u00ea tempo aos desenvolvedores para trabalhar com depend\u00eancias \u2014 incluindo a refatora\u00e7\u00e3o do c\u00f3digo para atualiz\u00e1-las para as vers\u00f5es mais recentes dos componentes em uso.<\/p>\n

Depend\u00eancias n\u00e3o rastreadas<\/h2>\n

Como quase todos os aplicativos usam componentes de terceiros \u2014 que, por sua vez, usam outros componentes de terceiros \u2014 os desenvolvedores do aplicativo principal geralmente n\u00e3o sabem que um determinado componente est\u00e1 em seu c\u00f3digo. Nesse caso, ele n\u00e3o \u00e9 verificado quanto a todos os outros riscos da lista. O status de atualiza\u00e7\u00f5es, vulnerabilidades e o resto \u00e9 simplesmente desconhecido.<\/p>\n

Como se proteger<\/strong>: Mantenha uma Lista de Materiais de Software (SBOM, na sigla em ingl\u00eas) detalhada com o uso de ferramentas de varredura que podem detectar at\u00e9 mesmo depend\u00eancias que s\u00e3o usadas sem um gerenciador de pacotes.<\/p>\n

Riscos regulat\u00f3rios e de licenciamento<\/h2>\n

Apesar de ser de c\u00f3digo aberto, todo aplicativo e pacote deste tipo vem com sua pr\u00f3pria licen\u00e7a de uso. Os riscos surgem se a licen\u00e7a for incompat\u00edvel com o uso do aplicativo para a finalidade pretendida ou se as licen\u00e7as de alguns componentes do aplicativo forem incompat\u00edveis entre si. Tamb\u00e9m \u00e9 poss\u00edvel que um ou mais componentes de depend\u00eancia violem as leis aplic\u00e1veis \u200b\u200bou os requisitos regulat\u00f3rios impostos \u00e0 empresa.<\/p>\n

Como se proteger<\/strong>: A j\u00e1 mencionada SBOM e as ferramentas de varredura de c\u00f3digo devem ser usadas \u200b\u200bpara rastrear licen\u00e7as e requisitos de licenciamento aplic\u00e1veis \u200b\u200ba aplicativos e componentes de c\u00f3digo aberto usados \u200b\u200bna empresa. E faz sentido trabalhar com o departamento jur\u00eddico para desenvolver uma lista de licen\u00e7as padr\u00e3o aceit\u00e1veis \u200b\u200bpara a empresa, detalhando sua compatibilidade com a finalidade do software utilizado. Software com licen\u00e7as incompat\u00edveis ou sem licen\u00e7a deve ser removido.<\/p>\n

Software imaturo<\/h2>\n

Utilizar componentes desenvolvidos por uma equipe sem maturidade traz uma s\u00e9rie de inconveni\u00eancias e riscos. Os problemas associados ao software imaturo variam de documenta\u00e7\u00e3o de c\u00f3digo insuficiente ou imprecisa a instabilidade e opera\u00e7\u00e3o propensa a erros e a aus\u00eancia de um conjunto de testes para avalia\u00e7\u00e3o de regress\u00e3o. Al\u00e9m do mais, o c\u00f3digo imaturo tem maior probabilidade de abrigar vulnerabilidades cr\u00edticas. Tudo isso torna impratic\u00e1vel o uso de software imaturo e aumenta tanto os custos envolvidos quanto os riscos de eventos cr\u00edticos e tempo de inatividade.<\/p>\n

Como se proteger<\/strong>: Antes de implantar um aplicativo ou componente, verifique se os desenvolvedores est\u00e3o usando as melhores pr\u00e1ticas atuais. Indicadores disso incluem documenta\u00e7\u00e3o completa e atualizada, pipelines de CI\/CD para testes de regress\u00e3o, bem como informa\u00e7\u00f5es detalhadas sobre a cobertura do teste e at\u00e9 mesmo o n\u00famero de pacotes que j\u00e1 usam o componente fornecido.<\/p>\n

Altera\u00e7\u00f5es n\u00e3o aprovadas<\/h2>\n

Os componentes usados \u200b\u200bpor um aplicativo podem mudar de maneira completamente invis\u00edvel para seus desenvolvedores. Essa situa\u00e7\u00e3o pode surgir se os componentes forem baixados de um servidor sem controle de vers\u00e3o estrito e\/ou por canais de comunica\u00e7\u00e3o n\u00e3o criptografados e n\u00e3o forem verificados usando hashes e assinaturas digitais. Nesse caso, a montagem do aplicativo teoricamente pode produzir um resultado diferente a cada vez.<\/p>\n

Como se proteger<\/strong>: Seja rigoroso na aplica\u00e7\u00e3o de pr\u00e1ticas de desenvolvimento seguras. Durante o desenvolvimento, use identificadores de recursos que indiquem claramente a vers\u00e3o do componente. Al\u00e9m disso, verifique os componentes baixados usando assinaturas digitais. Sempre use protocolos de comunica\u00e7\u00e3o seguros.<\/p>\n

Depend\u00eancias muito grandes ou muito pequenas<\/h2>\n

Atualmente, os desenvolvedores podem integrar um componente com apenas tr\u00eas linhas de c\u00f3digo. Ao mesmo tempo, \u00e9 igualmente prejudicial quando todo o componente consiste em quatro linhas de c\u00f3digo (muito pequenas) e quando o c\u00f3digo que voc\u00ea pretende usar \u00e9 apenas um dos milhares de recursos do componente \u2014 o restante n\u00e3o \u00e9 usado no aplicativo da empresa. Nesse caso, os desenvolvedores ficam sobrecarregados com a manuten\u00e7\u00e3o de mais uma depend\u00eancia por causa desta funcionalidade m\u00ednima.<\/p>\n

Como se proteger<\/strong>: Evite depend\u00eancias com pouca funcionalidade; desenvolva tal funcionalidade dentro do aplicativo principal.<\/p>\n","protected":false},"excerpt":{"rendered":"

Aplicativos de c\u00f3digo aberto requerem implementa\u00e7\u00e3o e manuten\u00e7\u00e3o adequadas; caso contr\u00e1rio, uma empresa poderia enfrentar muitas amea\u00e7as. Destacamos os principais riscos.<\/p>\n","protected":false},"author":2722,"featured_media":21155,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1119,1655],"tags":[3119,1185,2114,2842,935,776],"class_list":{"0":"post-21153","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-aplicacoes","10":"tag-business","11":"tag-codigo-aberto","12":"tag-desenvolvimento","13":"tag-negocios","14":"tag-riscos"},"hreflang":[{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/open-source-top-10-risks\/21153\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/open-source-top-10-risks\/25497\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/open-source-top-10-risks\/20930\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/open-source-top-10-risks\/28106\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/open-source-top-10-risks\/25804\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/open-source-top-10-risks\/26221\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/open-source-top-10-risks\/28706\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/open-source-top-10-risks\/35092\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/open-source-top-10-risks\/47875\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/open-source-top-10-risks\/20461\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/open-source-top-10-risks\/30029\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/open-source-top-10-risks\/26124\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/open-source-top-10-risks\/31809\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/open-source-top-10-risks\/31496\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com.br\/blog\/tag\/codigo-aberto\/","name":"C\u00f3digo aberto"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/21153","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=21153"}],"version-history":[{"count":2,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/21153\/revisions"}],"predecessor-version":[{"id":21157,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/21153\/revisions\/21157"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media\/21155"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media?parent=21153"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/categories?post=21153"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/tags?post=21153"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}