Comparação de velocidade de ferramentas SAST: Snyk Code vs. SonarQube e LGTM

Recebemos pedidos para comparar os tempos de varredura do Snyk Code com os de duas ferramentas SAST populares: LGTM e SonarQube. Para nossa pesquisa, fizemos algumas suposições, mas compartilhamos os detalhes para garantir a transparência.

Resumo

O Teste estático de segurança de aplicações (SAST) só é compatível com o trabalho dos desenvolvedores quando oferece feedback quase em tempo real e não atrasa os processos de desenvolvimento. O Snyk Code é até 106 vezes mais rápido que o LGTM. Em média, o Snyk Code é 5 vezes mais rápido que o SonarQube e 14 vezes mais rápido que o LGTM. Em resumo, o Snyk Code é um dos mecanismos de varredura semântica mais rápidos do mercado.

Cenário de teste

Selecionamos 48 repositórios JavaScript de código aberto (listados abaixo). A ideia era reproduzir conjuntos de código comuns no desenvolvimento moderno, e JavaScript pareceu um denominador comum adequado. Escolhemos uma amostra aleatória de repositórios bem avaliados no GitHub para representar desafios do mundo real.

Como scanners, usamos a Community Edition do SonarQube, uma ferramenta de análise estática de código aberto amplamente utilizada. Ela é executada localmente, então precisamos de um computador razoavelmente potente. Como testes anteriores com a edição gratuita do SonarCloud mostraram que o SonarQube é mais rápido em um bom computador, não é injusto usar o mecanismo local em vez da versão na nuvem. Precisamos usar uma das máquinas de desenvolvimento disponíveis (detalhes abaixo). O segundo concorrente é o LGTM, criado pela empresa Semmle, adquirida pelo GitHub. O LGTM usa pesquisa semântica profunda de código baseada no CodeQL. Usamos a oferta SaaS do LGTM.

Por fim, o Snyk Code é a solução SAST da Snyk. Ele é baseado no antigo mecanismo de varredura DeepCode, que já passou por vários meses de desenvolvimento adicional na Snyk. Além de ser fácil de usar para desenvolvedores e altamente preciso, um dos objetivos de design do Snyk Code é ser extremamente rápido. Para isso, ele usa um mecanismo proprietário de restrições. Escolhemos essas ferramentas porque (1) as licenças permitem que sejam executadas e comparadas; (2) são mecanismos semânticos, não linters (como o ESLint); (3) são ferramentas comuns e amplamente utilizadas; e (4) temos no teste tanto uma ferramenta executada localmente quanto uma SaaS.

A velocidade é essencial para que uma solução SAST seja fácil de usar pelos desenvolvedores. É amplamente reconhecido que os desenvolvedores são mais eficientes quando os problemas de segurança são identificados durante o desenvolvimento, para que possam ser resolvidos antes de o código ser enviado. O código ainda está fresco na memória. O Snyk Code oferece plugins para IDE que se integram perfeitamente ao fluxo de trabalho dos desenvolvedores. Além disso, apresenta diagramas de fluxo de dados fáceis de entender e explicações detalhadas, com exemplos de correções usadas em bibliotecas de código aberto no mesmo contexto. Mas, para este teste, nosso foco foi a velocidade.

Para realizar o teste, executamos uma varredura em cada repositório: SonarQube localmente, e LGTM e Snyk Code como serviços SaaS. Como mencionado acima, isso influenciou a escolha dos repositórios, pois não queríamos que os tempos de varredura dependessem da largura de banda da rede.

Também escolhemos repositórios de código aberto usados no mundo real, em vez de benchmarks, pois o objetivo era simular o que os desenvolvedores fazem de verdade. Comparar ferramentas SAST usando benchmarks tem seus próprios problemas e, neste caso, não ajudaria no nosso objetivo.

Resultados do teste

Abaixo estão os valores estatísticos gerais (arredondados) do tempo de varredura, em segundos. (n=48, arredondado para o inteiro mais próximo):

Veja os resultados em um gráfico de dispersão (quanto menor, melhor; escala logarítmica; feito com R e ggplot2):

O eixo logarítmico exagera a dispersão na faixa inferior. Na realidade, o desvio padrão do Snyk Code é muito menor que o do SonarQube, por exemplo.

Abaixo está um gráfico de caixa dos valores (quanto menor, melhor; usamos uma escala logarítmica para incluir todos os valores no gráfico; feito com R e ggplot2; mediana e média indicadas):

O gráfico mostra claramente que, na maioria dos casos, o Snyk é muito mais rápido que qualquer uma das outras duas ferramentas. A mediana do Snyk é de 6,7 vezes (SonarQube) a 16,4 vezes (LGTM) mais rápida, o que mostra que os resultados não dependem de alguns valores atípicos excepcionalmente bons, mas refletem uma tendência geral.

No diagrama acima, chama atenção a dispersão dos valores na coluna do LGTM. Os tempos variam de cerca de 2 minutos (razoável) a mais de 17 minutos (inaceitável). Os desenvolvedores não vão esperar vários minutos pelos resultados durante o expediente. Felizmente, a mediana do LGTM é de cerca de 3 minutos.

Ao comparar com nosso primeiro teste de velocidade (na época, como DeepCode; agora, Snyk Code), notamos uma grande melhoria de desempenho, pois otimizamos significativamente o carregamento no serviço de nuvem nos últimos meses. Desta vez, o SonarQube também foi mais rápido, provavelmente porque usamos um computador mais potente, com maior capacidade de paralelismo que no primeiro teste.

Outra observação interessante é que, do ponto de vista da velocidade, os mecanismos SaaS e os instalados localmente não são tão diferentes.

Suposições e limitações

• Escolhemos o SonarQube (Community Edition 8.9.1) e o LGTM porque as licenças permitem essas comparações e porque são ferramentas amplamente utilizadas.

• Escolhemos 48 repositórios JavaScript de médio porte, pois esse cenário de teste parece refletir o trabalho típico dos desenvolvedores. A amostra foi selecionada aleatoriamente entre os cerca de 200 mil repositórios mais populares do GitHub, classificados por estrelas. O tamanho do código não foi um critério.

• Forçamos uma varredura completa e não usamos um mecanismo de varredura diferencial. Por exemplo, no caso do Snyk Code em plugins de IDE, após a varredura inicial, o plugin faz varreduras diferenciais e economiza largura de banda.

• Usamos um Intel Xeon a 2 GHz, com 16 núcleos e 64 GB de RAM.

Dados brutos

Também queremos disponibilizar os dados brutos para que você possa aplicar suas próprias análises estatísticas. (Tempos em segundos)