Afinal, qual é a diferença entre Code Review e SAST e quando usar cada um deles?
Este é o primeiro de dois artigos onde vamos tratar estes dois tipos de testes, que sempre geram debates e discussões sobre diferentes entendimentos.
Prefere ouvir a nossa versão em áudio deste blog post? Clique no player abaixo:
Neste primeiro artigo vamos tratar mais sobre as ferramentas de análise automatizadas, falando sem seguida sobre as ferramentas de Secure Code Review.
Nosso objetivo é apresentar de forma abrangente o que é cada um desses métodos, e como eles podem ajudar no processo de manter a segurança de uma aplicação.
Vamos a primeira parte do artigo.
Ferramentas Automatizadas de Code Review e SAST
O tema escolhido para este artigo é um dos que mais levanta discussões entre os profissionais de segurança e os desenvolvedores, pelo simples fato de que temos muito forte no mercado uma visão salvadora das ferramentas.
É verdade que não é incomum termos calorosas e empolgantes discussões sobre a real efetividade das ferramentas dentro do SDLC (Software Development Life Cycle).
Mas vamos nos concentrar em alguns dados que possam ajudar a avaliar como as ferramentas devem ser adicionadas ao seu pipeline de desenvolvimento.
Vale ressaltar que aqui não há nenhuma indicação de que se deva parar de usar as ferramentas de Code Review e SAST. Inclusive nós também as usamos. No entanto, um ponto que deve ser observado com cautela é que alguns profissionais acabam considerando a ferramenta como uma solução para os problemas de validação de um código.
Ou seja, fazer o uso das ferramentas como se elas por si só fossem resolver problemas de código é que torna o seu uso um equívoco.
Vamos abordar melhor esse aspecto a seguir.
O que é uma ferramenta de SAST?
Uma ferramenta de SAST (Static Application Security Testing) — ou ferramenta de análise de código — é uma ferramenta que foi criada com o objetivo de analisar o código fonte ou mesmo suas versões compiladas de código, buscando nestes códigos falhas que possam comprometer a segurança.
Com a evolução dessas ferramentas, algumas migraram sua atenção também para o momento do desenvolvimento, criando assim alguns complementos aos IDEs. Isso acabou permitindo uma visão mais próxima do desenvolvedor.
Isso é, sem dúvida, um dos pontos mais fortes das ferramentas: atuar de forma proativa no desenvolvimento, notificando ao desenvolvedor que há algo que pode ser melhorado em seu código.
No entanto, mesmo com este auxílio, se o desenvolvedor não tiver os conhecimentos básicos e o entendimento dos conceitos de desenvolvimento seguro, ele será apenas um observador da ferramenta.
Ferramentas de code review e SAST devem ser entendidas como suporte ao processo de desenvolvimento, e devem ser estrategicamente integradas ao processo de desenvolvimento.
Como o SAST funciona?
Primeiro, não queremos aqui explicar detalhadamente como estas ferramentas funcionam. Nosso objetivo é criar uma base de conhecimento que possa ajudar no entendimento e escolha de suas ferramentas e quando usá-las.
As ferramentas SAST basicamente analisam os códigos das aplicações em um modelo inside out, ou seja, de dentro pra fora, avaliando pontos específicos, como vamos detalhar a seguir.
1. Análise de Controle de Fluxo
A análise de controle de fluxo valida a ordem das operações para buscar por padrões de sequências que possam ser prejudiciais os código.
Podemos citar, como exemplos, falhas de transmissão de cookies, variáveis que não foram iniciadas ou mesmo race conditions.
2. Análise Estrutural
Com base na linguagem que o desenvolvedor está usando, as ferramentas analisam a estrutura do código, tomando como base as melhores práticas para a linguagem. Essa avaliação leva em consideração técnicas e práticas de desenvolvimento seguro.
Essa análise visa, portanto, identificar pontos fracos na criação das classes, nas declarações e no uso de variáveis.
3. Análise Semântica
Essas ferramentas usam como base uma estrutura de análise semântica: uma funcionalidade semelhante ao grep, mas de uma forma bem limitada.
As ferramentas de SAST podem analisar o código buscando por contextos específicos, como por exemplo .executeQuery ().
4. Análise de Configuração
A análise de configuração verifica os arquivos de configuração do aplicativo, como XML ou arquivos de propriedades.
Ela garante que a configuração esteja alinhada às práticas e políticas de segurança, como, por exemplo, definindo uma página de erro padrão para o aplicativo Web.
Claro que a ferramenta não é tão simplista como podemos imaginar por essas pequenas explicações. Mas, como falamos, não é nossa intenção entrar em detalhes mais específicos.
No entanto, é importante compreender conceitos como Falso Positivo e Falso Negativo. Afinal, são eles que vão ajudar na avaliação de uma ferramenta.
Para aqueles que desejam saber mais sobre esses conceitos, sugerimos a consulta desse artigo da OWASP.
Um pouco sobre Benchmark na análise de ferramentas de Code Review e SAST
Quando queremos entender melhor como podemos fazer ou mesmo analisar o benchmark entre ferramentas, a OWASP tem um documento bem interessante.
Em seu documento chamado OWASP Benchmark Project há uma detalhamento de como podemos entender melhor valores comparativos — no caso, entre as ferramentas.
O documento explica quais são os quatro pontos importantes que devem ser observados. Isso nos oferece a possibilidade de testarmos nossas ferramentas usando o Youden Index como modelo de validação desses testes.
Apesar de serem fortes argumentos para a realização de testes mais reais, sem o conceito já definido de “Silver Bullet” esses modelos de testes não podem ser considerados controles definitivos que venham a validar a aceitação ou não de uma ferramenta.
Então, caso você queira realizar seus próprios testes, basta seguir os passos a seguir:
- Baixe o Benchmark do github
- Rode sua ferramenta nesse benchmark
- Rode o BenchmarkScore contra o relatório gerado pela ferramenta
Porém, como mencionamos acima, não devemos usar esses resultados de forma isolada. Quando bem utilizados, eles podem ajudar e muito na definição de novos testes e avaliações de ferramentas.
Ainda assim, é possível que antes de realizar os seus testes, você queira primeiro avaliar de forma geral suas opções de ferramentas de Review e SAST.
Para estes casos, também vem da OWASP uma sugestão de como isso pode ser feito. No documento Source code analysis você vai encontrar uma lista de possíveis premissas a serem utilizadas.
Aqui não vamos listar todas elas, mas vamos apontar algumas que achamos que podem instigar o interesse do leitor para se aprofundar na leitura do documento.
1. Tipos de vulnerabilidades
Pode parecer básico, mas é importante mostrar que uma boa ferramenta de análise deve, no mínimo, saber identificar corretamente as vulnerabilidades presentes no OWASP TOP 10.
Uma outra opção seria buscar por uma ferramenta que elimine os erros mais comuns de codificação — relacionados no SANS TOP 25.
2. Efetividade
Veja se a ferramenta que você está testando já possui um score no OWASP Benchmark. Caso não tenha, pense em avaliar você mesmo esta ferramenta.
Um dos pontos mais importantes para uma ferramenta de code Review e SAST é ter uma boa efetividade. Ou seja, ter uma relação favorável entre relação entre Falsos Positivos e Falsos Negativos.
3. Automação
Garanta que a ferramenta que você está avaliando permita que ela possa ser facilmente integrada ao seu processo de desenvolvimento.
Mas lembre-se que estas ferramentas devem ser integradas em seu pipeline de desenvolvimento: sua execução deve ser forma automática. Isso garante a avaliação de forma contínua.
Por fim, esses 3 pontos colocados aqui não devem ser entendidos como os únicos que devem ser observados. Eles são apenas parte de um conjunto ainda maior. Crie os seus e avalie sua ferramenta dentro do cenário que você construiu.
Ferramentas de Code Review e SAST são parte da solução
Aqui não nos cabe dizer que as ferramentas não são importantes dentro do processo de desenvolvimento, mas acreditamos que elas não são a solução definitiva para o processo de revisão de código.
É claro que as ferramentas de Code Review e SAST sempre terão a sua importância dentro do processo. Mas cabe a nós, enquanto especialistas, identificarmos como estas ferramentas se encaixam no processo.
E, ainda que as ferramentas sejam muito importantes, nada vai substituir a criatividade do ser humano. E é por isso que defendemos que todo processo de revisão de código precisa ser feito por um profissional. Ou seja, é preciso que haja o trabalho manual.
Com esses pontos bem definidos, fechamos a primeira parte de nosso artigo. Esperamos, com isso, despertar um pensamento analítico para a avaliação de suas ferramentas.
No próximo artigo falaremos mais sobre Secure Code Review.
