Entre para a LISTA VIP da Black Friday

00

DIAS

00

HORAS

00

MIN

00

SEG

Clique para saber mais
Alura > Cursos de DevOps > Cursos de Segurança > Conteúdos de Segurança > Primeiras aulas do curso Desenvolvimento Seguro: implementando Secret Scanning e SAST na esteira de CI

Desenvolvimento Seguro: implementando Secret Scanning e SAST na esteira de CI

Scanning de Secrets com TruffleHog - Apresentação

Olá! Eu sou a Camila Fernanda, mas você pode me chamar de Mila. Sou instrutora aqui na Alura e vou acompanhar você ao longo deste curso que é destinado a você, pessoa desenvolvedora que deseja trabalhar com segurança no desenvolvimento de aplicações.

Audiodescrição: Mila se descreve como uma mulher de pele parda, com cabelos compridos e encaracolados de cor castanho-escuro, e olhos castanho-escuro. Ela está sentada vestindo uma camiseta branca e usando um headset preto. Ao fundo, há uma parede branca com iluminação em degradê nas cores roxa e azul.

O que vamos aprender?

Neste curso, vamos automatizar um Secret Scanning, que seria o TruffleHog, que fará uma varredura de todo o projeto em busca de segredos ou credenciais em nosso código. Além disso, vamos automatizar essa varredura em um pré-commit e com o fluxo de trabalho no GitHub Actions.

Também vamos manipular um SAST, que é um teste de análise estática de uma aplicação voltada para a segurança. Para isso, usaremos uma ferramenta de SAST chamada SonarQube, a qual integraremos em nossa esteira de GitHub Actions para analisar uma aplicação API Rest.

Além disso, analisaremos os relatórios de segurança que o SonarQube gera e corrigiremos vulnerabilidades. Tudo isso será feito em cima da API Rest do VollMed, uma aplicação que faz o cadastro de médicos, pacientes e consultas.

Pré-requisitos

Para que você tenha uma melhor experiência acompanhando esse curso, seria interessante ter acompanhado toda a formação de desenvolvimento seguro até o momento. Também é recomendável ter noções básicas de controle de versão com Git e GitHub, saber trabalhar com workflows no GitHub Actions, gerenciar contêineres Docker e criar instâncias EC2 na AWS.

Apesar de parecer complexo, vamos abordar tudo passo a passo durante nosso projeto. Além disso, lembre-se de que temos toda a nossa comunidade no Discord e no fórum para fornecer suporte durante o curso. Aproveite todos os recursos que temos disponíveis além dos vídeos, como os da seção Para saber mais e as atividades.

Aguardamos você no próximo vídeo!

Scanning de Secrets com TruffleHog - Escaneando Secrets com o TruffleHog

Continuando o trabalho com a VollMed, nossa equipe de desenvolvimento tende a expandir cada vez mais, graças à escalabilidade que nossa aplicação oferece.

Contudo, a inspeção e correção de vulnerabilidades que fizemos manualmente ao longo do tempo não se torna tão viável quando o projeto cresce. Então, pensamos que seria útil ter algumas ferramentas para nos auxiliar na inspeção e gestão de vulnerabilidades. Felizmente, uma dessas ferramentas é a TruffleHog.

Escaneando secrets com o TruffleHog

Estamos com o repositório da TruffleHog aberto no GitHub. O nome do repositório é "trufflesecurity/trufflehog".

Analisando a documentação, no README.md, verificamos que esta ferramenta busca credenciais no nosso código. Ou seja, ela executa um scanning (varredura) de secrets (segredos), escaneando todo o nosso código em busca de segredos ou credenciais e apontando o que encontrou.

Abaixo na documentação, entendemos como ela funciona. Observando o demonstrativo, notamos que a execução é feita no terminal. Mais adiante, há instruções para instalação, seja para macOS, usando Docker ou baixando o binário da ferramenta. Para rodar no nosso projeto VollMed, vamos optar pela segunda alternativa com o Docker.

docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --repo https://github.com/trufflesecurity/test_keys

Precisamos ter o Docker instalado na máquina. O comando para execução é docker run, seguido de algumas flags como --rm, que indica que o container será removido após a execução dos comandos, e -it e -v, que determinam o modo interativo e verboso de visualização no terminal.

Depois, ele indica a pasta raiz do container, que vamos deixar como /pwd. Em seguida, é indicado o nome da imagem, que é trufflesecurity/trufflehog:latest para utilizar a última versão da ferramenta.

O comando termina especificando como informar nosso repositório, mesmo que seja através do GitHub. Nesse caso, usamos --repo seguido do link para o repositório do GitHub. Já temos o VollMed no GitHub e vamos usá-lo no comando.

docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --repo https://github.com/camilafernanda/3361-Curso-4-AppSec

A execução do comando pode demorar um pouco. No final, o scanning exibirá alguns segredos, entre os quais, uma chave privada. O TruffleHog nos diz que encontrou um resultado não verificado, que identifica como uma chave potencialmente perigosa para a segurança do VollMed.

Logo abaixo, são trazidas outras informações. A primeira delas é o Commit, onde a pessoa subiu a chave no GitHub. Temos também o Email da pessoa que subiu a chave, e o File, que seria a localização do arquivo. Conseguimos verificar isso na aba "Explorer": em "ssl_certificate", encontramos o arquivo chave-privada.pem.

Na sequência, temos o link a partir do qual conseguimos acessar no próprio GitHub, o Repository, e o Timestamp de quando a chave foi para o repositório.

Acima dessas informações, observamos outros arquivos com várias chaves semelhantes alocadas em package.lock.json. Todas as chaves acima estão nesse mesmo arquivo. Vamos acessar um dos links para conferir no GitHub o que é trazido do arquivo package-lock.json.

Será aberto automaticamente o arquivo package-lock.json, de dependências do Node, e foi trazida uma versão do semver do ESLint, uma ferramenta utilizada para programar em Node, com alguns padrões que precisam ser obedecidos na escrita do código.

Vamos pensar o seguinte: essa versão do semver traz algum secret? Alguma chave ou credencial que traz algum risco de vulnerabilidade para o VollMed? A resposta é não, então isso se caracteriza como um falso positivo.

Notamos que todas essas informações são públicas e estão relacionadas a dependências no npmjs. Portanto, elas não apresentam risco à segurança do VollMed. Nesse caso, podemos instruir o TruffleHog a ignorar todas as referências a package-lock.json, usando um comando no VS Code.

De volta ao comando anterior, vamos adicionar a flag --exclude-paths, onde podemos indicar uma lista que queremos que o TruffleHog ignore no VollMed. Para isso, na pasta raiz, vamos criar um novo arquivo chamado trufflehog-exclude-path.txt. Nesse arquivo, vamos trazer o package-lock.json e salvar.

trufflehog-exclude-path.txt:

package-lock.json

Com isso, temos justamente uma lista. Podemos colocar apenas o nome do arquivo e listar outros que podem apresentar algum problema de falso positivo. Agora, vamos indicar no comando a nossa pasta.

O trufflehog-exclude-path.txt, arquivo que criamos, está na pasta raiz. A pasta raiz do nosso container é a "pwd", então vamos digitar /pwd/trufflehog-exclude-path.txt.

docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --repo https://github.com/camilafernanda/3361-Curso-4-AppSec --exclude-paths=/pwd/trufflehog-exclude-path.txt

Vamos rodar novamente o comando e verificar se ele vai trazer novamente aqueles falsos positivos do package-lock.json, visto que ele não apresenta nenhum problema de segurança para nós.

O comando do trufflehog já carregou e trouxe apenas a chave privada, que não está privada, mas sim no repositório do GitHub, e não trouxe mais os falsos positivos.

Conclusão

É importante toda vez que rodarmos alguma ferramenta que gera relatório de segurança, analisar caso por caso e verificar se realmente é uma vulnerabilidade.

Precisamos avaliar esses falsos positivos, pois, por meio do relatório, o nosso time de pessoas desenvolvedoras tomará decisões sobre o nosso código, corrigindo essa vulnerabilidade. Portanto, precisamos analisar com calma todos os resultados.

Futuramente, vamos estudar essa chave no TruffleHog e conferir outras opções quando rodarmos essa ferramenta, algo que pode ajudar muito o dia a dia do nosso time de desenvolvimento!

Scanning de Secrets com TruffleHog - Automatizando o Trufflehog no GitHub Actions

Rodamos o TruffleHog na VollMed, uma ferramenta de scanning de secrets (segredos) para o nosso repositório. Porém, como seria o funcionamento para rodar este TruffleHog a cada vez que existir uma alteração no VollMed?

Automatizando o TruffleHog no GitHub Actions

As pessoas desenvolvedoras do nosso time teriam que, a cada alteração, rodar manualmente, conforme fizemos no terminal. Isso não é tão viável, já que precisam focar em diversas outras tarefas no setor de desenvolvimento.

Portanto, podemos automatizar todo esse comando por meio do GitHub Actions, criado justamente para automatizar fluxo de trabalhos no nosso workflow do GitHub.

Para fazer isso, abriremos uma nova pasta no nosso repositório, chamada ".github". Estamos com o VollMed aberto no VS Code. Clicamos no canto superior em "New Folder…" e nomeamos como ".github". Dentro desta pasta, adicionaremos outra chamada "workflows", onde iremos automatizar as tarefas.

Após criar esta pasta, podemos adicionar arquivos que possuam a extensão .yaml, que descreverão todos os passos para a automatização do nosso workflow. O primeiro arquivo que criaremos terá o nome trufflehog-scan.yaml.

Agora, podemos adicionar alguns atributos necessários, como o nome e quando as ações irão acontecer. Neste arquivo, adicionaremos o seguinte código:

trufflehog-scan.yaml:

name: TruffleHog Scan Test

on:
 pull_request:
   branches:
     - main

jobs:
 trufflehog:
   runs-on: ubuntu-latest

   steps:
    - name: Checkout repository
      uses: actions/checkout@v2

O atributo name é o nome da tarefa que vamos automatizar no workflow. O atributo on define quando essa tarefa será ativada, e, neste caso, a tarefa é ativada sempre que há uma pull_request na branch main. Tudo que colocarmos dentro de on precisa ter a indentação correta; caso contrário, o arquivo não funciona.

Note que identificamos como pull_request. Poderia ser push_request, mas é mais comum nas empresas fazer o pull_request antes de subir as alterações para a main, pois, geralmente, temos as reviews de todas as alterações feitas. Assim, ao fazer a solicitação para empurrar as alterações, será rodado o TruffleHog antes de ir para a branch main.

Em jobs, definimos o que será feito, isto é, o trabalho (trufflehog) que será realizado na última versão do Ubuntu (ubuntu-latest), onde o comando será rodado (runs-on).

Os passos para execução são detalhados em steps, que incluem primeiramente o Checkout repository, correspondente ao nome da etapa, e em seguida, o uses. O que isso indica? Como o GitHub vem primeiro no ambiente do VollMed, precisamos fazer o checkout para o ambiente do Ubuntu, onde vamos rodar o comando. Para isso, precisamos fazer o checkout indicado por actions/checkout@v2.

Tudo isso é padronizado para automatizarmos nossos passos. No entanto, ainda não colocamos o comando que rodamos com o Docker da imagem do TruffleHog. Então, adicionaremos um hífen para adicionar o name do próximo passo, no qual faremos todo o setup do TruffleHog, ou seja, faremos o pull da imagem Docker que usamos.

Faremos a importação da imagem usando um comando de terminal, portanto, adicionamos run logo abaixo de name. O comando será docker pull, através do qual puxaremos a imagem do TruffleHog, cujo nome já temos no comando rodado anteriormente. Vamos copiá-lo (trufflesecurity/trufflehog:latest) e colar após docker pull.

    - name: Set up TruffleHog
      run: |
        docker pull trufflesecurity/trufflehog:latest

Temos nosso setup pronto para rodar o TruffleHog e executar todo o comando que fizemos. Para isso, criaremos um novo item de name em steps chamado Run TruffleHog, que também irá rodar um comando. Vamos retornar ao terminal e copiar todo o comando que fizemos anteriormente. Em seguida, vamos colar após run.

    - name: Run TruffleHog
      id: trufflehog
      run: |
        docker run --rm -v $PWD:/pwd trufflesecurity/trufflehog:latest github --repo https://github.com/camilafernanda/3156-Curso-2-AppSec --exclude-paths=/pwd/trufflehog-exclude-path.txt

Agora temos todos os passos. Preparamos o ambiente e somente no final rodamos o TruffleHog. A ideia é que, ao fazer um pull_request, isso rode automaticamente.

O próximo passo é salvar este arquivo e subir no GitHub como um pull request para testar se está funcionando. Para isso, utilizaremos o comando git checkout com uma nova branch de feature do TruffleHog (-b feat/Trufflehog).

git checkout -b feat/Trufflehog

Em seguida, adicionaremos todas as alterações com git add ..

git add .

Feito isso, faremos um commit com uma mensagem (-m): "Feat: Trufflehog workflow".

git commit -m "Feat: Trufflehog workflow"

Após fazer o commit, podemos fazer o push.

git push origin feat/Trufflehog

Uma vez feito o push, será disponibilizado um link que podemos acessar para criar um pull request.

Depois de criado, acessaremos o pull request e poderemos verificar se nosso workflow está funcionando. Isso pode ser verificado na aba "Actions", onde estão todos os workflows, localizados na pasta ".github" criada anteriormente.

Conseguimos visualizar que nosso workflow já rodou. Identificamos ele com um ícone de carregamento amarelo antes, e agora temos um ícone em verde antes do título. Vamos acessar o workflow para conferir o que ele realizou.

Quando abrimos, conseguimos ver somente uma caixa, no arquivo trufflehog.scan.yaml, em um fundo preto, apresentando o nome e o tempo, que durou 13 segundos. Dentro do workflow, temos um ícone de verificado, o título trufflehog, e a duração de 13 segundos. Podemos acessar no centro da tela para obter mais informações de todos os logs e passos que aplicamos.

Então, tudo que aplicamos, como o "Set up job", o "Checkout repository", tudo mais que aplicamos, está bem detalhado. Portanto, você pode abrir para visualizar todos os logs, e recomendamos muito que você leia passo a passo o que aconteceu.

No "Run TruffleHog", o antepenúltimo passo, conseguimos identificar o mesmo comando que aplicamos no terminal, mas agora no GitHub. Ele trouxe tudo, a mesma resposta, a chave privada que ele encontrou, no GitHub de forma automatizada.

Conclusão

Com isso, as pessoas desenvolvedoras não precisam mais executar todo esse comando localmente, assim que houver cada alteração no nosso projeto!

Sobre o curso Desenvolvimento Seguro: implementando Secret Scanning e SAST na esteira de CI

O curso Desenvolvimento Seguro: implementando Secret Scanning e SAST na esteira de CI possui 166 minutos de vídeos, em um total de 54 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