Automações na área de AppSec 🤖
Published: 2023-02-28 22:50:58

Olá, pessoal.
Tudo bem?

Esse é o meu primeiro post utilizando a plataforma dev.to! Eu possuo um [blog](https://michelleamesquita.medium.com/) no Medium também, onde falo de AppSec/DevSecOps caso queiram ler, mas dependendo, futuramente, eu possa adicionar alguns artigos que escrevi lá aqui também. 😊

Sem mais delongas, gostaria de tratar um pouco sobre o assunto automações para a área de AppSec.

Começo com esse texto pois dentro dessa vasta área de Application Security, existe espaço para todos trabalharem, desde conscientização dos desenvolvedores ou mesmo adição de ferramentas na pipeline!

No entanto, o foco hoje é na parte de **secure code review**! Isso é importante de ser falado pois muito se fala de adição de ferramentas de **[SAST](https://owasp.org/www-community/Source_Code_Analysis_Tools), [DAST](https://owasp.org/www-project-devsecops-guideline/latest/02b-Dynamic-Application-Security-Testing) e [SCA](https://owasp.org/www-project-dependency-check/)**. No entanto, as ferramentas trazem bastante _**falso positivos**_. Assim, temos que exercitar bem a lógica de programação para validarmos o _output_ que a ferramenta retorna. Como também, questionar se a ferramenta está validando todos os pontos que ela deveria checar.

Dessa forma, o secure code review é extremamente necessário para validar e confirmar o que o SAST retorna. Isso porque as ferramentas possuem diversas lógicas internas com expressões regulares, mas que nem sempre identificam que um ponto foi tratado (falso positivo) ou não retornam todos os pontos que estão vulneráveis!

Além disso, é interessante pensar e entender na lógica que uma ferramenta de SAST funciona. Nesse caso, trouxe como exemplo o [Checkmarx](https://checkmarx.com/glossary/static-application-security-testing-sast/), na imagem abaixo, é que ela analisa o input da ferramenta (parâmetros), output (saída para o usuário) e através disso, ele busca se existe um sanitizador (algo que modifique a entrada do usuário) para a vulnerabilidade **[XSS](https://owasp.org/www-community/attacks/xss/)**. Caso exista essa regra na ferramenta, ele entende que a vulnerabilidade foi tratada.
![Imagem que exemplifica a lógica do Checkmarx](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v868aujwh5p0wgfns2jt.png)

Como as ferramentas possuem uma lista de regras pré-setadas, é importante que o analista de AppSec também crie suas próprias regras de acordo com as vivências na área, até para confirmar ou analisar se existem pontos também críticos. Embora as ferramentas na pipeline já agilizem muito o processo, precisamos ter esse entendimento que é necessário realizar nossa própria **análise** também. 

Para isso, eu desenvolvi um script que funciona como um grande **[RegEx](https://regexr.com/)**, onde eu crio as minhas regras para validar ainda mais pontos.

Segue o link no Github para quem quiser contribuir também 😎.
https://github.com/michelleamesquita/sast-validator

Eu criei regras para algumas das principais vulnerabilidades que vejo acontecer no dia-a-dia. Como também, separei por algumas funcionalidades como autenticação, upload de arquivos e reset/conexão de bancos com senhas. Quando falamos de code review, esse é um ponto super importante para entender aonde procurar por vulnerabilidades: **funcionalidades da aplicação**.


Funcionamento da aplicação:

![Imagem que contém o comando para executar o script](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l9re92jwwkhawxmnw55e.png)

Comando:
`python3 sast.py -d PATH -l Language (optional) 
`

Output:
![Imagem que contém o output do script](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/87wz1trdc5n1py74smok.png)


Espero que gostem! 💜👩‍💻