Com mais organizações utilizando códigos-fonte abertos em seus próprios aplicativos, elas precisarão ser capazes de lidar com as complexidades de tais ambientes com ferramentas de automação para que possam responder rapidamente a novas vulnerabilidades.
Quase todos os softwares desenvolvidos internamente hoje continham alguns códigos-fonte abertos, observou Phillip Ivancic, chefe de estratégia de soluções da Ásia-Pacífico do Synopsys Software Integrity Group.
De acordo com o relatório de análise de risco e segurança de código aberto de 2022 do fornecedor de segurança, 97% das bases de código comerciais continham pelo menos alguns códigos-fonte abertos. Destes, uma média de 78% do código nas bases de código era de código aberto. Lançado em maio, o estudo analisou 2.409 bases de código comerciais em 17 setores.
A maioria das organizações não gostaria de construir tudo do zero quando desenvolve seu próprio software, disse Liu Yang, cofundador e CEO da Scantist, um fornecedor de segurança de aplicativos que em 2016 se desmembrou de um laboratório de pesquisa na Universidade Tecnológica de Nanyang (NTU) de Cingapura. .
Agora havia muitas bibliotecas e bases de código bem estabelecidas em software de código aberto (OSS) que as organizações poderiam explorar e construir, disse Liu em entrevista ao ZDNet.
Andrew Martin, chefe da Databricks no Sul da Ásia, concordou, acrescentando que o código aberto permitiu que as empresas inovassem mais rapidamente e alavancassem códigos que já estavam disponíveis, em vez de gastar recursos construindo software proprietário internamente.
A tecnologia de código aberto também garante total transparência e visibilidade do código-fonte, oferecendo às equipes de dados uma conexão com a comunidade de código aberto mais ampla, disse Martin.
No entanto, disse Liu, usar o código aberto significava que qualquer vulnerabilidade nos códigos poderia ser herdada pelo aplicativo corporativo host. Vulnerabilidades de código aberto, portanto, sempre devem ser abordadas primeiro, disse ele.
A falha em fazer isso pode levar a sérios riscos de segurança para as empresas que não se mantêm informadas sobre essas vulnerabilidades e atualizam seus softwares de acordo, alertou.
O estudo da Synopsys revelou que 81% dos códigos de software continham pelo menos uma vulnerabilidade de código aberto conhecida, uma queda de 3% em relação ao ano anterior.
Embora explorar o código aberto não implique que o software interno seja menos seguro, isso trouxe considerações importantes que devem ser abordadas e gerenciadas, disse Ivancic ao ZDNet. Por um lado, as empresas devem conhecer todos os componentes do OSS, incluindo as versões reais que foram usadas na base de código de seus projetos.
Conhecido como Software Bill of Materials (SBOM), esse repositório central garantiria que as empresas pudessem responder rapidamente quando novas vulnerabilidades fossem descobertas, como a falha de dia zero Log4j do ano passado. Com um SBOM, eles seriam capazes de identificar aplicativos vulneráveis e implantar as ações de remediação necessárias, disse ele.
Eles também precisavam conhecer a base de código exata do OSS usada em qualquer projeto, para que pudessem determinar se o aplicativo seria afetado quando novas vulnerabilidades de alto risco fossem descobertas.
A falha de dia zero do Log4j, em particular, provavelmente geraria mais vulnerabilidades nos próximos anos devido ao crescente uso de OSS, disse Liu.
Além disso, ele observou que a biblioteca Java para registrar mensagens de erro em aplicativos era uma estrutura fundamental usada por metade dos aplicativos Java, o que significava que todos os softwares de código aberto que usavam a biblioteca potencialmente tinham vulnerabilidades graves.
Os hackers podem explorar a falha do Log4j para realizar ataques remotos e usar a biblioteca OSS de uma empresa para controlar seus sistemas.
Também foi difícil lidar com essas vulnerabilidades devido à natureza em camadas do desenvolvimento de OSS, disse ele.
“Se você estiver usando uma biblioteca OSS para um aplicativo, essa biblioteca provavelmente está usando uma segunda biblioteca e que, por sua vez, está usando uma terceira biblioteca”, explicou Liu. “Se a terceira biblioteca tiver uma vulnerabilidade crítica e você estiver usando a primeira biblioteca, há uma vulnerabilidade intrínseca nessa cadeia de dependência. Ela pode apresentar riscos de segurança para você, mesmo se você não estiver usando a terceira biblioteca.”
Identificar todas as interdependências passivas e indiretas está longe de ser fácil, observou ele, acrescentando que pode ser difícil para as empresas acessarem especialistas em segurança para realizar tais trabalhos. Ele apontou para a necessidade de ferramentas automatizadas para dar suporte a essas avaliações de segurança.
Ivancic enfatizou a necessidade de as organizações entenderem os riscos operacionais e de licenciamento envolvidos no uso de códigos-fonte abertos. Por exemplo, ele observou que as bases de código OSS que não tinham uma comunidade ativa de contribuidores podem indicar riscos potenciais, já que novas vulnerabilidades podem não ser descobertas e corrigidas em tempo hábil.
O estudo da Synopsys revelou que 88% das bases de código usavam componentes que não eram a versão mais recente, enquanto 84% tinham códigos-fonte abertos que estavam desatualizados há mais de quatro anos. Além disso, 53% das bases de código auditadas tinham conflitos de licenciamento e 20% continham código aberto sem licença ou licença personalizada.
Ivancic observou que os projetos de código aberto tinham várias cláusulas de licenciamento que variavam de muito permissivas àquelas que podem exigir que os usuários publiquem trabalhos derivados sob os mesmos termos de licenciamento. Um SBOM, então, permitiria às organizações rastrear melhor as diferentes condições de licenciamento, disse ele.
“Se as organizações não forem proativas na manutenção e revisão de suas atualizações de vulnerabilidades, elas correm o risco de se tornar um alvo fácil para os invasores”, observou ele. “Além disso, se não cumprirem as licenças de código aberto, podem colocar seus negócios em risco de litígio e se expor a ameaças à sua propriedade intelectual”.
Assim como Liu, Ivancic destacou a importância de incluir automação nos pipelines de desenvolvimento para mitigar riscos com base em políticas de segurança internas.
“O OSS não é inseguro em si… o desafio está em todas as versões e componentes que podem compor um projeto de software”, explicou. “É impossível acompanhar sem automação e priorização.”
Ele observou que a comunidade OSS foi responsiva ao abordar questões de segurança e implantar correções, mas as organizações que utilizam OSS teriam que navegar pela complexidade para garantir que seu software tivesse a base de código correta e atualizada.
Isso foi agravado pelo fato de que a maioria das organizações teria que gerenciar muitos projetos simultaneamente, disse ele, enfatizando a importância de estabelecer uma estratégia holística de segurança de software.
Ele apontou ainda para o Instituto Nacional de Padrões e Tecnologia dos EUA (NIST), que ofereceu uma estrutura de cadeia de fornecimento de software que poderia ajudar as organizações a planejar sua resposta de segurança de OSS.
Regulamentos úteis, mas não o suficiente para corrigir todos
Questionado se os regulamentos são necessários para impulsionar melhores práticas de segurança, Liu disse que a maioria das empresas vê a segurança cibernética como um custo e não gostaria de abordá-la ativamente na ausência de qualquer incentivo.
Portanto, algumas políticas de governança ou regulatórias correspondentes seriam úteis para melhorar a segurança geral do software de código aberto, disse ele.
Ele observou que houve discussões entre os desenvolvedores sobre os riscos de explorações de backdoor e códigos maliciosos, o que sugeriu a necessidade de uma melhor governança em termos de segurança e responsabilidade. Ele acrescentou que sua equipe de pesquisa na NTU estava procurando propor um conjunto de mecanismos e regras para abordar a segurança do OSS.
No entanto, ele disse que a regulamentação por si só não resolveria tudo. As organizações ainda precisavam descobrir como obter melhor segurança de maneira econômica.
Isso, disse Liu, era onde o ecossistema mais amplo poderia colaborar. Ele acrescentou que o Scantist recentemente executou um programa de recompensas de bugs no qual os participantes foram incentivados a usar a análise de composição de software para encontrar e corrigir vulnerabilidades.
O objetivo aqui era promover a segurança do OSS, bem como aumentar a conscientização entre as pequenas e médias empresas, disse Liu. A Scantist oferece uma ferramenta de análise de composição de software, chamada Thompson, que é apresentada para ajudar as empresas a gerenciar os riscos de segurança e conformidade de suas bibliotecas de código aberto.
Quando contatada, a Agência de Segurança Cibernética de Cingapura (CSA) disse que atualmente não tem planos de impor regulamentos de segurança relacionados ao uso de software de código aberto. Em vez disso, a agência governamental defendeu a adoção de princípios de confiança zero e que todas as organizações de Cingapura construíssem suas defesas cibernéticas com base nessa estrutura.
Um porta-voz da CSA disse ao ZDNet que a segurança do OSS deve ser avaliada como parte dos esforços de uma empresa para reduzir os riscos de seus parceiros da cadeia de suprimentos. Para ajudar as empresas a fazer isso, a CSA introduziu várias medidas, incluindo programas para setores de CII (infraestrutura de informação crítica) e dispositivos inteligentes de consumo.
Por exemplo, o programa CII Supply Chain foi anunciado no ano passado para delinear processos e melhores práticas que podem ajudar os operadores de CII e seus fornecedores a gerenciar os riscos da cadeia de suprimentos e reforçar sua postura de segurança cibernética da cadeia de suprimentos.
A CSA no início deste ano também introduziu as marcas de certificação Cyber Essentials e Cyber Trust que certificaram as medidas de segurança cibernética que as organizações adotaram para seus produtos e serviços. A iniciativa visa fornecer “indicadores visíveis” de negócios que priorizam a segurança cibernética, bem como aumentar o nível de confiança entre as organizações que negociaram com players certificados, disse o porta-voz da CSA.
Ele acrescentou que o Esquema de Rotulagem de Segurança Cibernética, que classificou os dispositivos inteligentes de acordo com seus níveis de provisões de segurança cibernética, com os níveis 3 e 4 nas duas categorias mais altas. Ele observou que os produtos certificados sob a Esquema de Critérios Comuns de Cingapura teria passado por análise binária para identificar vulnerabilidades conhecidas no OSS.
De acordo com o estudo da Synopsys, a indústria da Internet das Coisas (IoT) estava entre as maiores usuárias de código aberto, com 100% das bases de código do setor contendo códigos de código aberto. No entanto, 64% das bases de código de IoT contêm vulnerabilidades.
Martin observou que o código aberto nunca foi feito para competir com o código proprietário tradicional. “Hoje, muitos desenvolvedores de software e entidades estão procurando integrar o código aberto com os sistemas operacionais e aplicativos existentes”, disse ele. “Isso é diferente das incompatibilidades que podem ocorrer devido a diferenças em elementos como formatos de dados. Em última análise, a integração de código aberto pode acontecer desde que o desenvolvimento esteja lá.”
Ele acrescentou que mesmo as indústrias mais regulamentadas, como o setor público e as instituições financeiras, estão adotando o conceito de que o código aberto é a melhor maneira de promover a inovação, recrutar e reter os melhores talentos e uma plataforma de tecnologia à prova de futuro.
COBERTURA RELACIONADA
source – www.zdnet.com
