Testes dinâmicos de segurança de aplicações (DAST)

Uma ferramenta DAST não precisa conhecer detalhes da sua aplicação, como a linguagem de programação usada para implementá-la. Assim, você pode melhorar a segurança da sua aplicação mesmo quando usa linguagens de programação de nicho.

Como o DAST se diferencia de outros métodos de testes de segurança?

Para determinar se um método específico de teste de segurança é adequado ao ambiente de testes da sua aplicação, é importante considerar o que ele oferece e também suas limitações. Vamos analisar as diferenças entre cada um desses métodos de teste.

SAST vs. DAST vs. SCA

Testes estáticos de segurança de aplicações (SAST) têm foco no código. Eles são executados no início do pipeline de CI, analisando o código-fonte, o bytecode ou o código binário para identificar padrões problemáticos que não seguem as práticas recomendadas. O SAST depende da linguagem de programação.

Testes dinâmicos de segurança de aplicações (DAST) são um método de teste de caixa-preta que analisa aplicações durante a execução. São aplicados mais adiante no pipeline de CI. O DAST é um bom método para prevenir regressões e não depende de uma linguagem de programação específica.

Testes interativos de segurança de aplicações (IAST) são semelhantes ao DAST, pois têm foco no comportamento da aplicação durante a execução. Mas a análise IAST se baseia em uma combinação de testes de caixa-preta, varredura e análise dos fluxos internos da aplicação. A vantagem do IAST é poder associar descobertas semelhantes às do DAST ao código-fonte, como no SAST. A desvantagem dessa abordagem é que o IAST depende da linguagem de programação e só pode ser executado mais adiante no pipeline de CI.

Análise de composição de software (SCA) tem foco nas dependências de código de terceiros usadas na aplicação. A análise de composição de software é muito eficaz em aplicações que usam muitas bibliotecas de código aberto. Esse método também depende da linguagem de programação.

Leia mais sobre SAST vs. DAST: quais são as diferenças e como combinar os dois.

Como o DAST se integra a outros métodos de testes de segurança de aplicações?

O DAST funciona melhor em conjunto com métodos de testes de segurança de aplicações que dependem de verificações estáticas, como SAST e SCA, pois acrescenta informações sobre a execução à análise estática do código-fonte.

Muitas vezes, as ferramentas SAST analisam apenas trechos isolados de código e não levam o contexto em conta. O código de um arquivo pode parecer problemático, mesmo que outro arquivo que o utiliza resolva todos os problemas. As medidas de segurança implementadas no seu sistema podem até ser executadas em um computador completamente diferente. Por exemplo, uma ferramenta SAST identificaria uma entrada não sanitizada como um problema, pois não consegue associá-la à sanitização feita no servidor logo antes do uso dos dados.

As ferramentas DAST seguem uma abordagem de testes de ponta a ponta. Elas não sabem se o código do cliente segue as práticas recomendadas de sanitização de entradas. As ferramentas DAST analisam as entradas e saídas da sua aplicação; se a saída estiver sanitizada, não importa em que parte da arquitetura a sanitização aconteceu.

Mas partes da sua aplicação que só falham em casos extremos podem passar despercebidas por uma ferramenta DAST, já que ela cobre apenas casos de uso específicos, não entradas teóricas. É aí que entram as ferramentas SAST e SCA. Elas analisam o código-fonte e verificam comportamentos problemáticos que passariam despercebidos se você usasse apenas uma ferramenta DAST.

Por exemplo, uma conversão de tipo pode falhar ou gerar resultados indesejados. Um caso de teste DAST que cobre apenas 10 entradas pode indicar que está tudo certo, mas uma ferramenta SAST identificaria que um método de conversão tende a falhar com valores específicos que você nem teria considerado ao implementar sua aplicação.

Vantagens e desvantagens do DAST

Como a principal função das ferramentas DAST é testar uma aplicação durante a execução, elas oferecem vários benefícios, mas também têm desvantagens. Vamos analisá-las com mais detalhes para ajudar você a decidir se o DAST é adequado ao seu projeto de software.

Vantagens:

• Menos falsos positivos: Como não analisa a aplicação inteira, o DAST geralmente gera menos falsos positivos do que o SAST. Assim, você consegue verificar muito mais rápido se uma vulnerabilidade é real e descobrir se é possível evitar que ela volte a ocorrer.

• Independente de linguagem: O DAST é o único método de testes de segurança que não depende de uma linguagem de programação específica. Ele não analisa código-fonte, bytecode ou código assembly; apenas verifica as entradas e saídas do seu sistema. Se sua aplicação foi implementada com uma linguagem de programação de nicho, o DAST pode ser sua única opção.

• Novos testes rápidos para vulnerabilidades corrigidas: O DAST ajuda a controlar regressões. Quando uma vulnerabilidade de segurança é encontrada e reproduzida, essa reprodução pode ser automatizada e adicionada à suíte de testes DAST. Assim, cada versão futura incluirá as interações que levaram a problemas anteriores. Se esses problemas voltarem a ocorrer, o DAST os detectará antes do lançamento.

Desvantagens:

• Não fornece informações sobre o código: O DAST analisa apenas as entradas e saídas do seu sistema. Por isso, não é possível associar as vulnerabilidades encontradas às linhas de código.

• Processo de teste mais lento: A necessidade de executar e usar o software pode tornar o processo de teste mais lento, mesmo com métodos de teste automatizados. Percorrer um processo de cadastro com várias combinações de entradas leva tempo.

• Resultados no fim do pipeline de CI/CD: O DAST fica mais à direita no pipeline de CI/CD, pois as ferramentas precisam executar a aplicação para funcionar. Isso pode consumir bastante tempo, principalmente se sua aplicação tiver crescido ao longo do tempo.

• Pode exigir testes manuais: Se, por algum motivo, você não puder automatizar a execução e o uso da sua aplicação, terá que remover a verificação DAST do pipeline de CI/CD e testar a aplicação manualmente a cada lançamento.

Como implementar o DAST com sucesso

Como o DAST depende da execução da sua aplicação, adicioná-lo ao pipeline de testes não é tão simples quanto adicionar o SAST. É possível automatizar o DAST, mas primeiro é preciso criar um script ou gravar as etapas que serão automatizadas. Isso exige seguir um processo depois de adicionar uma ferramenta DAST ao pipeline.

1. Converse com seus usuários

Um bom ponto de partida para implementar o DAST é conversar com seus usuários e registrar como eles usam sua aplicação. Além de anotar o que fazem, peça que expliquem o que estão fazendo.

Os usuários tendem a esquecer em que estão clicando na aplicação: interações frequentes se tornam inconscientes. Isso ajuda os usuários a se concentrarem nas tarefas, mas o fato de não pensarem em algo em que clicaram não significa que isso não possa causar um problema.

2. Automatize as interações dos usuários

A próxima etapa é usar uma ferramenta de automação para criar scripts com as ações dos usuários. Isso pode ser mais simples em aplicações CLI e API do que em aplicações com interface gráfica, mas, em geral, é possível fazer isso em todos esses tipos de aplicação.

3. Adicione os scripts de teste ao pipeline de CI/CD

Quando os casos de uso mais importantes estiverem cobertos por interações automatizadas, você poderá executar esses scripts na sua aplicação enquanto uma ferramenta DAST faz a varredura. Depois da primeira execução do DAST, você poderá começar a corrigir as vulnerabilidades de segurança.

4. Adicione testes de regressão à suíte de testes

Se você encontrar vulnerabilidades de segurança no uso diário da sua aplicação, poderá adicionar scripts específicos de uso à sua suíte de testes. Isso ajuda a garantir que os problemas não voltem a ocorrer.

Resumo

Embora o DAST seja um método confiável de detecção de vulnerabilidades para ter no seu arsenal, usá-lo sozinho não cobre todas as frentes. Mas, às vezes, ele é a única solução disponível, por exemplo, quando você usa uma linguagem de programação de nicho para implementar sua aplicação ou pacotes e extensões de código fechado para uma linguagem de programação comum.

Executar uma ferramenta DAST pode levar bastante tempo, especialmente quando há interações complexas. E, se você não conseguir automatizar essas interações, terá que realizá-las manualmente antes de cada lançamento, o que pode levar dias ou até semanas.

Ao comparar SAST e DAST, o SAST pode parecer a melhor opção em geral, pois pode ser usado mais cedo no processo de desenvolvimento, quando é mais fácil e barato corrigir os problemas de segurança detectados. Mas as ferramentas DAST também oferecem ótimos benefícios.