0
0
O software de código aberto é onipresente. Tornou-se um motor inigualável da inovação tecnológica porque as organizações que a usam não têm que reinventar a roda para componentes de software comuns.
No entanto, a onipresença do software de código aberto também apresenta um risco significativo à segurança, pois abre a porta para que vulnerabilidades sejam introduzidas (intencionalmente ou inadvertidamente) aos consumidores de produtos de software de código aberto. A recente corrida para enfrentar grandes vulnerabilidades na amplamente utilizada biblioteca de código Log4j é o maior sinal ainda de que os riscos dentro do ambiente de software de código aberto devem ser abordados.
O Open Source Appeal for Cybercriminals
O método de ataque de código aberto é atraente para maus atores porque pode ser generalizado e altamente eficaz. Os atacantes podem usar vários métodos para ofuscar mudanças maliciosas que contribuíram para projetos de código aberto, e o rigor na revisão do código para implicações de segurança pode variar amplamente entre os projetos. Sem controles rigorosos para detectar essas alterações maliciosas, elas podem passar despercebidas até que sejam distribuídas e incluídas em software em várias empresas.
Os ataques ao código-fonte aberto podem variar de tamanho e das entidades que afetam. Por exemplo, em julho passado, pesquisadores encontraram nove vulnerabilidades que afetam três projetos de código aberto — EspoCRM, Pimcore e Akaunting — que são frequentemente alavancados por pequenas e médias empresas. Além disso, a violação de dados da Equifax de 2017, que afetou os dados pessoais de 147 milhões de pessoas como resultado de uma vulnerabilidade no código-fonte aberto da organização, é um exemplo claro de como as vulnerabilidades podem ser exploradas por maus atores e criar efeitos nocivos em todo o país.
Nunca vou desistir de você
A CISA disse que centenas de milhões de dispositivos provavelmente foram afetados pela vulnerabilidade do Log4j. Dada a magnitude deste incidente, muitas empresas provavelmente estão analisando se devem aproveitar o código-fonte aberto para desenvolvimentos futuros.
No entanto, abrir mão do código aberto não é realista. Todo software moderno é construído a partir de componentes de código aberto, e reconstruir esses componentes sem código aberto exigiria investimentos maciços em tempo e dinheiro para produzir aplicações ainda menores. Mais de 60% dos sites em todo o mundo são executados em servidores Apache e Nginx, e 90% dos líderes de TI supostamente usam código-fonte aberto corporativo regularmente.
Testando e protegendo seu software
Em vez de evitar o código aberto, uma abordagem mais realista é que as equipes de segurança e software trabalhem juntas para desenvolver políticas e um processo de teste de aplicativos e componentes de software. As organizações devem pensar nisso como um processo de três partes. Ele requer um código de varredura e teste, estabelecendo um processo de corte claro para endereçamento e correção de vulnerabilidades à medida que surgem, e criando uma política interna na qual as regras são definidas para resolver problemas de segurança.
Quando se trata de testar a resiliência do seu ambiente de código aberto com ferramentas, a análise de código estático é um bom primeiro passo. Ainda assim, as organizações devem lembrar que esta é apenas a primeira camada de testes. A análise estática refere-se à análise do código-fonte antes que o aplicativo ou programa de software real entre no ar e abordando quaisquer vulnerabilidades descobertas. No entanto, a análise estática não pode detectar todas as ameaças maliciosas que podem ser incorporadas no código-fonte aberto. Testes adicionais em um ambiente de caixa de areia devem ser o próximo passo. Revisões rigorosas de código, análise dinâmica de código e testes unitários são outros métodos que podem ser aproveitados. (A análise dinâmica refere-se à análise do programa de software enquanto ele está sendo executado para identificar vulnerabilidades.)
Após a digitalização ser concluída, as organizações devem ter um processo claro para lidar com quaisquer vulnerabilidades descobertas. Os desenvolvedores podem estar se encontrando contra um prazo de lançamento, ou o patch de software pode exigir refatorar todo o programa e colocar uma pressão sobre os cronogramas. Esse processo deve ajudar os desenvolvedores a lidar com escolhas difíceis para proteger a segurança da organização, dando passos claros para lidar com vulnerabilidades e problemas mitigadores.
A etapa de mudança de política deve criar um plano documentado de como todas as decisões serão tomadas avançando e quais partes interessadas devem estar envolvidas durante todo o processo. Além disso, as organizações podem implementar vários controles para seus componentes de código aberto, como programas de certificação e credenciamento. No entanto, lembre-se de que isso adicionará custos adicionais de despesas gerais e reduzirá o desenvolvimento de projetos de código aberto.
Defendendo código aberto contra ataques futuros
A indústria em geral está tomando nota da necessidade de proteger ainda mais o código-fonte aberto. A Linux Foundation anunciou em outubro que levantou US$ 10 milhões ao lado de outros líderes do setor para identificar e corrigir vulnerabilidades de segurança cibernética em software de código aberto e desenvolver melhores práticas de ferramentas, treinamento, pesquisa e divulgação de vulnerabilidades.
Além dos esforços do setor para proteger o software construído no código-fonte aberto contra ameaças cibernéticas, as organizações também devem adotar uma abordagem ativa interna de sua estratégia de defesa. Isso deve incluir a implementação de procedimentos de teste e controle tanto para seu próprio código quanto para o código-fonte aberto no qual eles dependem. As organizações também devem desenvolver políticas internas e diretrizes que reconheçam os riscos do uso de software de código aberto e identifiquem os controles a serem usados para gerenciar esse risco. Isso permitirá que eles continuem aproveitando os benefícios do código-fonte aberto, ao mesmo tempo em que criam um ambiente resiliente contra ataques futuros.
FONTE: DARK READING