3 parâmetros para medir testes SAST

Em nosso blog anterior sobre por que não dá para comparar ferramentas SAST usando apenas listas, suítes de testes e benchmarks, exploramos as ferramentas e métricas mais usadas atualmente para avaliar e comparar ferramentas de testes SAST. Também vimos alguns motivos pelos quais essas ferramentas podem apresentar resultados inconsistentes e não ser confiáveis para avaliar uma ferramenta de testes SAST.

Em vez disso, ao avaliar uma ferramenta de testes SAST, você deve considerar 3 parâmetros:

• precisão

• completude

• outros diferenciais exclusivos

Neste blog, vamos explorar esses parâmetros e ver como medi-los. Ao avaliar uma ferramenta de testes SAST, há dois tipos de métricas relevantes: quantitativas (o número de resultados em relação ao “ruído”) e qualitativas (especialmente a profundidade e o suporte a linguagens).

Aspectos quantitativos

As definições de precisão e completude a seguir podem parecer um pouco complexas à primeira vista, porque, na verdade, são dois lados da mesma moeda. É matematicamente impossível (segundo o Teorema de Rice) realizar uma análise estática perfeita de programas. Pode parecer que aumentar o número de sugestões ajudaria a encontrar todos os problemas possíveis. Infelizmente, isso também aumenta o número de falsos positivos (FPs) a ponto de o ruído tornar os resultados impossíveis de usar. Os fornecedores de ferramentas de testes SAST podem recorrer a alguns artifícios para melhorar os resultados, mas a perfeição é matematicamente impossível.

Precisão

No contexto dos testes SAST, a precisão é definida, de forma geral, como a obtenção do maior número possível de VPs (verdadeiros positivos, ou seja, achados que são problemas reais), mantendo o menor número possível de FPs (achados que não são vulnerabilidades e, portanto, estão incorretos).

A precisão é especialmente importante. Uma alta taxa de precisão significa mais resultados úteis e menos “ruído” (relatórios irrelevantes e sem ações práticas). O “ruído” também é o principal fator que desestimula os desenvolvedores a usar produtos de testes SAST. Por isso, quanto maior a precisão, melhor será a experiência geral dos desenvolvedores.

Para calcular a precisão, primeiro você precisa fazer a triagem dos resultados. A fórmula é TP*100/(TP+FP). O resultado será um número entre 1 e 100. Quanto maior o número, maior a precisão. Por exemplo, uma ferramenta que encontra 140 VPs e 40 FPs teria uma taxa de precisão de 77,7%.

Completude

O NIST define: “Completude, às vezes chamada de taxa de revocação, é uma medida dos problemas reais encontrados (VPs) em relação a todos os problemas possíveis (VPs e falsos negativos). Quanto maior a completude (até o máximo teórico de 1), melhor a ferramenta cobre os problemas existentes no código.” Em termos práticos: a quantidade de problemas reais que não foram detectados, ou seja, os falsos negativos (FNs).

Quanto mais completa for a ferramenta, melhor será sua visibilidade e proteção. Isso também pode resultar em mais achados, é claro, mas, com uma alta taxa de precisão, a maioria deles deve ser relevante. Ainda assim, a gravidade desses achados sempre tem um papel importante na completude: mil FNs de baixa gravidade não são necessariamente um problema se você está tentando minimizar o ruído. Como regra geral, quanto menos FNs, melhor. E é importante saber como eliminá-los para evitar que vulnerabilidades reais passem despercebidas.

Só é possível gerar essa métrica se você souber da existência de vulnerabilidades no seu código ou se estiver comparando várias ferramentas e tiver encontrado diferenças nos achados. Outra abordagem é analisar a gravidade dos FNs e priorizar os mais importantes. É difícil medir FNs porque são incógnitas desconhecidas. As compensações são inevitáveis. A experiência mostra que, em projetos não triviais, sempre devemos esperar FNs. Em cibersegurança, baixar a guarda por se sentir seguro demais nunca é uma opção.

O aspecto qualitativo

A avaliação qualitativa analisa como são tratados o suporte a linguagens e a vulnerabilidades. Como vimos no blog anterior, limitar-se a listas de vulnerabilidades conhecidas, suítes de testes e repositórios intencionalmente vulneráveis não oferece uma visão completa. Por isso, uma boa ferramenta SAST vai além das listas.

Essa avaliação pode ser dividida em duas áreas de interesse: suporte a linguagens e vulnerabilidades, e abordagem à profundidade e à precisão.

Como determinar o suporte a linguagens?

É importante entender como as prioridades e o suporte a linguagens da ferramenta SAST que você está avaliando são definidos.

Já sabemos que listas de vulnerabilidades não são suficientes. Uma abordagem mais abrangente seria reunir dados de várias fontes para criar um suporte sólido a linguagens, atualizado em relação aos riscos cibernéticos atuais e relevante para cada contexto.

Assim, embora as listas possam servir de referência, vale explorar outras fontes:

• Fontes de notícias — vulnerabilidades em alta e vetores recém-publicados têm maior probabilidade de serem explorados

• Bancos de dados de vulnerabilidades conhecidas e dados de exploração, como o NVD Database e a Snyk Vulnerability Database.

• Práticas recomendadas e contexto específicos de cada linguagem e framework

• Pesquisas sobre vulnerabilidades zero-day, como novos padrões ou padrões já conhecidos

Para determinar quais linguagens e frameworks terão suporte no Snyk Code, usamos todas as fontes acima e outras para criar uma lista dos problemas mais relevantes para os clientes.

Como avaliar a profundidade e a precisão do suporte a linguagens?

Ter uma lista abrangente de linguagens e vulnerabilidades com suporte é um primeiro passo importante, mas também é preciso considerar até que ponto esse suporte se traduz em resultados.

Por exemplo, uma ferramenta SAST que depende da comunidade open source para criar e disponibilizar novas regras, sem um processo rigoroso de revisão, tende a apresentar muitos FPs e resultados inconsistentes entre diferentes linguagens e vulnerabilidades.

No Snyk Code, temos uma equipe de pesquisadores de segurança dedicada, que trabalha continuamente para ampliar o suporte a linguagens e vulnerabilidades, além de aprimorar o suporte existente com mais profundidade e precisão.

Qual é a velocidade de desenvolvimento e manutenção da ferramenta SAST?

Como vimos acima, a manutenção e o desenvolvimento contínuo de uma solução SAST são importantes. Isso envolve duas áreas: o roadmap do produto e a capacidade da empresa ou comunidade de executá-lo. Os avanços recentes em machine learning tornam interessante entender como essa tecnologia se encaixa no roadmap. Também são importantes o suporte a linguagens modernas, o uso de um mecanismo moderno e a velocidade com que novas linguagens são adicionadas.

Em segundo lugar, é importante entender a capacidade da empresa ou comunidade de manter a base de conhecimento da ferramenta SAST. Como já dissemos, segurança exige monitoramento constante e resposta a diversas fontes.

Juntando tudo

Com a avaliação quantitativa, você pode entender o desempenho real da ferramenta. Ter o melhor suporte a linguagens e vulnerabilidades não basta se a ferramenta gera muitos resultados (mesmo que sejam VPs) ou, por outro lado, muito ruído (FPs). Um profissional de segurança busca um alto nível de completude, mas o desenvolvedor está mais interessado em orientações práticas e concretas. Por isso, é importante equilibrar o número de sugestões, sua priorização e a capacidade da equipe de desenvolvimento de lidar com elas. Nossa experiência e pesquisa mostram que sobrecarregar os desenvolvedores com sugestões (especialmente quando a precisão é baixa) desmotiva a equipe e, na prática, torna o processo mais lento.

Do ponto de vista qualitativo, sugerimos listar os aspectos importantes para o seu ambiente, montar uma matriz e inserir nela os valores de cada concorrente.

Para medir as características quantitativas, sugerimos escolher projetos reais que você conheça bem. Para facilitar, prefira um projeto de pequeno a médio porte. Como mencionamos no blog anterior, evite usar um aplicativo intencionalmente vulnerável, pois é provável que ele não represente o valor real da ferramenta.

Depois de executar a ferramenta SAST e receber os resultados, é hora de fazer a triagem. Isso significa determinar se cada resultado é um VP (um problema real) ou um FP (um problema que não existe). Os resultados SAST muitas vezes dependem do contexto, por isso é importante conhecer bem o projeto que você está analisando. No fim das contas, sua experiência e seu trabalho não podem ser substituídos por resultados prontos de benchmarks.

Por fim, você precisará calcular a precisão e a completude usando as fórmulas mencionadas anteriormente neste post.

Por que não reunir todas as ferramentas e executá-las?

Como vimos acima, todas as ferramentas geram VPs e FPs. Assim, embora pareça fazer sentido usar todas as ferramentas disponíveis, na prática, o trabalho de separar o ruído supera o valor agregado por outra ferramenta. Os desenvolvedores terão que lidar com sugestões duplicadas de diferentes ferramentas e em diferentes formatos, o que gera muito trabalho adicional, além de limitações no tempo de execução. Embora essa seja uma boa maneira de obter números de FNs e FPs, não é viável para operações contínuas. Pela nossa experiência, o mais importante é contar com uma plataforma fácil de usar para os desenvolvedores. Se você trabalha em um ambiente altamente crítico para a segurança ou regulamentado, talvez queira adicionar ferramentas especializadas mais adiante no processo de CI/CD.

Sem dúvida, uma ferramenta SAST é essencial para qualquer desenvolvedor e pode fazer uma grande diferença na segurança das suas aplicações. Por isso, é fundamental escolher a melhor opção para você e sua organização. Esperamos que as informações e etapas deste post e do blog anterior ajudem você a tomar decisões mais acertadas.