A segurança das aplicações é a cada dia um dos pontos mais sensíveis da cybersecurity para as empresas. Elas precisam de forma ágil e eficiente identificar as vulnerabilidades em suas aplicações, mitigando os riscos. Abordamos aqui em nosso blog em outro artigo o que é o DevSecOps e como esse framework funciona e faz parte desse cenário.

Neste artigo, vamos nos aprofundar em dois conceitos importantes para o DevSecOps: DAST e SAST. Esses conceitos criam certa confusão no mercado tanto pela similaridade entre os nomes quanto pela interseção que possuem em seus objetivos ao serem realizados.

 

O que são o SAST e DAST?

SAST e DAST são metodologias de testagem de segurança das aplicações usadas para descobrir vulnerabilidades que podem tornar uma aplicação suscetível a um ataque. O SAST – Static Application Security Testing, é um método white box de teste. Ele examina o código do software em busca de falhas e fraquezas, como SQL Injection e outras listadas, por exemplo, no OWASP Top 10.

O DAST – Dynamic Application Security Testing é um método black box que examina a aplicação enquanto ela está rodando, tentando encontrar vulnerabilidades que um atacante poderia usar para explorar a aplicação.

 

Qual a diferença entre SAST e DAST?

Muitas empresas questionam sobre os prós e contras de escolher um SAST ou um DAST. Contudo, a verdade é que são abordagens diferentes, com benefícios diferentes e recomendadas para momentos diferentes dentro do DevSecOps.

As duas abordagens encontram tipos diferentes de vulnerabilidades, e são mais eficientes ou não de acordo com o momento em que são empregadas no ciclo de desenvolvimento. O SAST deve ser performado mais no começo e de preferência nos arquivos que contenham o código fonte. Contudo, já que essa abordagem é feita sobre código estático, ela não consegue identificar vulnerabilidades que surgem com a aplicação em produção.

O DAST por sua vez deve ser feito com a aplicação rodando, em ambiente similar ao de produção. Contudo, o DAST é um teste mais complexo, e as vulnerabilidades encontradas (que poderia ter sido encontradas previamente com um SAST) tendem a ser empurradas para correção apenas no próximo início do ciclo de desenvolvimento.

Para poder dizer que verdadeiramente existe um framework de DevSecOps em sua empresa, é preciso que as duas abordagens sejam realizadas, de forma que os resultados sejam complementares, aumentando significativamente a segurança da aplicação testada.

Se você ainda não conhece o Security Pipe, o serviço modular da Real Protect para levar o DevSecOps para sua empresa, confira aqui nossa abordagem!