Você sabe qual é a diferença entre Secure Code Review e SAST e quando usar cada um deles?
Dividimos este tema em dois artigos: no primeiro, falamos sobre as ferramentas de análise automatizadas, explicando qual seria o melhor momento e melhor forma de fazer uso desse recurso.
Já neste segundo artigo, abordaremos as ferramentas de Secure Code Review a partir de dois trechos do Owasp Code Review Guide.
O que diz o OWASP Code Review Guide
Este documento pode ser um dos grandes aliados das equipes de desenvolvimento e que desejam entender melhor a importância desse processo.
A primeira afirmação é:
“Secure code review is probably the single-most effective technique for identifying security bugs early in the system development lifecycle. When used together with automated and manual penetration testing, code review can significantly increase the cost effectiveness of an application security verification effort.”
Essa colocação pode ser traduzida de forma livre como:
“Revisão de código segura é provavelmente a mais simples técnica efetiva para identificar bugs de segurança cedo dentro do processo de desenvolvimento. Quando usada em conjunto com testes de intrusão automáticos e manuais, code review pode aumentar significativamente a efetividade na verificação da segurança das aplicações.”
Como podemos ver, aqui também não há a orientação no sentido de excluirmos todos os outros testes não manuais. O que queremos deixar claro é que esses testes automatizados devem fazer parte de um conjunto de testes.
E esses testes devem fazer parte da rotina de uma abordagem DevSecOps. Caso você ainda não esteja usando este modelo, recomendamos a leitura do artigo Como Migrar de DevOps para DevSecOps.
A segunda afirmação é:
“Manual secure code review provides insight into the “real risk” associated with insecure code… A human reviewer can understand the relevance of a bug or vulnerability in code. Context requires a human understanding of what is being assessed.”
Então, como podemos ver, o documentos nos mostra que:
“Revisão manual de código nos fornece uma visão real dos riscos associados a um código inseguro… Uma revisão humana pode entender a relevância de um bug ou de uma vulnerabilidade no código. Contexto requer entendimento humano do que está avaliado.”
Com base nessas duas afirmações, a seguir vamos tratar sobre secure code review.
O que é Secure Code Review?
Quando falamos em Secure Code Review, precisamos ter em mente que esse é um processo que tem como finalidade a validação de um código de uma aplicação, ou seja, a revisão de código buscará por falhas neste código.
Uma validação de código busca entender, portanto, se todos os controles de segurança estão devidamente incorporados na aplicação, fazendo com que esta se mantenha segura mesmo quando houver ataques.
Portanto, realizar um Secure Code Review é garantir que a aplicação foi desenvolvida de forma a estar protegida em um determinado ambiente.
Ainda, quando realizamos uma revisão em códigos, também garantimos que os desenvolvedores estão seguindo as melhores práticas de desenvolvimento seguro.
De forma geral, e em um ambiente perfeito, após a realização de uma revisão de código, um teste de intrusão posterior não deveria encontrar qualquer vulnerabilidade nesta aplicação.
Como falamos, não há aqui a intenção de hostilizar o uso de ferramentas: na realidade, acreditamos que a revisão de código pode atingir ótimos resultados e ganhar escalabilidade a partir da combinação do esforço humano e com a automação.
Isso porque as ferramentas usadas para realizar estes testes sempre vão precisar de uma intervenção humana.
Além disso, sempre será necessário que a revisão de código seja realizada por um especialista, pois é ele quem será capaz de avaliar brechas onde as ferramentas não podem chegar, considerando o contexto.
Quando usar Secure Code Review?
Assim como no uso de ferramentas SAST, a análise de código manual também tem seu momento, custo, vantagens e limitações.
Portanto, podemos afirmar que uma revisão manual de código também deve ser planejada e executada em um momento adequado do processo.
Revisões manuais de código, por exemplo, são perfeitas para determinar erros em lógica de negócios, assim como entender as intenções do desenvolvedor no momento da construção do software.
Já ferramentas automatizadas, por outro lado, não funcionam tão bem nesse sentido. Isso porque esse tipo de análise, de forma isolada, acaba gerando como resultado inúmeros falsos positivos. Ou, ainda pior: pode gerar muitos falsos negativos — como já comentamos.
A revisão manual de código
Avaliações de processos de autenticação, autorização, criptografia e acima de tudo, processos de validação de dados são melhores avaliados por revisões manuais de código.
A revisão manual também é indicada para examinar trechos de código raramente percorridos.
Técnicas de avaliação, como teste de intrusão ou “apenas difusão” por exemplo, examinam trechos do código para os quais são fornecidas entradas. No entanto, trechos menos acionados, ou intencionalmente ocultos, podem ser perdidos.
Isso porque as ferramentas automatizadas de análise estática podem seguir estes trechos, mas dificilmente conseguem entender a lógica de negócios associada a eles.
Uma revisão manual rigorosa geralmente é capaz desvendar e examinar esses trechos que, de outra forma, seriam perdidos ou mal compreendidos por ferramentas automatizadas.
Portanto, se compreendermos que precisamos usar as melhores ferramentas em benefício do resultado final, percebemos que tanto revisões automatizadas quanto manuais têm seu espaço.
Isso quer dizer que não há, na verdade, a eliminação de uma ou de outra opção dentro do processo: cada uma dessas técnicas apresenta benefícios para a segurança de uma aplicação. O que precisamos, então, é colocar cada um em seu lugar de destaque.
Reservar pequenos espaços de tempo dentro do processo de desenvolvimento para que seja feita uma revisão manual, além de entregar mais segurança, proporcionará uma melhor escalabilidade ao processo, visto que haverá menos código a ser validado.
Da mesma forma, posicionar ferramentas de validação automática de código pode ajudar no desenvolvimento de um processo com menor incidência de erros humanos, além de reduzir o tempo necessário para validações de códigos.
Mais uma vez, não há soluções mágicas quando falamos em segurança de aplicações. Afinal, ela é algo que vai além de um processo: a segurança de aplicações implica em uma mudança cultural.
Limitações das validações de código
Há momentos em que a interferência humana pode trazer mais prejuízo que vantagens.
Quando falamos de falhas como buffer overflow, existem partes de códigos não acionados (os chamados dead codes) ou mesmo erros sutis que dificilmente são identificados por seres humanos. E é neste momento que a ferramenta mostra seu valor.
Além desse aspecto, durante as revisões manuais muitas vulnerabilidades podem passar despercebidas, como no caso de integração de pequenos erros isolados espalhados por grande quantidade de código, por exemplo.
Então mais uma vez é preciso admitir que, em casos como esses, a ferramenta é uma das melhores opções.
O custo é uma outra limitação para equipes de revisão manual de código. Os profissionais que realizarão os testes precisam estar constantemente treinados e à disposição para as revisões de códigos. Isso pode gerar um custo que nem todas as empresas estão dispostas a cobrir.
Quanto ao tempo, além da experiência de desenvolvimento, geralmente leva mais de um ano para que um profissional adquira a experiência necessária para realizar revisões de código de forma segura.
Fica claro que há, sim, limitações no uso de revisões manuais, assim como também há limitações no uso exclusivo de ferramentas. A combinação entre os dois modelos nos parece ser a melhor solução.
Identificar as limitações em seu processo e a equipe certa já é um grande passo para construir uma melhor solução.
Da mesma forma, perceber que o uso isolado de ferramentas não é a melhor solução quando se quer garantir a segurança do código.
Antes do Secure Code Review
É comum encontrarmos equipes de desenvolvimento e de revisão de códigos que não trocam informações sobre a abordagem que foi usada para a construção do código.
Sendo assim, esse é o primeiro passo para realizar uma boa revisão de código.
1. Entenda a abordagem dos desenvolvedores
Durante o planejamento para a revisão de código, converse com os desenvolvedores e entenda qual abordagem e mecanismos foram usados para, por exemplo, validação de dados, autenticação ou mesmo autorização.
Esse tipo de entendimento pode ajudar a reduzir o tempo empregado na revisão de código, tornando a revisão muito mais efetiva.
2. Use várias técnicas
Outra boa abordagem é não se limitar ao uso de uma única técnica de revisão.
Sempre que possível, use técnicas de revisão manual e automatizadas, entendendo que cada método tem suas vantagens e pode trazer para a revisão ganhos consideráveis.
3. Atenha-se aos fatos
Quando falamos de analisar vulnerabilidades, é melhor pecar pelo excesso.
Durante o processo de revisão de código, não cabe o julgamento sobre o risco aceitável vindo da vulnerabilidade identificada. Portanto, a equipe de revisão deve relatar o que encontrou: deixe esta avaliação de risco para o cliente.
4. Busque entender o quadro geral
É normal que desenvolvedor busque o entendimento de cada detalhe da linha avaliada: resista a isso e busque entender o todo.
Em vez de entender o detalhe de cada linha, tente entender o código como um todo e o que ele está fazendo. Depois que entender o todo busque áreas importantes para revisar como por exemplo autenticação, autorização, conexão com bancos de dados.
5. Acompanhe os pontos de revisão
Tenha sempre em mente a troca de informações com outros membros da equipe que fazem as revisões. Afinal, essa troca de experiência ajuda a melhorar essas revisões.
A comunicação pode ainda ajudar no entendimento das vulnerabilidades identificadas, como elas se relacionam e como isso pode influenciar na segurança geral do código.
6. Mantenha seu foco na revisão do código
Muitas vezes o trabalho de revisão de código pode ter o foco desviado para outras vulnerabilidades que não estão conectadas ao código. Mas é preciso focar: afinal, revisar código não é um teste de intrusão.
Por fim, é importante deixar claro que essa lista não é uma lista finita de práticas a serem executadas antes das revisões, mas seguir esses pontos certamente ajudará a melhorar o seu processo e seus resultados.
Busque montar e entender o seu processo de revisão de código.
Qual a lição aprendida?
Aqui na Conviso já realizamos centenas de revisões de códigos em clientes. Chega a ser impossível estimar isso em linhas de código.
Com essa experiência, aprendemos a identificar algumas centenas de vulnerabilidades em mais de 10 anos de mercado.
Para nós, ficam evidentes os benefícios alcançados quando conseguimos identificar e ajudar na correção destas vulnerabilidades, minimizando, assim, o risco de comprometimento da aplicação.
Entendemos também que nem sempre esse é um movimento fácil, afinal, nem mesmo o fato de ter uma equipe de revisores experientes e efetivos garante 100% de segurança a seu código.
Portanto, é importante compreender que a revisão de código é um processo, e como tal é formado por recursos, tarefas e pessoas, cada um com sua importância no todo.
Vimos que um bom programa de revisão de código inclui uma variedade de ferramentas e métodos.
A revisão manual, por exemplo, pode encontrar falhas que nenhuma outra técnica pode identificar.
A longo prazo, quando a revisão de código manual é combinada com teste de intrusão, análise automatizada e treinamento para desenvolvedores, podemos identificar uma melhoria significativa no processo de revisão de uma aplicação.
Esperamos que estes dois artigos tenham contribuído para gerar uma nova visão ao seu processo de validação de código, ajudando a manter as suas aplicações cada vez mais seguras.
Nos vemos nos próximos!
