Ao longo dos últimos anos as empresas têm vindo a aumentar a sua utilização de código-fonte aberto para ajudá-los a construir aplicações mais poderosas mais rápido.
Os componentes de código aberto reduzem o tempo de desenvolvimento de aplicativos, fornecendo recursos poderosos que os desenvolvedores não precisam escrever por conta própria, acelerando a implantação de novos lançamentos. Formando a espinha dorsal do software de hoje, componentes de código aberto agora compreendem entre 60-80% de aplicações modernas.
Bibliotecas e ferramentas de código aberto – uma responsabilidade para com a segurança
As equipes de desenvolvimento podem aproveitar facilmente as diferentes bibliotecas e ferramentas de código aberto, que são atualizados e fornecidos pela comunidade de código aberto, retirando-os de recursos populares como o GitHub.
Junto com as vantagens claras para desenvolvedores, usando componentes de código aberto não é isento de riscos. Manter seus produtos de software seguros pode ser um desafio e requer as ferramentas certas para lidar com as ameaças. No caso de componentes de código aberto, em oposição ao código proprietário que é escrito internamente por uma empresa, o principal risco para produtos que usam software de código aberto são vulnerabilidades conhecidas. Essas são vulnerabilidades que foram publicadas online e estão disponíveis para qualquer pessoa ver e possivelmente usar para explorar as vítimas. O problema de usar componentes com vulnerabilidades conhecidas provavelmente já está no seu radar, tendo mantido um lugar no infame Top do OWASP 10 Desde a 2013.
Como software de terceiros, componentes de código aberto podem ser usados em milhares de produtos, e uma vulnerabilidade encontrada em um único componente pode ter um impacto em uma ampla gama de aplicativos. Porque os componentes de código aberto são mantidos pela comunidade de código aberto, dependemos deles para nos alertar sobre novas vulnerabilidades quando esses pesquisadores de segurança as encontrarem.
Na tentativa de manter os outros seguros, esses pesquisadores postarão suas descobertas sobre quais componentes de código aberto são vulneráveis e como executar as explorações para alertas de segurança e bancos de dados como os. Banco de dados de vulnerabilidade nacional apoiado pelo governo (NVD). Embora isso possa ser útil para equipes de segurança vigilantes, que podem usar essas informações para corrigir rapidamente seus aplicativos, os hackers também estão observando aqui para obter informações gratuitas sobre o que visar e como.
O desafio aqui é ficar um passo à frente dos atacantes. Infelizmente, a grande maioria das equipes de desenvolvimento simplesmente não tem conhecimento de quanto seus produtos dependem de componentes de código aberto, e não mantêm um estoque adequado de quais eles têm em seus produtos. Isso pode ser um problema significativo, pois eles podem ser alvos de um componente vulnerável que eles nem sabiam que estavam usando.
Foi o que aconteceu no caso Equifax em setembro passado, quando a empresa foi violada por meio de uma versão vulnerável do Apache Struts 2 (CVE-2017-5638), levando ao roubo de 145.9 milhões de registros de informações de identificação pessoal, incluindo segurança social e números de cartão de crédito. De acordo com relatórios, o ataque ocorreu dois meses depois que a vulnerabilidade foi divulgada, envergonhar a empresa por não tomar as medidas necessárias para manter seus dados seguros.
Automação é crítica para proteger componentes de código aberto
Devido em parte ao rápido ritmo de desenvolvimento, e forte dependência de componentes de código aberto para se manter dentro do cronograma, rastreamento manual de componentes de código aberto simplesmente não é uma opção para organizações que desejam permanecer seguras.
Escalabilidade é a chave, e apenas soluções automatizadas oferecem uma resposta sobre como ficar por dentro de cada componente de código aberto que entra no ambiente de desenvolvimento. Apenas Análise de Composição de Software (SCA) ferramentas são capazes de identificar componentes de código aberto e alertar as equipes de segurança sobre os riscos.
Para implementar adequadamente um processo de segurança de código aberto, especialmente em um modelo DevOps, as equipes de segurança e desenvolvimento precisam trabalhar juntas para detectar problemas o quanto antes, adotando uma abordagem de deslocamento para a esquerda. Quando eles integram uma ferramenta SCA em seu servidor CI / CD, as ferramentas podem identificar componentes vulneráveis antes que eles entrem na construção, evitando operações mais caras posteriormente, quando os desenvolvedores teriam que rasgar e substituir o componente vulnerável antes de um lançamento.
Ao mesmo tempo, é essencial mudar para a direita com alertas quando novas vulnerabilidades são descobertas, dando às equipes de segurança o aviso de que precisam para corrigir rapidamente seus produtos antes que os hackers tentem fazer sua violação.
Implementando um contínuo, ferramenta SCA automatizada, as organizações podem aplicar políticas em todo o seu desenvolvimento e produtos, mitigando significativamente os riscos de vulnerabilidades conhecidas em seu uso de componentes de código aberto.
Sobre o autor: Zev Brodsky
Por dia, Zev é o Community Manager da WhiteSource, líder em gerenciamento de segurança de código aberto. À noite, ele é um entusiasta de taco, jogador de damas mais ou menos, e colecionador de selos raros.
