0
0
Noventa e nove por cento das bases de código corporativas contêm componentes de código aberto, de acordo com um estudorecente. Mas em meio a essa adoção avassaladora, surgiu um risco: as organizações perderam a visibilidade da infinidade de componentes de código aberto que estão sendo usados em suas aplicações e infraestrutura, tornando mais difícil identificar potenciais vulnerabilidades de segurança.
A mesma coisa que torna o código aberto tão poderoso — uma comunidade mundial de milhões de desenvolvedores constantemente produzindo novas ferramentas para promover a eficiência e a inovação — também apresenta seu maior teste de segurança. Com tantos subcomponentes sendo usados em todos os aplicativos, o cenário de risco tornou-se muito fragmentado para as equipes de segurança monitorarem adequadamente os buracos que os ciberataques podem explorar.
Cinquenta e sete por cento dos entrevistados de uma pesquisa do Gartner classificaram as vulnerabilidades de segurança como um grande desafio ao trabalhar com código aberto, o que mostra que os benefícios de custo, flexibilidade e conveniência do código aberto vêm com certos riscos que precisam ser enfrentados.
Era mais fácil para as organizações entender e controlar seu uso de software de código aberto há 10 ou 20 anos, quando um grupo menor de fornecedores comerciais de código aberto licenciava seu software para os clientes, entendia tudo sobre o código e lidava com patches de segurança.
Agora, no entanto, os desenvolvedores se baseiam em uma enorme variedade de projetos menores que encontram no GitHub ou compartilham uns com os outros. Isso, afinal, é a coisa bonita sobre o código aberto — os desenvolvedores não precisam mais lutar com ferramentas ruins ou reinventar rodas de software quando podem facilmente se beneficiar das contribuições disponíveis livremente da comunidade para enfrentar praticamente qualquer necessidade de desenvolvimento.
Quando o fazem, no entanto, raramente examinam o que está sob o capô — o código fonte e suas dependências (os outros componentes com os quais a ferramenta foi montada e devem ser usados para funcionar).
Eles podem realmente confiar no código? Será que o partido que o criou está pronto para identificar e divulgar alguma falha de segurança? Há alguém para contatar? Um único aplicativo pode ter 10 tempos de execução e 100 outros pacotes. Como você pode estar confiante de que todos estão atualizados do ponto de vista da segurança?
Essa fragmentação é a ameaça de segurança de código aberto nº 1 para as empresas, e pode ajudar a explicar por que as Vulnerabilidades e Exposições Comuns (CVEs) em software de código aberto mais do que dobraram entre 2018 e 2019, de 421 para 968, de acordo com um relatório da empresa de segurança da informação RiskSense.
Como o COVID-19 traz uma variedade de mudanças que afetam a infraestrutura de TI e levanta novas preocupações com a segurança cibernética, tornou-se mais importante do que nunca que as organizações reconheçam a necessidade de melhores práticas de segurança em suas empresas.
Aqui estão três passos essenciais que toda empresa deve seguir.
Passo 1: Rastreie componentes de código aberto que estão sendo usados
na fabricação, uma nota de materiais é um inventário centralizado e abrangente de todos os materiais e peças necessários para fazer um produto. Se for constatado que se encontra defeituoso, o fabricante pode identificar o impacto imediatamente.
Ao adotar uma abordagem semelhante, as empresas podem ganhar nova visibilidade sobre a desordem de componentes de código aberto que seus desenvolvedores estão usando. Como resultado, eles podem assumir o controle de garantir que seus componentes de código aberto sejam seguros em vez de depender de informações da comunidade que muitas vezes são escassas ou difíceis de encontrar. Este inventário, que inclui todas as dependências usadas por diferentes aplicativos, pode ser compilado manualmente ou com uma ferramenta de detecção automatizada.
Passo 2: Pare de enfatizar agilidade sobre segurança
Para se manter competitiva, todas as empresas hoje sentem pressão para implantar novos aplicativos rapidamente. Mas isso nunca deve vir ao custo da segurança. É por isso que toda organização deve adotar o DevSecOps, que aplica melhor higiene à entrega de aplicativos, introduzindo segurança no início do ciclo de vida do aplicativo e exigindo testes de segurança e verificação a cada etapa.
Passo 3: Vá com Proxies confiáveis Sempre que possíveis
editores linux, como o Canonical for Ubuntu, têm um programa abrangente para revisar, priorizar e corrigir seus pacotes de software para vulnerabilidades. Embora nem todos os aplicativos de código aberto possam ser cobertos por padrão, vale a pena verificar quais pacotes e versões de código aberto podem se beneficiar de patches de segurança. Os editores do OS mantêm seu próprio banco de dados para rastrear a remediação das vulnerabilidades públicas mais recentes de várias fontes, incluindo MITRE, NIST NVD,entre outras. Esses são os tipos de qualidades que fazem um provedor de código aberto confiável, e as empresas seriam inteligentes em considerá-las como parte de suas decisões de código aberto.
Seguindo essas três etapas, as empresas podem garantir que a fragmentação em seu software de código aberto não signifique segurança comprometida.
FONTE: DARK READING