Alura > Cursos de DevOps > Cursos de Segurança > Conteúdos de Segurança > Primeiras aulas do curso [EM BREVE] Análise estática de segurança (SAST)

[EM BREVE] Análise estática de segurança (SAST)

Aula 1 - Apresentação

Apresentando o instrutor e o curso

Olá! Meu nome é Rodrigo da Silva Ferreira Caneppele e estou aqui para começarmos nosso curso sobre SAST, que é Análise Estática de Segurança de Software. Vamos explorar algumas ferramentas open source (código aberto) e explicar a diferença em relação às ferramentas enterprise (empresariais), além de como podemos validar o código dentro de uma ferramenta de segurança, que neste caso é o SAST.

Possuo formação em Engenharia de Computação, com mestrado na área de Engenharia Biomédica, em Cibersegurança e em Cloud (nuvem).

Audiodescrição: Rodrigo é um homem branco, com cabelo castanho claro e comprido. Ele veste uma blusa azul e está em um ambiente de escritório, com uma parede branca ao fundo e uma estante com livros à sua direita.

Explorando DevSecOps e Application Security

Olá! Vamos explorar a área de DevSecOps e Application Security, com o objetivo de ajudar as pessoas desenvolvedoras a construir aplicações cada vez mais seguras. Uma das etapas importantes que abordaremos nesta disciplina é a adesão do SAST.

Um ponto interessante que sempre gostamos de destacar é a questão da cultura maker. Para aqueles que têm alguma dificuldade em programar, conhecer um pouco sobre Arduino e microcontroladores pode ser bastante útil. Essa prática pode ajudar a visualizar a programação de forma mais concreta, assim como nos ajudou.

Iniciando o curso

Durante o curso, comentaremos alguns trechos de código que podem ser de interesse. Acreditamos que vale muito a pena conferir. Vamos começar o nosso curso. Obrigado! [♪]

Aula 1 - sast-ci-cd

Abordando o papel do SAST no ciclo de desenvolvimento seguro

Continuando nossa aula, já explicamos o que é SAST e a diferença entre SAST, SCA e DAST. Discutimos sobre o motor do SAST, que funciona de maneira semelhante a regex. Agora, vamos abordar o papel do SAST no ciclo de desenvolvimento de software seguro, conhecido como SSDLC.

O que significa o Software Development Lifecycle de forma segura? Trata-se de um processo contínuo, no qual o desenvolvimento de código não tem um fim. A ideia é sempre aprimorar o código como um todo. Começamos com o projeto do código e do software, considerando sua escalabilidade. Em seguida, passamos pelos requisitos e pela arquitetura da aplicação. Depois, realizamos testes de qualidade e segurança, para então desenvolver o código com foco em segurança e levá-lo à produção.

Integrando o SAST no processo de desenvolvimento

Consideramos muitos requisitos, como autenticação e autorização, especialmente na arquitetura e na escalabilidade da aplicação. Dessa forma, identificamos onde adicionar o SAST, que é principalmente na fase de teste. Podemos realizar testes de qualidade e segurança, incluindo a análise do código. Se identificarmos alguma vulnerabilidade, corrigimos antes de levar para a produção, no momento do deploy.

Podemos automatizar esse processo com esteiras ou utilizando a IDE, como mostramos na primeira aula. O SAST se encaixa na fase de desenvolvimento do código, ou seja, na escrita do código, antes de levá-lo para um ambiente específico. Temos a ideia do CI/CD, onde a pipeline é utilizada antes de levar o código para um ambiente específico, como o de homologação. Podemos fazer isso durante o desenvolvimento do código.

Implementando controles e prevenindo vulnerabilidades

Essa abordagem permite desenvolver a aplicação de forma integrada e contínua, levando-a para outros ambientes até o deploy, seja em homologação ou produção. Além disso, colocamos um gate, que funciona como uma trava na pipeline, para impedir que vulnerabilidades cheguem a esses ambientes. No ambiente de homologação, isso pode não ser um problema, mas em produção, sim. Por isso, geralmente colocamos o gate em produção e, dependendo dos cenários e da maturidade das aplicações, também em homologação, para resolver problemas antes de chegar à produção.

Durante o desenvolvimento de uma aplicação, podemos implementar pre-commit hooks para adicionar alguns mecanismos de controle, como evitar que vulnerabilidades, por exemplo, senhas, sejam vazadas para o GitHub. Dessa forma, podemos bloquear o commit antes que ele chegue à produção. Existem maneiras de implementar esses controles, mas geralmente pensamos em gates de pipeline, ou seja, desenvolver de forma automatizada. No entanto, também podemos evitar que um código vulnerável seja enviado para uma ferramenta de versionamento como o GitHub, impedindo que ele seja explorado.

Garantindo a segurança na pipeline e no ambiente de desenvolvimento

Na pipeline, podemos evitar que o código vulnerável seja implantado, garantindo que ele não seja enviado com vulnerabilidades. Além disso, a prática de shift left nos permite detectar vulnerabilidades cedo e fornecer um feedback rápido. Se identificarmos uma vulnerabilidade na pipeline, podemos informar a pessoa desenvolvedora, que poderá verificar se conseguiu realizar o deploy. Podemos enviar essa mensagem por uma ferramenta de comunicação, como o Slack, ou diretamente na pipeline, informando que o deploy não foi possível devido à vulnerabilidade. Assim, evitamos que a aplicação seja levada à produção com vulnerabilidades, reduzindo o custo e o impacto dessas falhas em produção.

Podemos também integrar o ambiente de desenvolvimento com a IDE, ou através de alertas, como mencionado, passando essa informação para a pessoa desenvolvedora por meio de um bot, que indicará onde está o erro da vulnerabilidade, permitindo que ela corrija antes de passar para outros ambientes, sejam eles de homologação ou produção. Isso pode ser feito antes do commit, com ferramentas que analisam o código na IDE, bloqueando-o antes de ser enviado para o GitHub. Por exemplo, o uso do GitLeaks é comum para detectar vulnerabilidades relacionadas a senhas, impedindo que o commit seja enviado para o GitHub.

Prevenindo vulnerabilidades com ferramentas de CI/CD

Além disso, podemos identificar outras vulnerabilidades, como XSS e SQL Injection na aplicação. Na ferramenta de CI/CD, que veremos na prática mais adiante no curso, podemos prevenir problemas usando uma esteira automatizada, evitando que o código vá para a produção. Ferramentas como Jenkins e GitHub Actions, que são de CI/CD, permitem integrar ferramentas de segurança que bloqueiam e impedem que o código seja enviado para ambientes vulneráveis.

Esperamos que tenham gostado da aula. Muito obrigado!

Aula 1 - motor-sast

Introduzindo o conceito de SAST

Olá, pessoal.

Na nossa última aula, discutimos sobre o que é SAST, a diferença entre SAST, SCA e DAST, e como eles são utilizados. Agora, vamos entender mais detalhadamente como funciona o SAST internamente. O SAST é uma ferramenta que realiza análise estática do código em busca de vulnerabilidades. Internamente, ele utiliza uma técnica chamada AST (Abstract Syntax Tree), que é uma representação abstrata do código. Essa técnica busca por padrões específicos, como, por exemplo, a palavra input no Python, request para identificar requisições, ou password para verificar questões relacionadas a senhas. Dessa forma, o SAST consegue identificar funções e variáveis dentro da aplicação.

Explicando o uso do Checkmarx e a função do SAST

Neste exemplo, utilizamos uma ferramenta chamada Checkmarx, que é paga e serve para analisar código. Ela realiza essa representação abstrata, buscando por entradas e vulnerabilidades, como XSS. Se o código contém algo relacionado a Path Traversal, a ferramenta verifica se há validação para identificar Path Traversal, por exemplo. A ideia é que o SAST funcione como um grande regex (expressão regular), buscando palavras específicas na aplicação. Ele verifica se há validação de entrada que poderia evitar a ocorrência de vulnerabilidades. Assim, o SAST mapeia o que chamamos de fluxo, analisando a entrada e o contexto de segurança para identificar possíveis vulnerabilidades.

Demonstrando a implementação do SAST com exemplo de código

Para ilustrar como o SAST pode ser implementado, considere o seguinte exemplo de código:

if(All.IsWebApplication)
{
    CxList inputs = Find_Interactive_Inputs();
    CxList outputs = Find_XSS_Outputs().Find_Console_Outputs();
    CxList sanitized = Find_XSS_Sanitize();
    result = inputs.InfluencingOnAndNotSanitized(outputs, sanitized);
}

Esse trecho de código demonstra como uma aplicação web pode identificar entradas interativas e saídas que podem ser vulneráveis a XSS, verificando se essas saídas foram devidamente sanitizadas.

Explicando o uso de expressões regulares no SAST

Em resumo, o SAST realiza consultas para buscar padrões específicos, como XSS, e, se não houver validação adequada, identifica isso como uma vulnerabilidade. Para esclarecer, um regex é uma expressão regular que busca por palavras específicas.

Aqui está um texto que demonstra como buscar por letras maiúsculas, como A e Z. Se quisermos buscar por palavras inteiras, podemos utilizar o \w+, que capturará a palavra completa contendo a letra maiúscula. O regex (expressão regular) funciona dessa forma, permitindo buscar por entradas ou partes de palavras, mapeando se há algum tipo de validação no contexto. Isso é o que ocorre nos bastidores quando pensamos em sites e no funcionamento de seus motores.

Exemplificando o uso de expressões regulares

Para exemplificar o uso de expressões regulares, considere o seguinte padrão:

/([A-Z])/g

Esse regex busca por qualquer letra maiúscula no texto. Se quisermos capturar palavras inteiras que começam com uma letra maiúscula, podemos usar:

/([A-Z]\w+)/g

Discutindo o papel da Inteligência Artificial no SAST

Atualmente, com o avanço da Inteligência Artificial, alguns Large Language Models (Modelos de Linguagem Grande) têm sido utilizados para auxiliar nesse contexto, reduzindo a ocorrência de falsos positivos. Assim, conseguimos identificar o que é realmente uma vulnerabilidade e o que é erroneamente interpretado como tal. Essa é uma discussão contínua de melhoria e aprimoramento das ferramentas ao longo do tempo, mas os LLMs têm contribuído significativamente para esse progresso.

Comparando ferramentas Open Source e Enterprise

No slide, vemos que ele serve como um padrão para buscar funções e algoritmos, especialmente relacionados a senhas. Pode buscar por palavras específicas, como exec e eval, ou por algoritmos inadequados para criptografia, como MD5 e SHA-1, identificando vulnerabilidades. Dessa forma, padrões conhecidos de erro são considerados para evitar falhas na aplicação, como um cat dentro dela. Tudo isso é levado em conta para criar regras e gerar o formato que conhecemos como SAST.

A diferença entre ferramentas Open Source e Enterprise é que estas últimas possuem LLMs e regras mais específicas. A ideia principal é buscar palavras específicas, analisar os dados e o fluxo dentro do sistema, e configurar e tratar esses dados na aplicação para detectar vulnerabilidades.

Concluindo a aula sobre SAST

Esperamos que tenham gostado da aula. O objetivo foi explicar o funcionamento do SAST, que é um grande motor com várias regras, semelhante a um regex, buscando palavras específicas e mapeando possíveis correções para evitar vulnerabilidades. Obrigado!

Sobre o curso [EM BREVE] Análise estática de segurança (SAST)

O curso [EM BREVE] Análise estática de segurança (SAST) possui 163 minutos de vídeos, em um total de 26 atividades. Gostou? Conheça nossos outros cursos de Segurança em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

Aprenda Segurança acessando integralmente esse e outros cursos, comece hoje!

Conheça os Planos para Empresas