Desenvolvimento seguro com DAST e SCA: protegendo as dependências e a aplicação em execução

Analisando dependências vulneráveis - Apresentação

Olá! Eu sou o Geovane e serei o seu instrutor neste curso sobre desenvolvimento seguro, onde vamos fazer scan de dependências e também analisar nossa aplicação em tempo de execução.

Audiodescrição: Geovane tem pele branca, cabelo e barba curtos, e usa óculos com armação arredondada. Está usando camiseta preta e ao fundo há uma parede azul.

Se você quer aprender a analisar a segurança das dependências da sua aplicação e também como analisar a segurança quando sua aplicação estiver em execução, este curso é para você.

Vamos aprender a escanear nossas dependências e também as dependências de nossas dependências, buscando por vulnerabilidades para corrigir. Para isso, utilizaremos uma ferramenta chamada Dependency Track.

Depois, vamos conectar essa ferramenta à esteira de CI para aprimorar o fluxo de desenvolvimento, pensando no contexto de uma empresa que trabalha com muitas pessoas desenvolvendo.

Em seguida, vamos trabalhar o conceito de testes dinâmicos, utilizando a ferramenta Nuclei para garantir que nossa aplicação esteja sendo testada a partir de dezenas de vetores de teste com a aplicação em execução.

Para finalizar, conheceremos um conjunto de ferramentas para melhorar o seu fluxo de desenvolvimento de aplicações seguras. Tudo isso aprenderemos no contexto do VollMed, uma aplicação para gerenciamento de clínicas, que permite, por exemplo, criar e editar perfis de pacientes. Lembrando que focaremos na parte da API do aplicativo VollMed.

Pré-requisitos

Caso você não tenha acompanhado todos os cursos dessa formação, lembre-se de que é importante ter alguns conhecimentos em HTTP e APIs, além de saber trabalhar um pouco com o Node.js; ter noções sobre AWS e GitHub, e também saber utilizar comandos no terminal.

Não esqueça de aproveitar todos os recursos da plataforma Alura. Se tiver dúvidas, pode recorrer ao fórum e à nossa comunidade no Discord. Então é isso aí, vamos estudar!

Analisando dependências vulneráveis - Instalando o Dependency Track

Estamos de volta, mexendo no VollMed, nos cursos dessa formação temos trabalhado nele para deixá-lo cada vez mais seguro do ponto de vista do desenvolvimento.

Então, fomos pegando cada arquivo aqui do projeto do VollMed e inspecionamos para deixá-lo mais seguro.

Mas será que verificamos tudo mesmo? Ou seja, se sairmos um pouco da nossa pasta do código-fonte do VollMed, no explorador de arquivos temos o arquivo package.json, onde, entre outras coisas, estão definidas quais são as dependências que o VollMed precisa.

Porque não implementamos tudo do zero. Precisamos, por exemplo, de uma biblioteca para fazer a validação do CPF, outra biblioteca que é o próprio Express, que é o nosso framework, e todas essas bibliotecas também chamam outras bibliotecas.

Então, fica uma dúvida aqui para tentarmos entender se essas bibliotecas, essas dependências, estão seguras. Será que tem como verificar isso?

Uma forma talvez seria abrir o GitHub de cada uma delas e inspecionar e olhar no código, ou talvez rodar algum programa para verificar, alguma das técnicas que aprendemos para verificar a segurança. Mas isso seria muito trabalho, porque temos muitas dependências no arquivo package.json.

Na verdade, temos uma solução muito mais simples, que é utilizar algumas ferramentas para fazer análise das dependências do ponto de vista de segurança, ou seja, verificar se essas dependências têm vulnerabilidades conhecidas, e se tiver, vamos precisar fazer alguma coisa a respeito.

Vamos acessar o navegador, onde já tenho aberta a página de uma dessas ferramentas que podemos utilizar para escanear as dependências. Vamos acessar o site da ferramenta Dependency Track.

Podemos instalar essa ferramenta para rodar no nosso projeto. No lado esquerdo tem um botão"Download". ao clicarmos nele, a página rola para baixo, onde aparece o comando de instalação.

Docker Compose

curl -LO https://dependencytrack.org/docker-compose.yml
docker-compose up -d

Então, tem dois comandos aqui. Vou começar pelo curl, que basicamente permite que façamos o download de um arquivo Docker Compose.

Vamos para o terminal. E fora da pasta do VollMed podemos rodar o seguinte comando:

curl -LO https://dependencytrack.org/docker-compose.yml

Podemos até abrir o docker-compose.yml e dar uma olhada no que tem aqui dentro. Vemos que tem dois serviços. Um deles é um servidor de API, dtrack-apiserver. Tem um monte de variáveis que estão comentadas, com as quais não precisamos nos preocupar por enquanto. E tudo isso ainda está dentro da configuração da API. E mais para baixo, tem também outro serviço configurado, que é o Dependency Track Frontend. Ou seja, esse Docker Compose coloca dois serviços para executar, um back-end e um front-end, que são os dois do Dependency Track.

Outra coisa interessante de observarmos nesse arquivo, é que tem algumas portas mapeadas. Então, no caso do back-end, temos a porta 8081, e no caso do front-end estamos com a porta 8080 configurada. E o último detalhe é que, para o back-end, ele também faz algumas reservas para os recursos da máquina. O que quer dizer isso? Quer dizer quanta memória vai ser necessária para executar. Então, ele vem aqui por padrão, reservando 8 GB de memória para executar o Dependency Track, e coloca um limite de 12 GB, então, para não passar de 12, ficar entre 8 e 12.

É bastante memória, mas se precisar fazer ajustes, por exemplo, para conseguir executar na sua máquina, aqui testei até rodar ele com 6 GB de mínimo e 8 GB de máximo, então, isso pode ser ajustado também.

Vamos voltar no terminal e rodar o próximo comando que está na seção de download do Dependency Track:

docker-compose up -d

Esse comando vai executar os dois serviços, API e o front-end do Dependency Track. E como acabamos de ver, que ele usa bastante memória, isso é um indício que ele usa bastante recurso, então, vai demorar um pouco para carregar.

Ele até está baixando algumas coisas aqui para terminar de executar, mas já consigo acessá-lo, ele vai fazendo o resto em segundo plano.

Então, volto aqui para o meu navegador, e vou colocar na barra de endereços localhost:8080 e pressionar "Enter".

Será aberta uma tela do Dependency Track onde podemos fazer login. Por padrão, o usuário e a senha, os dois são "admin".

Ao fazer o login, ele vai pedir para mudarmos essa senha, que está muito óbvia por padrão. Vocês escolhem a senha que quiserem colocar. Vamos atualizar a senha, e ele vai pedir para fazermos o login novamente, agora com a nova senha. Admin, e a senha que escolheu. É bom anotar a senha, pois depois, pode acabar tendo que resetar toda a máquina, porque não vai ter o link para obter senha novamente.

Neste vídeo, fizemos a instalação do Dependency Track, que é o primeiro passo para podermos analisar as dependências do nosso projeto VollMed.

Estamos logados no Dependency Track. Vamos perceber que ele tem uma interface muito interessante. Temos um dashboard, onde vão aparecer as vulnerabilidades do portfólio, ou seja, dos projetos que estaremos analisando com o Dependency Track.

Podemos clicar nesse menu do lado esquerdo para criar nossos projetos. Além disso, podemos fazer também o gerenciamento das dependências, que é um tópico importante. Enfim, o Dependency Track é um projeto bem completo e amplamente utilizado no mercado. Esse é um dos motivos de termos selecionado essa ferramenta para trabalhar nesse curso.

Agora, falta colocarmos as dependências para o Dependency Track analisar. Mas isso, vamos fazer no próximo vídeo!

Analisando dependências vulneráveis - Gerando a SBOM e importando no DTrack

Já estamos com o Dependency Track instalado, e o que falta é conseguirmos carregar a nossa lista de dependências para ele fazer a análise das vulnerabilidades.

Estou pensando de que forma poderíamos fazer isso. Por exemplo, poderíamos ir até o nosso arquivo package.json, copiar toda a nossa lista de dependências, talvez copiar e colar lá no Dependency Track para ele analisar.

Mas, isso seria algo muito manual para nós fazer, queremos algo mais automatizado. E se fizéssemos isso, não teríamos como avaliar as dependências das dependências. Precisamos de uma solução mais robusta, algo que seja recursivo, que verifique dentro de cada dependência para termos uma visão completa de todos os componentes do nosso software.

Felizmente, alguém já teve esse problema, outras pessoas já pensaram nisso, e já existem até soluções open source para resolver esse problema. Vou mudar de tela, vou abrir o meu navegador, onde já estou com um projeto aberto no GitHub, que é o CycloneDX implementado para o Node.js.

No READ ME tem as instruções de como instalá-lo. Vamos copiar o seguinte comando para instalar como um global pelo npm:

npm install --global @cyclonedx/cyclonedx-npm

Vamos colar e executar no terminal. Estamos fazendo npm install --global, o que significa que vai instalar para funcionar como um comando no nosso terminal, e não como uma instalação no package.json.

Agora nós já temos o CycloneDX instalado, e para executá-lo, basta colocar o nome dele, cyclonedx-npm, e podemos até adicionar um --help para entender como utilizar esse comando.

cyclonedx-npm --help

Tem duas flags aqui que são importantes para nós. A primeira é o tipo da aplicação, --mc-type. E tem alguns tipos que eu posso selecionar. Por exemplo, se for uma biblioteca, ou se for um firmware para um dispositivo embarcado, mas no caso é uma API, então é uma aplicação.

Vou colocar aqui que o tipo é aplicação, e o resultado dessa análise do CycloneDX vai ser uma lista enorme de dependências. Precisamos colocar isso em um arquivo para ficar salvo. Vamos usar a configuração output file, e escrever bom.json, que será o nome do arquivo onde vamos colocar.

cyclonedx-npm --mc-type application --output-file bom.json

Podemos pressionar "Enter", ele vai analisar o package.json, e também todos os node_modules, que são onde as dependências são instaladas. Por exemplo, se eu fizer um ls no node_modules, vemos que tem muita coisa. Se eu abrir o arquivo bom.json, você verá que também é um arquivo muito grande que reflete a quantidade de dependências que temos.

Se analisarmos esse json, veremos que primeiramente há alguns metadados, que não vamos examinar muito, e um pouco mais abaixo, na linha 97, começa um array com a lista de todos os componentes do nosso software.

Por exemplo, o primeiro componente é chamado de Babel, que é o transpilador de JavaScript, que é do tipo library. Nessa array tem um autor, uma descrição, uma licença, no caso, que é a licença do MIT. Ele faz essa estrutura para todas as dependências. Olha só o tamanho desse arquivo, deixa eu fazer um scroll para baixo, até a última linha, temos 59.362 linhas dessa análise das dependências.

Quando eu falo que é uma lista enorme das dependências, não é exagero, é uma lista enorme mesmo.

Deixa eu fechar esse arquivo porque agora que já temos ele, está na hora de colocá-lo no Dependency Track para fazer análise.

Vamos voltar para o navegador, no dashboard do Dependency Track e podemos clicar no menu "Projects" da barra lateral esquerda.

Em seguida, podemos clicar no botão "Create Project", e precisamos colocar algumas configurações. Primeiro, vou colocar o nome do projeto: Voll.Med, vou colocar a versão também, que é 1.0.0, e o classificador é aplicação, Application o mesmo que selecionamos na linha de comando ao rodar o CycloneDX.

Após preencher os campos, podemos clicar em "Create". Ele criou o projeto, podemos clicar no projeto. Ao abrir, ele mostra o nome, que é Voll.Med, na versão 1.0, e aqui tem um dashboard onde vão aparecer as nossas dependências quando carregarmos.

Vamos selecionar a aba "Components", e clicar no botão "Upload BOM". Nesta janela, podemos selecionar o arquivo bom.json e clicar em "Upload". Agora, o BOM vai ser importado pelo Dependency Track, e ele vai tentar fazer duas coisas. A primeira delas é buscar na internet por bancos de dados de vulnerabilidades já conhecidas. A segunda coisa é tentar cruzar essas vulnerabilidades já conhecidas com as dependências que estão lá, e também com as versões das dependências.

Se olharmos aqui no terminal, vou mudar de aba, aqui para a aba onde rodamos o Docker Compose do Dependency Track, vamos perceber que há muitos logs aparecendo. Por exemplo, um dos logs que aparece aqui é OSS Index Analysis Task, ou seja, é uma tarefa de análise do OSS (Open Source Software), que são programas de código aberto. Então, ele está analisando as dependências. Aqui tem um outro log também, que é BOM Upload Processing Task. Então, esse tal de "BOM" que temos falado até agora, o que será que significa? Vamos aproveitar que está carregando para entender também.

Deixa eu voltar aqui no nosso GitHub do CycloneDX, e vamos ler a seção "Sobre" dele. Ele está dizendo o seguinte, que o CycloneDX permite que criemos Software Bill of Materials do tipo CycloneDX para projetos Node.js.

O Bill of Materials é exatamente a lista que criamos. Ao invés de chamá-lo de List of Materials, ele é chamado de Bill of Materials. E "Software", porque esse termo de Bill of Materials às vezes é utilizado em outras indústrias também. Por isso que às vezes vocês vão ver "BOM" ou "SBOM" e tudo significa a mesma coisa: é a nossa lista de dependências.

Pelo terminal conseguimos ver que o Dependency Track continua trabalhando e fazendo análise. Essa análise que chamamos de Software Component Analysis. Ou seja, é a análise de todos os componentes do nosso software. E é esse o tipo de teste que estamos fazendo nessa aula. Vamos continuar na próxima também!

Sobre o curso Desenvolvimento seguro com DAST e SCA: protegendo as dependências e a aplicação em execução

O curso Desenvolvimento seguro com DAST e SCA: protegendo as dependências e a aplicação em execução possui 120 minutos de vídeos, em um total de 46 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:

• Analisando dependências vulneráveis
• Colocando o DTrack na esteira de produção
• Testando a segurança de forma dinâmica
• Personalizando as verificações dinâmicas
• Ferramentas para o fluxo de desenvolvimento seguro