Como evitar e identificar vazamentos de secrets com GitLeaks

Os times de Segurança e Infraestrutura gastam uma verdadeira fábula na aquisição de produtos de segurança. Agora imagine que, com apenas um commit desavisado, você tornasse disponível na internet as chaves que abrem todas as trancas de segurança? Vazamentos de segredo – em código – é uma das principais brechas de segurança em empresas de tecnologia. E no post de hoje vamos descobrir como evitar e identificar vazamentos de secrets com gitleaks.

Mas antes…

O que é uma secret?

Por mais simples que seja essa pergunta, a resposta não é trivial. Partindo do básico, secret é todo e qualquer dado sensível que, se vazado, pode fragilizar a segurança de um ambiente. Logo, você pode deduzir imediatamente que as senhas de acesso aos recursos da sua solução são secrets. E não haveria erro na sua resposta. Com brilhantismo, você poderia continuar dizendo que as chaves privadas também são secrets. E parabéns! Eu não diria melhor. Mas só isso?

Secret é todo e qualquer dado sensível que, se vazado, pode fragilizar a segurança de um ambiente

Refletindo melhor sobre o corolário anterior – sobre fragilizar um ambiente – também seria possível inferir que o endereço de um servidor, a porta em que ele está disponível ou qual a solução que está sendo utilizada são informações que fragilizam a segurança. Afinal, de posse dessas informações, uma pessoa com más intenções poderia pesquisar as falhas pontualmente daquele serviço e explorá-las. Então tudo é secret?

Depende. É preciso que você faça a boa e velha continha do trade-off. Atualizar secrets costuma ser uma tarefa burocrática (e com razão). Logo, quanto tempo você pode esperar e o poder de personalização que você deseja dar para sua aplicação? Respondida essa pergunta, responda a outra: Vale a pena aumentar essa parcela de risco dado o benefício? Senhas, sem dúvida, são inegociáveis. Agora, informações de infra podem passar por esse trade-off.

Um último ponto é: SECRETS NÃO VÃO PARA O FRONTEND. Se você tem algum código, chave, ou o que for, que é incorporada ao código transpilado do front, você não pode considerar essa informação um segredo. Afinal, o usuário poderia facilmente ter acesso a ela. NUNCA envie secrets para o front.

O que é GitLeaks?

Agora que já sabemos o que é uma secret, acho que você já realizou que secrets e código tem uma relação íntima. E quem nunca commitou uma Connection String por engano? É aqui que entra o GitLeaks.

GitLeaks é uma ferramenta capaz de vasculhar todos os commits da sua aplicação em busca de secrets. Através de uma série de expressões regulares, armazenadas em um arquivo .toml, ele vasculha cada commit, buscando por matches para as expressões configuradas. O GitLeaks também produz um relatório detalhado com o possível vazamento, e atrelado a cada ocorrência, um fingerprint. Dessa forma, você pode optar por: apagar o texto identificado ou adicionar o fingerprint ao arquivo .gitleaksignore, que diz quais textos devem ser ignorados em cada commit.

Mas nem sempre você precisa vasculhar o repositório inteiro. Principalmente porque deixaria o processo de busca muito lento. Por isso, o GitLeaks também permite buscar por vazamentos apenas no commit atual. Dessa forma, ao adotar o GitLeaks, é interessante você rodar a ferramenta uma vez para todos os commits. E só então adicionar um step na sua pipeline, que valida a presença de vazamentos por cada commit/branch.

Como rodar o GitLeaks localmente?

Você pode baixar e compilar o GitLeaks direto na sua máquina. Basta que você baixe o repositório oficial da ferramenta e execute o make build. Eu particularmente prefiro a opção via Docker.

No terminal, digite o comando:

docker run -v $(pwd):/path zricethezav/gitleaks:latest detect --source="/path" -c /path/ gitleaks-azure.toml

Onde:

• -v $(pwd) :/path mapeia o código da sua aplicação para um repositório interno da imagem Docker;
• detect é o comando que detecta as secrets no código
• --source identifica, dentro da imagem, onde o código fonte está e deve ser analisado.
• -c: fornece um arquivo de configuração personalizado;

Existem mais opções e você pode encontrá-las da seguinte forma:

docker run zricethezav/gitleaks:latest --help

Como rodar o GitLeaks no Azure DevOps?

Antes, precisamos agradecer ao @joost_voskuil, que criou e disponibilizou gratuitamente um step para as pipelines do Azure DevsOps. E não apenas isso: ele também escreveu – e mantém – uma versão atualizada do arquivos de configuração .toml, voltado para o desenvolvimento .Net. Ao @josst_voskuil, nosso muito obrigado 😊

Então, a primeira coisa a se fazer é tornar disponível o gitleaks na sua organização, clicando no botão “Get It Free” da página https://marketplace.visualstudio.com/items?itemName=Foxholenl.Gitleaks&ssr=false#overview

Desta forma, estará disponível a task Gitleaks@2 no Azure Devops.

  - task: Gitleaks@2
    inputs:
      scanlocation: "$(Build.SourcesDirectory)"
      configtype: "custom"
      configfile: "$(Build.SourcesDirectory)gitleaks.toml"
      ${{ if eq(variables['Build.Reason'], 'PullRequest') }}:
        scanmode: "prevalidation"
      ${{ else }}:
        scanmode: "changes"
      taskfail: $(parameters.taskFail)
      taskfailonexecutionerror: false
      redact: true
      uploadresults: true
      reportformat: "sarif"
      reportname: "GITLEAKS SCAN"
      verbose: true

Onde:

• scanlocation: Path para onde o código está;
• configtype: Você pode usar a configuração padrão – que não é necessariamente voltada para aplicações .net ou utilizar uma configuração custom;
• configfile: path para o arquivo .toml. No exemplo, estou definindo uma versão própria. Mas você pode utilizar as versões pré-definidas pelo autor. Basta que você use a configuração configfile: predefined e predefinedconfigfile: UDMSecretChecksv8.toml;
• scanmode: É sobre a forma como o escaneamento será feito. No exemplo acima, faço o prevalidation quando estou rodando essa task em um PullRequest. Nas demais situações, o escaneamento se baseia apenas nas diferenças entre os commits.
• redact: Faz com que as secrets encontradas fiquem ocultas no log da pipeline ou nos relatórios gerados.

Para maiores detalhes, você pode visitar:  https://github.com/jessehouwing/azure-devops-gitleaks

O que fazer quando encontrar vazamentos?

Quando você encontrar vazamentos, procure removê-los do código imediatamente. Procure tomar cuidado com os “falso-positivos”. Mesmo não sendo senhas reais, eles podem refletir algum padrão que coloque em risco a segurança das informações. Utilize placeholder caso realmente tenha que salvar algo no código. Nunca senhas ou segredos reais. No caso de reais “falso-positivos”, você pode configurá-los no arquivo .gitleaksignore.

Você pode, também, ter a péssima surpresa de ter secrets armazenadas no seu histórico. Nesse caso, elas também precisam ser removidas. Para isso, existe uma ótima ferramenta, que você conhecerá nesse site: https://rtyley.github.io/bfg-repo-cleaner/. Siga essas instruções e você terá repositórios livre vazamentos.

Contudo lembre-se: Ferramentas de análise estática estão sempre sujeitas a falhas. Por isso é importante que, durante o code review, esta etapa também seja assegurada pelas pessoas em revisão.