Por que as organizações confiam na Snyk para vencer a batalha pela segurança do código aberto?

Definir e explicar o papel de uma equipe de segurança própria, dedicada a pesquisar e analisar vulnerabilidades em ecossistemas de código aberto para garantir a segurança desse universo, não é uma tarefa fácil. É difícil dar uma resposta concisa quando alguém faz a pergunta relativamente simples: “O que a equipe de segurança da Snyk faz?”. Não há uma resposta curta que explique exatamente o que fazemos e como somos especialistas na nossa área.

Acredito que o problema esteja no fato de que “pesquisador” e “analista”, em geral, e “analista de segurança” ou “pesquisador de segurança”, especificamente, estão entre os títulos mais banalizados e usados em excesso desde “consultor”. Eles podem significar literalmente qualquer coisa, e cada empresa parece ter uma definição totalmente diferente do que faz sua equipe de pesquisa de segurança — quando ela sequer existe.

Provavelmente não vou conseguir resolver por completo o problema de explicar às pessoas que conheço fora do trabalho o que faço. Mas este blog é, pelo menos, uma tentativa de minimizar essa questão e explicar de uma vez por todas o que a incrível equipe de pesquisa de segurança da Snyk faz.

Veja o que vamos abordar neste artigo:

• Nossa missão

• Nossos métodos

  • Bancos de dados estruturados de comunidades de ecossistemas

  • Bancos de dados não estruturados e alertas de segurança

  • Descoberta de vulnerabilidades ainda não publicadas

  • Divulgações de comunidades e do meio acadêmico

  • Pesquisa própria e análise de tendências de vulnerabilidades

• Resumo

Nossa missão

A missão da Snyk é tornar o mundo do código aberto mais seguro e ajudar a capacitar desenvolvedores a assumir um papel ativo na proteção de suas bases de código. Uma das principais formas de fazer isso é analisar as bibliotecas de código aberto gerenciadas e as imagens de contêiner dos nossos usuários em busca de vulnerabilidades e fornecer as informações mais precisas e práticas possíveis sobre os problemas encontrados, além de oferecer opções para corrigi-los.

O papel da equipe de pesquisa de segurança na empresa é reunir e manter o banco de dados de vulnerabilidades Snyk Intel, que alimenta nossas análises e fornece essas informações aos usuários para que possam corrigir as vulnerabilidades antes que elas se tornem ameaças à segurança.

Criar — e manter — um banco de dados de segurança de alto nível é um trabalho difícil. É preciso se empenhar não só para garantir a precisão dos dados, mas também a abrangência e a profundidade do banco. Provavelmente, a melhor forma de explicar exatamente como fazemos isso é mostrar como identificamos, verificamos e priorizamos as vulnerabilidades para incluir no banco de dados.

Nossos métodos

Usamos vários métodos para acompanhar continuamente os problemas de segurança no código aberto:

1. Bancos de dados estruturados de comunidades de ecossistemas

As fontes mais óbvias de vulnerabilidades em ecossistemas de código aberto são os bancos de dados mantidos pelas comunidades, como rubysec, friends of php, rustsec e muitos outros. Esses bancos são organizados por desenvolvedores de código aberto que atuam nos respectivos ecossistemas e buscam dar o máximo de visibilidade possível aos problemas de segurança que encontram neles.

A equipe de pesquisa de segurança da Snyk acompanha ativamente esses bancos de dados mantidos pelas comunidades para ficar por dentro das vulnerabilidades divulgadas por elas. No entanto, apesar do excelente trabalho das comunidades para informar os usuários dos ecossistemas sobre essas vulnerabilidades, muitas vezes ainda é preciso fazer um trabalho complementar.

A equipe de pesquisa de segurança verifica e analisa cada vulnerabilidade divulgada para:

1. confirmar que se trata mesmo de uma vulnerabilidade — isso inclui investigar o problema divulgado e, se necessário, criar provas de conceito para verificar se ele pode ser explorado.

2. elaborar uma descrição completa e precisa da vulnerabilidade, incluindo a gravidade e a pontuação CVSS — ao investigar a fundo a vulnerabilidade, conseguimos entender melhor seus possíveis impactos e vetores de ataque, além dos prováveis usos do pacote vulnerável no ecossistema. Com base nisso, elaboramos uma descrição e um alerta de gravidade para que os desenvolvedores entendam melhor a vulnerabilidade e como ela pode afetar suas bases de código.

3. verificar se os dados de metadados importantes, como as versões corrigidas e os pacotes afetados, estão completos e corretos — investigamos a base de código do pacote para identificar as alterações exatas que introduziram e corrigiram a vulnerabilidade. Em seguida, cruzamos essas informações com os nomes e as versões precisos dos pacotes para garantir que identificamos somente os pacotes e as versões vulneráveis.

4. identificar as funções ou classes vulneráveis em um pacote — durante a triagem da vulnerabilidade, procuramos identificar exatamente quais funções do pacote são vulneráveis. Esses metadados permitem que os desenvolvedores saibam se o uso específico que fazem do pacote está vulnerável.

5. monitorar e priorizar explorações dessa vulnerabilidade divulgadas em ataques reais — mesmo depois da publicação de uma vulnerabilidade, é preciso acompanhar a divulgação de novas informações, especialmente se for publicado um método de exploração bem desenvolvido. Monitoramos diversas fontes para identificar explorações assim que são publicadas e avaliamos seu nível de maturidade para que os desenvolvedores saibam como priorizar a correção dessas vulnerabilidades.

2. Bancos de dados não estruturados e alertas de segurança

É ótimo contar com bancos de dados estruturados nos ecossistemas, mas também há uma grande quantidade de informações sobre novas vulnerabilidades em bancos não estruturados e alertas públicos. Por isso, é fundamental acompanhar e priorizar esse tipo de fonte.

Os bancos de dados CVE e NVD são os exemplos mais óbvios: eles registram muitas vulnerabilidades em formatos não estruturados e que não podem ser lidos por máquinas. Além do CVE e do NVD, há inúmeros alertas de produtos e listas de discussão, como a lista de discussão do Apache, os blogs de atualização do Node.JS, os alertas de segurança do Jenkins e muitos outros, que também exigem nossa atenção.

A equipe também precisa aplicar aqui todo o trabalho descrito na seção anterior, mas é igualmente necessário organizar os dados em um formato legível por máquinas e pessoas. Por exemplo, o NVD ou a lista de discussão do Apache podem informar que uma vulnerabilidade afeta o “Apache Tomcat”. Mas os desenvolvedores precisam saber se, entre os 958 pacotes relacionados ao “Apache Tomcat” disponíveis atualmente no Maven, o pacote específico que eles usam está vulnerável.

Com uma pesquisa aprofundada da base de código vulnerável, a equipe consegue identificar os parâmetros do código afetado. Em seguida, usamos nossas ferramentas internas para analisar os pacotes provavelmente relacionados à vulnerabilidade e verificar se eles contêm o código vulnerável. Só depois de confirmar que esse código está presente e é relevante atribuímos a vulnerabilidade a um pacote específico. Esse trabalho reduz bastante a quantidade de falsos positivos no nosso banco de dados e permite que os desenvolvedores que usam a Snyk se concentrem em corrigir vulnerabilidades, em vez de lidar com ruído.

3. Descoberta de vulnerabilidades ainda não publicadas

Até aqui, descrevi principalmente como a equipe ajuda a priorizar vulnerabilidades conhecidas e tornar as informações sobre elas mais úteis para os desenvolvedores, algo que por si só já é essencial. Mas a equipe também contribui para reforçar a segurança dos ecossistemas de código aberto ao identificar vulnerabilidades que ainda não foram divulgadas.

Em parceria com nossa equipe de dados, desenvolvemos vários algoritmos de aprendizado de máquina para ajudar a encontrar o que chamamos de vulnerabilidades “de meio período”. São vulnerabilidades que talvez estejam sendo discutidas em fóruns públicos, mas que ainda não foram divulgadas oficialmente.

É sabido que essas vulnerabilidades costumam ser as mais perigosas. O período entre o início das discussões sobre uma vulnerabilidade e o momento em que ela é reconhecida, permitindo que o público tome medidas para corrigi-la, cria uma janela na qual agentes mal-intencionados podem tirar proveito desse conhecimento antecipado.

Ajudamos a fechar essa lacuna: identificamos vulnerabilidades recém-descobertas e alertamos os usuários logo no início de seu ciclo de vida. Para isso, monitoramos fontes onde correções de código, relatos de bugs e possíveis vulnerabilidades costumam ser discutidos em estágios preliminares, como PRs e issues em sistemas de controle de versão, chamados no JIRA e sites como Reddit e StackOverflow.

Contamos com um amplo conjunto de recursos para alimentar nossos modelos de aprendizado de máquina, incluindo um banco de dados preexistente, cuidadosamente organizado por nossa equipe, com trechos de código vulnerável, relatos de bugs e descrições de vulnerabilidades. Assim, nossos sistemas conseguem processar milhares de eventos em todos os pacotes dos ecossistemas que apoiamos e alertar a equipe sobre possíveis vulnerabilidades. Acreditamos ter criado o feed de alertas mais abrangente disponível atualmente.

Esses alertas são enviados ao sistema de alerta antecipado da equipe e, em seguida, passam por triagem. Um analista avalia as informações do alerta e, se necessário, verifica a vulnerabilidade por meio de uma prova de conceito. Depois, entra em contato com os responsáveis pela manutenção do pacote para ouvir o que sabem sobre a possível vulnerabilidade.

Após conversar com os responsáveis pela manutenção e verificar a vulnerabilidade, publicamos as informações no nosso banco de dados para alertar todo o ecossistema sobre o problema de segurança e permitir que ele seja corrigido. Só no último ano, ajudamos a divulgar cerca de 200 vulnerabilidades dessa forma, incluindo a injeção de comandos no Vizion e o ataque de temporização que afeta os populares pacotes Escada e Elliptic.

4. Divulgações de comunidades e do meio acadêmico

A divulgação responsável de vulnerabilidades é um modelo comum no mundo da cibersegurança. Nele, vulnerabilidades de dia zero são divulgadas primeiro em caráter privado, dando tempo suficiente para que os responsáveis pela manutenção do código e dos aplicativos lancem uma correção ou um patch antes da divulgação pública da vulnerabilidade. Caso contrário, colocaríamos em risco a segurança dos usuários finais. Como sempre, o equilíbrio é fundamental: o objetivo é reduzir tanto o tempo em que a vulnerabilidade permanece privada quanto o período em que o aplicativo fica vulnerável sem uma correção.

A Snyk lançou seu programa de divulgação de vulnerabilidades em 2019 para ajudar a preencher essa lacuna e facilitar a tarefa de pesquisadores que desejam relatar vulnerabilidades, reconhecendo devidamente o trabalho de quem as descobriu.

Nossa equipe de segurança analisa cuidadosamente todos os relatos de vulnerabilidade. Esse trabalho exige conhecimento específico e compreensão da linguagem de programação em questão, do pacote e do contexto. Depois de verificar os detalhes da vulnerabilidade, a equipe trabalha lado a lado com os responsáveis pela manutenção para corrigi-la o quanto antes.

Por fim, como autoridade de numeração de CVEs (CNA), ajudamos a atribuir um ID CVE ao problema e a publicar um alerta detalhado. Em 2019, ajudamos a divulgar mais de 130 vulnerabilidades. Entre os exemplos mais notáveis estão a execução remota de código no mongo-express e a gravação arbitrária de arquivos no yarn.

Trabalhamos com pesquisadores independentes, profissionais de segurança e a comunidade acadêmica para divulgar vulnerabilidades. Pesquisadores individuais usam nosso programa de divulgação para reportar uma ou, às vezes, várias vulnerabilidades que afetam pacotes. Já pesquisadores acadêmicos que descobrem novos tipos de vulnerabilidade entram em contato com a Snyk para usar nosso programa na divulgação em larga escala de várias vulnerabilidades em todo o ecossistema. Começamos 2020 com uma grande parceria com a equipe do Security Lab da Johns Hopkins University, ajudando a divulgar mais de 60 vulnerabilidades — e esse número continua crescendo. Entre os exemplos de destaque estão CVE-2019-10795 no undefsafe e CVE-2019-10777 no aws-lambda.

5. Pesquisa proprietária e análise de tendências de vulnerabilidades

A última peça desse quebra-cabeça da segurança é nossa pesquisa proprietária interna, que busca descobrir e divulgar de forma responsável novas vulnerabilidades no ecossistema de código aberto. Na Snyk, consideramos fundamental descobrir e divulgar novas vulnerabilidades com responsabilidade para manter o ecossistema seguro, e usamos nosso banco de dados de vulnerabilidades conhecidas para isso. Ao analisar as tendências de vulnerabilidades em uma linguagem específica ou em várias linguagens, identificamos características importantes de vulnerabilidades que provavelmente serão comuns no ecossistema.

Em outras palavras, se observamos uma determinada vulnerabilidade aparecer em vários pacotes diferentes do ecossistema — todos com vetores de ataque semelhantes —, sabemos que provavelmente há outras vulnerabilidades ainda não descobertas. Além disso, sabemos que outros agentes, possivelmente mais mal-intencionados, podem estar cientes dessa possibilidade e buscando tirar proveito dela.

Por isso, a Snyk usa seus recursos de pesquisa de forma criteriosa e eficiente para descobrir novos tipos de vulnerabilidade em larga escala, como o zip-slip, ou encontrar novas ocorrências de tipos de vulnerabilidade em alta em pacotes populares. Para isso, combinamos a análise de grandes volumes de dados para identificar tipos de trechos vulneráveis, padrões de código e outras características semelhantes em pacotes potencialmente vulneráveis com pesquisas sobre diferentes vetores de exploração. Em seguida, nossas ferramentas internas testam esses vetores nos pacotes suspeitos e determinam se eles são realmente vulneráveis.

Depois de descobertas, usamos nosso cronograma e nossa metodologia de divulgação responsável para informar os mantenedores afetados e ajudar a desenvolver uma correção. Só então divulgamos publicamente a vulnerabilidade em nosso banco de dados e atribuímos a ela um CVE.

Resumo

Com todo esse trabalho, nosso produto de segurança alcança quatro objetivos fundamentais:

1. Agilidade — as informações sobre vulnerabilidades e exploits chegam aos usuários a tempo de agir, com alertas sobre vulnerabilidades muitas vezes antes que elas se tornem amplamente conhecidas e possam ser exploradas por agentes mal-intencionados.

2. Completude — os usuários podem ficar tranquilos sabendo que têm uma visão completa das vulnerabilidades e não precisam se preocupar com outras falhas potencialmente exploráveis escondidas na base de código.

3. Precisão — os dados fornecidos são precisos, evitando o ruído e os falsos positivos tão indesejados em uma análise de segurança.

4. Praticidade — os dados ajudam os desenvolvedores a avaliar rapidamente as vulnerabilidades que os afetam e priorizar o trabalho de acordo.

Juntos, esses quatro objetivos permitem que quem usa a Snyk saiba que, apesar da interminável selva de vulnerabilidades nos ecossistemas de código aberto, conta com uma equipe dedicada de especialistas em segurança, pronta para entrar em ação e fornecer todas as informações necessárias para manter sua segurança — e a de todo o ecossistema de código aberto.

Encontre vulnerabilidades no seu código — crie uma conta gratuita na Snyk.