Regra de e-mail em Ruby removida do Snyk Code

O Snyk Code oferece suporte a várias linguagens importantes no universo cloud native, incluindo Ruby (e vimos uma ótima adoção — muito obrigado!). Nossos pesquisadores monitoram constantemente nossos conjuntos de regras, usando nosso conjunto de treinamento de projetos de código aberto e também — sim, essa é uma vantagem de um serviço SaaS — observando o desempenho das regras no código analisado. Só para lembrar: o Snyk não usa seu código para treinar nossos conjuntos — mas agrega estatísticas de uso.

Nos dados de Ruby, encontramos um caso fora da curva (sobre o qual também recebemos comentários de usuários):

Descobertas de regras de HardcodedEmail relativas às demais.

Por que removemos a regra HardcodedEmail para Ruby

Tínhamos uma regra que procurava endereços de e-mail no código Ruby e os sinalizava como possíveis problemas de baixa prioridade. Embora ainda seja uma boa prática não armazenar e-mails codificados diretamente no código, percebemos que essa regra gerava problemas que muitas vezes eram ignorados ou não resolvidos. Analisamos os números mais a fundo e constatamos que o ruído gerado não tinha relação alguma com o uso das recomendações. Por isso, decidimos remover a regra. Temos outras regras que usam fluxo de dados para encontrar credenciais ou senhas usadas indevidamente, então continuamos bem cobertos nesse aspecto.

O que isso significa para você? Se você usa Ruby, em breve verá uma redução nos resultados de baixa prioridade relacionados a endereços de e-mail.

Qual é a principal lição além da regra para Ruby?

Toda ferramenta de teste de segurança de aplicações estático (SAST) — e, de forma mais geral, toda ferramenta de análise estática de código — precisa equilibrar precisão (identificar apenas problemas realmente positivos, mas, com isso, deixar alguns passar) e abrangência (identificar qualquer problema possível, mas gerar muito ruído com falsos positivos). Graças à velocidade do Snyk Code, podemos usar de 120 mil a 150 mil projetos por linguagem como conjunto de teste, o que ajuda a manter esse equilíbrio entre precisão e abrangência.

Além disso, temos dados de uso do app Snyk. Com eles, começamos a otimizar o sistema e seguimos aprimorando-o. Há vários motivos para isso:

• O ambiente está em constante mudança: JavaScript é famoso por ter uma nova biblioteca da moda a cada duas semanas. Mas, brincadeiras à parte, todos os ecossistemas de linguagens adicionam novas bibliotecas ou alteram as existentes o tempo todo. Usamos machine learning para aprender essas mudanças automaticamente e incorporá-las à nossa base de conhecimento.

• Algumas boas práticas não são realmente adotadas: Embora seja uma boa prática não incluir e-mails codificados diretamente no código, precisamos reconhecer que a realidade pode ser diferente e que há bons motivos para não seguir essa recomendação.

• Novos tipos de problemas surgem: Lembra do Trojan Source? Era um tipo de problema totalmente novo, que nunca havíamos visto antes. Em poucos dias, a equipe do Snyk Code já estava pronta para oferecer regras para detectá-lo — em todas as linguagens de programação com suporte, com alta precisão nos resultados.

Agradecemos seu feedback e suas sugestões para melhorar o produto. Além das decisões baseadas em dados, elas são uma fonte valiosa de informações para nós. Nós ouvimos e agimos. Se você ainda não usa o Snyk Code, talvez este seja um bom momento para começar. Basta criar uma conta gratuita da Snyk e obter resultados em segundos.

Use gratuitamente nossa ferramenta verificadora de código Ruby para ver como o Snyk Code analisa seu código em busca de problemas de segurança e qualidade.