Em setembro de 2026, autoridades do Japão, Estados Unidos, Austrália e Alemanha assinaram um alerta conjunto sobre uma campanha batizada de WaterPlum: mais de 30 mil dispositivos de programadores infetados em mais de 100 países, através de falsas entrevistas de emprego que terminavam com malware instalado no computador da vítima. O grupo chegou a controlar cerca de 10,71 milhões de dólares em criptomoeda, saqueados de mais de 7 mil carteiras digitais. O FBI, através do escritório de Honolulu, confirmou o alvo: programadores, engenheiros web e especialistas em blockchain (SecurityWeek).

O caso ilustra um problema que já não é marginal. Segundo o relatório State of Secrets Sprawl da GitGuardian, publicado em 2026, foram encontrados 28,65 milhões de novos segredos (chaves de API, tokens, palavras-passe) em commits públicos do GitHub durante 2025, um aumento de 34% em relação ao ano anterior. Em 2024 o número já tinha sido de 23,77 milhões, com uma subida de 25% (GitGuardian). É neste contexto que três ferramentas se tornaram referência para detetar segredos antes que saiam do controlo de uma equipa: GitGuardian, Gitleaks e Semgrep Secrets.

Este artigo compara as três opções em profundidade: preços, cobertura de deteção, integração em pipelines de CI/CD, casos reais de 2025 e 2026, e um guia prático para quem quer adotar uma delas sem travar a equipa de desenvolvimento. A pergunta que se repete em equipas técnicas portuguesas e internacionais é sempre a mesma. Vale a pena pagar por uma plataforma comercial ou o scanner open source já chega?

A resposta curta é “depende do tamanho da equipa e da exposição pública da organização”, mas a resposta longa exige olhar para números concretos. Uma equipa de dez pessoas a trabalhar num produto interno tem um perfil de risco muito diferente de uma empresa com centenas de colaboradores, repositórios públicos, forks de terceiros e integrações com múltiplos fornecedores cloud. As três ferramentas aqui comparadas foram pensadas para públicos distintos dentro desse espetro, e é por isso que raramente faz sentido perguntar apenas “qual é melhor” sem primeiro definir o contexto.

O que são ferramentas de deteção de segredos e porque importam

Uma ferramenta de deteção de segredos (“secrets detection” ou “secrets scanning”) procura, no código-fonte, no histórico do Git, em pull requests e por vezes em ficheiros de configuração, padrões que correspondem a credenciais: chaves da AWS, tokens do Slack, palavras-passe de bases de dados, chaves privadas SSH ou segredos de serviços de inteligência artificial. O objetivo é simples de descrever e difícil de executar bem: encontrar o segredo antes que um atacante o encontre primeiro.

O problema cresce com a adoção de ferramentas de IA. O relatório da GitGuardian identificou 1.275.105 segredos de serviços de IA expostos publicamente em 2025, um salto de 81% em relação a 2024, e 24.008 segredos únicos encontrados em ficheiros de configuração do protocolo MCP (Model Context Protocol) espalhados pelo GitHub (GitGuardian). Entre os tipos de segredos mais comuns, 58% caem na categoria “genérica” (tokens sem formato previsível, difíceis de detetar com regras fixas), contra 49% em 2023. As chaves da AWS continuam a liderar entre as credenciais nomeadas, seguidas de webhooks do Slack e chaves de API do Azure AD.

Para quem desenvolve software todos os dias, o cenário típico é familiar: um programador precisa de testar rapidamente uma integração com um serviço externo, cola uma chave de API diretamente no código para “resolver depois” e, três semanas mais tarde, esse commit já foi enviado para um repositório partilhado, incluído numa pull request e, em alguns casos, publicado sem querer num fork público. A credencial continua válida, o programador já esqueceu que a colocou ali, e ninguém a revogou. É este o intervalo exato que as ferramentas de deteção de segredos tentam fechar, de preferência antes do commit sair da máquina local.

Há uma distinção técnica que separa boas ferramentas de ferramentas medianas: detetar um segredo não é o mesmo que confirmar que ele ainda está ativo, e remover uma linha de código não revoga a credencial que ela continha. Rever o histórico completo do Git, validar se o segredo ainda funciona junto do fornecedor (AWS, GitHub, Stripe) e automatizar a rotação são capacidades que separam GitGuardian, Gitleaks e Semgrep Secrets de forma relevante, como se vê já a seguir.

Vale ainda separar três momentos distintos no ciclo de vida de um segredo exposto: a deteção (encontrar o padrão no código ou no histórico), a validação (confirmar se a credencial ainda funciona) e a remediação (revogar, rotar e documentar o incidente). Muitas equipas investem apenas na primeira etapa e assumem que o trabalho está feito, quando na realidade um alerta sem validação nem rotação associada tende a acumular-se numa fila que ninguém trata. É precisamente nessa segunda e terceira etapa que GitGuardian e Semgrep Secrets se diferenciam do Gitleaks, que cobre sobretudo a primeira.

GitGuardian: deteção comercial, monitorização pública e governação de identidades

A GitGuardian nasceu como uma plataforma especializada em segredos e cresceu para cobrir também a chamada “NHI Governance” (governação de identidades não-humanas), um termo que a própria empresa usa para descrever a gestão de chaves de serviço, tokens de máquina a máquina e contas de automação que raramente aparecem nos inventários tradicionais de identidade.

Segundo a página oficial de preços, a plataforma distingue dois produtos: Internal Secrets Monitoring, para repositórios privados, e Public Secrets Monitoring, para detetar segredos de uma organização que acabaram expostos em repositórios públicos de terceiros, cobrados por número de “developers publicamente ativos” em vez de por repositório (GitGuardian). Um terceiro, o site de avaliações G2, descreve o plano gratuito como capaz de identificar mais de 350 tipos de segredos específicos, genéricos e personalizados para equipas até 25 programadores.

Entre as funcionalidades de destaque estão os “honeytokens” incluídos no plano Enterprise (credenciais falsas plantadas de propósito para detetar acessos indevidos), playbooks de remediação a partir do plano Business, e scan completo do histórico Git até 12 GB por repositório. A plataforma funciona em modo SaaS ou self-hosted, com suporte a deployment dedicado apenas no tier superior. Para equipas que já lidam com auditorias de conformidade, a vantagem de ter tudo centralizado numa consola única costuma pesar mais do que o custo adicional face a um scanner gratuito.

O conceito de honeytoken merece um parágrafo próprio porque inverte a lógica habitual de deteção. Em vez de esperar que um atacante use uma credencial real roubada, a equipa planta uma credencial falsa, sem qualquer função legítima, dentro do código ou da infraestrutura. Se essa credencial for usada, o alerta é praticamente garantido como verdadeiro positivo, porque não existe nenhuma razão legítima para ela estar ativa. É uma técnica de deteção de intrusão mais do que de prevenção, e está disponível apenas no tier mais caro da GitGuardian, o que limita o seu uso a organizações com orçamento de segurança mais robusto. Já o scan de histórico Git até 12 GB por repositório cobre a maioria dos projetos empresariais, mas pode ficar curto em monorepos de grande escala, um detalhe que vale confirmar antes de assinar um contrato anual.

Gitleaks: o scanner open source que domina os pipelines de CI/CD

O Gitleaks é um scanner de linha de comandos, escrito em Go, totalmente gratuito e distribuído sob licença MIT. Em outubro de 2026, o repositório soma 29.658 estrelas e 2.263 forks no GitHub, números que o colocam entre os projetos de segurança mais populares da categoria (GitHub). Não existe camada paga obrigatória: a ferramenta corre localmente, em pre-commit hooks ou integrada em qualquer pipeline de CI/CD sem custos de licenciamento.

Tecnicamente, o Gitleaks combina expressões regulares com verificação de entropia para detetar padrões de credenciais em cada commit, branch ou pull request. A instalação é direta e qualquer equipa consegue correr uma primeira análise em minutos:

# instalar via Homebrew (macOS/Linux)
brew install gitleaks

# analisar todo o histórico de um repositório
gitleaks detect --source . --verbose

# usar como gate num pipeline de CI, falhando o build se encontrar um segredo
gitleaks detect --source . --exit-code 1

A simplicidade é também a principal limitação. O Gitleaks não valida se uma credencial encontrada ainda está ativa, não tem consola central para gerir alertas entre vários repositórios e não oferece governação de identidades nem monitorização de exposições públicas fora dos repositórios que a própria equipa decide analisar. Para uma equipa pequena ou para um projeto open source, isso raramente é um problema. Para uma organização com centenas de repositórios e exigências de conformidade como a NIS2, a ausência de um painel centralizado começa a pesar.

Outro ponto a considerar é a manutenção das regras de deteção. O ficheiro de configuração do Gitleaks (gitleaks.toml) permite adicionar expressões regulares próprias para cobrir formatos de credenciais internas, algo útil para empresas com sistemas legados ou tokens proprietários que nenhuma ferramenta comercial cobre por padrão. A contrapartida é que essa manutenção fica inteiramente a cargo da equipa: não há um fornecedor a atualizar regras automaticamente sempre que surge um novo formato de chave de um serviço de IA, por exemplo. Isso explica por que razão muitas organizações usam o Gitleaks como primeira camada, barata e rápida, e reservam uma ferramenta comercial para a camada de monitorização contínua e validação.

Semgrep Secrets: deteção com validação ativa dentro de uma plataforma AppSec maior

O Semgrep nasceu como motor de análise estática de código (SAST) e hoje vende uma plataforma AppSec completa, com quatro módulos: Code, Supply Chain, Secrets e capacidades assistidas por IA para triagem e correção. O motor de código aberto por trás do produto, hospedado em github.com/semgrep/semgrep, está licenciado sob LGPL 2.1 e acumula 16.867 estrelas e 1.084 forks em outubro de 2026.

É importante não confundir o motor Semgrep (gratuito e open source) com o módulo Secrets, que é um produto comercial da camada SaaS da empresa. Segundo a página oficial de preços, o plano gratuito cobre até 10 contribuidores e 10 repositórios, com os módulos Code e Supply Chain a custo zero. O módulo Secrets custa 15 dólares por contribuidor por mês quando comprado isoladamente dentro do plano Teams, que arranca nos 30 dólares por contribuidor por mês já incluindo Code e Supply Chain. O plano Enterprise é feito por cotação (Semgrep).

A diferença técnica que a empresa mais destaca é a validação ativa: em vez de apenas sinalizar um padrão que parece uma chave da AWS, o Semgrep Secrets tenta confirmar junto do fornecedor se a credencial ainda está ativa, reduzindo o volume de alertas que acabam ignorados por serem falsos positivos ou chaves já revogadas. Essa camada de triagem assistida por IA é o principal argumento de venda face a um scanner puramente baseado em regras, como o Gitleaks.

Na prática operacional, isto significa que um alerta do Semgrep Secrets chega à equipa já classificado como “credencial confirmada ativa” ou “credencial provavelmente inativa”, em vez de uma simples lista de padrões suspeitos sem priorização. Para equipas de segurança pequenas, que não têm tempo para investigar manualmente cada alerta de um scanner tradicional, essa triagem automática pode ser o fator decisivo. A desvantagem simétrica é a dependência de uma infraestrutura SaaS: não existe opção self-hosted para o Semgrep Secrets, o que pode ser um impedimento para organizações do setor público ou financeiro com políticas estritas de residência de dados, um tema especialmente relevante à luz das obrigações impostas pela NIS2 em Portugal.

Tabela comparativa de especificações

A tabela seguinte resume as características principais das três ferramentas, com dados recolhidos diretamente das páginas oficiais e dos repositórios públicos em outubro de 2026.

CaracterísticaGitGuardianGitleaksSemgrep Secrets
Modelo de licenciamentoComercial (SaaS/self-hosted)Open source (MIT)Comercial (módulo da plataforma Semgrep)
Custo de entrada$0, até 25 programadores$0, sem limite$0, até 10 contribuidores/10 repositórios
Tipos de segredos detetados350+ (específicos, genéricos, personalizados)Regras pré-definidas + entropia, configuráveisRegras proprietárias + validação ativa
Scan de histórico GitSim, até 12 GB por repositório (Business)Sim, todo o histórico localSim, dentro do fluxo CI/CD
Validação de credenciais ativasParcial, por integraçãoNãoSim, validação ativa junto do fornecedor
Monitorização de repositórios públicos de terceirosSim (Public Secrets Monitoring)NãoNão
Honeytokens / deteção de intrusãoSim (plano Enterprise)NãoNão
Self-hosted / on-premiseSim (Enterprise)Sim (é um binário local)Não (SaaS)
Integração CI/CD nativaSim (GitHub Actions, GitLab CI, Jenkins)Sim (qualquer pipeline via CLI)Sim (GitHub Actions, GitLab CI)
Pre-commit hookSimSimSim
Deteção de segredos de IA/MCPSim (categoria dedicada no relatório 2026)Depende de regras personalizadasSim, via módulo Code + Secrets combinados
Estrelas no GitHub (projeto principal)Não aplicável (produto fechado)29.65816.867 (motor open source)
Suporte dedicado / SLASim (Enterprise)Comunidade (sem SLA)Sim (Enterprise)

Preços: do plano gratuito ao contrato empresarial

Nenhuma das três empresas publica uma tabela de preços totalmente transparente para os planos superiores, o que é comum no mercado de segurança empresarial. Ainda assim, há dados concretos suficientes para comparar o ponto de entrada e a estrutura de cada plano.

PlanoGitGuardianGitleaksSemgrep Secrets
Gratuito$0 – até 25 programadores, scan em tempo real ilimitado, 500 deteções históricas$0 – sem limite de utilizadores ou repositórios$0 – até 10 contribuidores e 10 repositórios (Code + Supply Chain)
IntermédioBusiness – cotação, até 20 equipas, playbooks de remediação, scan até 12 GBNão existe (projeto sem camada paga)Teams – a partir de $30/contribuidor/mês (Code+Supply Chain), Secrets +$15/contribuidor/mês
EmpresarialEnterprise – cotação, honeytokens, self-hosted, equipas e API ilimitadasNão existeEnterprise – cotação, SSO, suporte dedicado
Suporte pago/consultoriaIncluído a partir do BusinessNenhum oficial (apenas comunidade)Incluído a partir do Enterprise

Na prática, uma equipa de dez programadores que só precise de bloquear commits com segredos óbvios não paga nada em nenhuma das três opções. O custo só aparece quando entram em jogo requisitos como monitorização de repositórios públicos de terceiros, validação automática de credenciais ou relatórios de conformidade para auditores, exatamente os pontos em que GitGuardian e Semgrep Secrets cobram por contribuidor ou por equipa.

Benchmarks e dados de deteção: o que os números realmente mostram

Não existe, até à data de publicação deste artigo, um benchmark independente e público que teste as três ferramentas sob o mesmo corpus de segredos, com métricas comparáveis de precisão, recall e taxa de falsos positivos. Qualquer afirmação do tipo “a ferramenta X deteta mais do que a Y” sem essa base é, na prática, marketing. O que existe são três conjuntos de dados que, juntos, dão uma imagem razoável do problema que as três ferramentas tentam resolver.

Primeiro, os números de escala da GitGuardian: 28,65 milhões de segredos novos detetados em commits públicos do GitHub em 2025, um crescimento de 34% sobre 2024, que por sua vez já tinha crescido 25% sobre 2023 (GitGuardian State of Secrets Sprawl 2026). O mesmo relatório estima que a exploração ativa de uma credencial exposta pode começar dentro de horas após a publicação, não dias ou semanas, o que torna qualquer atraso na deteção um risco concreto.

Segundo, os números de adoção open source: 29.658 estrelas do Gitleaks contra 16.867 do motor Semgrep no GitHub, uma diferença que reflete públicos distintos. O Gitleaks é adotado maioritariamente por quem quer um scanner leve e sem custos. O Semgrep atrai equipas que já usam a ferramenta para SAST e decidem expandir para segredos dentro da mesma plataforma.

Terceiro, os dados de cobertura por categoria: 58% dos segredos encontrados em 2025 pela GitGuardian eram “genéricos” (sem formato fixo e por isso mais difíceis de regrar), e a categoria de segredos ligados a serviços de IA cresceu 81% num só ano, para 1,27 milhões de ocorrências. Isto é relevante para avaliar qualquer ferramenta: um scanner com boa cobertura de chaves da AWS pode continuar fraco a detetar tokens genéricos de uma API de IA lançada há seis meses, simplesmente porque ainda não existe uma regra específica para esse formato.

Esta limitação metodológica não é um detalhe menor para quem decide com base neste artigo ou em qualquer outro material de marketing do setor. Um fornecedor pode legitimamente contar “350 tipos de segredos” somando todas as variações de formato de uma única credencial (por exemplo, diferentes prefixos de chaves da AWS), enquanto outro conta por família de fornecedor. Sem uma definição comum, comparar o número total de detetores entre GitGuardian, Gitleaks e Semgrep Secrets é como comparar maçãs com peras com o mesmo nome. A recomendação mais honesta para qualquer equipa técnica é testar as três ferramentas com os próprios repositórios, usando os planos gratuitos disponíveis, antes de decidir qual delas captura melhor os segredos reais que circulam no código da organização.

Casos reais de 2025 e 2026: quando o segredo escapa

Cinco episódios recentes mostram como a exposição de segredos em código e pipelines passou de risco teórico a incidente recorrente.

  • Campanha WaterPlum (setembro de 2026): hackers associados à Coreia do Norte infetaram mais de 30 mil dispositivos de programadores em mais de 100 países, entre dezembro de 2025 e julho de 2026, através de falsas entrevistas de emprego técnico. O grupo chegou a controlar cerca de 10,71 milhões de dólares em criptomoeda roubados de mais de 7 mil carteiras digitais (SecurityWeek).
  • Repositório “Private-CISA” exposto (maio de 2026): um contratante associado à Nightwing manteve, entre novembro de 2025 e maio de 2026, um repositório público no GitHub com cerca de 844 MB de histórico interno, incluindo credenciais administrativas da AWS GovCloud, um ficheiro de texto com tokens da AWS, palavras-passe em texto simples e chaves SSH. A CISA confirmou a exposição mas disse não ter encontrado provas de que sistemas sensíveis tenham sido comprometidos.
  • Compromisso de pipeline CI do LiteLLM (2026): o grupo TeamPCP comprometeu o pipeline de integração contínua do projeto LiteLLM, expondo credenciais que cobriam GitHub, npm, AWS, Google Cloud, Azure, HashiCorp Vault, SSH e bases de dados, segundo relatos de agosto de 2026. O mesmo grupo esteve associado a outro incidente que afetou ferramentas como Bitwarden, Trivy e Checkmarx.
  • Crescimento de segredos de IA expostos (relatório 2026): a GitGuardian documentou 1.275.105 segredos de serviços de IA encontrados publicamente em 2025, mais 81% do que em 2024, e 24.008 segredos únicos em ficheiros de configuração MCP, um sinal de que a corrida à adoção de agentes de IA está a abrir uma nova categoria de exposição.
  • Crescimento sustentado de segredos genéricos (2023 a 2025): a proporção de segredos “genéricos” sem formato fixo subiu de 49% em 2023 para 58% em 2025, segundo a GitGuardian, confirmando que depender apenas de regras para padrões conhecidos (como o prefixo “AKIA” das chaves da AWS) deixa cada vez mais espaço para fuga de credenciais personalizadas.

Nenhum destes casos prova, isoladamente, que GitGuardian, Gitleaks ou Semgrep Secrets teria impedido o incidente. Mas todos partilham o mesmo padrão: uma credencial ficou visível em código, configuração ou histórico de Git, e ninguém a detetou a tempo. É exatamente esse intervalo entre exposição e deteção que as três ferramentas tentam fechar.

Prós e contras de cada ferramenta

GitGuardian

  • Prós: consola centralizada, monitorização de exposições em repositórios públicos de terceiros, honeytokens para detetar intrusões, mais de 350 tipos de segredos cobertos, plano gratuito generoso para equipas pequenas.
  • Contras: preços dos planos Business e Enterprise só disponíveis por cotação, o que dificulta orçamentar antecipadamente. Funcionalidades avançadas de governação de identidades ficam concentradas no tier mais caro.

Gitleaks

  • Prós: totalmente gratuito e open source (MIT), instalação simples, funciona offline, integra-se em qualquer pipeline sem depender de uma conta SaaS, comunidade grande (quase 30 mil estrelas no GitHub).
  • Contras: sem validação de credenciais ativas, sem painel central para gerir várias equipas ou repositórios, sem suporte comercial com SLA, configuração de regras personalizadas exige trabalho manual.

Semgrep Secrets

  • Prós: validação ativa de credenciais reduz falsos positivos, faz parte de uma plataforma AppSec mais ampla (Code, Supply Chain, Secrets), triagem assistida por IA, plano gratuito cobre equipas pequenas.
  • Contras: módulo Secrets tem custo adicional mesmo dentro do plano Teams ($15/contribuidor/mês), não existe opção self-hosted, preço por contribuidor pode escalar rápido em equipas grandes.

Guia de migração: como adotar deteção de segredos sem travar a equipa

Adotar qualquer uma destas ferramentas de forma abrupta, bloqueando todos os commits a partir do primeiro dia, costuma gerar resistência imediata da equipa de desenvolvimento. Quem já passou por uma migração deste tipo sabe que o maior risco não é técnico, é cultural: se o primeiro contacto de um programador com a ferramenta for um build vermelho e um alerta que parece bloquear o trabalho sem explicação, a tendência natural é tentar contornar a regra em vez de corrigir o problema de raiz. Um caminho mais realista segue cinco etapas.

  1. Auditoria inicial em modo silencioso. Corra o Gitleaks (ou o scanner gratuito do GitGuardian ou do Semgrep) sobre todo o histórico dos repositórios principais, sem bloquear nada, apenas para medir a dimensão real do problema.
  2. Triagem e rotação imediata. Qualquer segredo confirmado como ativo deve ser revogado e substituído de imediato, independentemente de o remover do código. Apagar a linha não invalida a credencial.
  3. Pre-commit hook antes do CI. Adicione o scanner como hook local (por exemplo com gitleaks protect --staged ou o hook oficial do Semgrep) antes de o impor no pipeline central, para que os programadores vejam o alerta antes do push.
  4. Gate obrigatório no CI/CD. Só depois de a equipa se habituar aos alertas locais é que faz sentido falhar o build em CI quando um segredo novo é detetado, evitando que o bloqueio pareça arbitrário.
  5. Monitorização contínua e exposição pública. Para organizações com presença pública relevante, ativar a monitorização de repositórios de terceiros (disponível na GitGuardian) cobre o cenário em que um colaborador publica código fora do controlo da organização, por exemplo num fork pessoal.

Equipas que já usam o Snyk, Dependabot ou Socket para dependências, ou o Trivy, Syft e Cosign para imagens de contentores e SBOM, tendem a preferir um scanner de segredos que se integre no mesmo painel, o que favorece a GitGuardian ou o Semgrep face a um Gitleaks isolado. Para quem já tem um agente de IA a gerir partes do fluxo de código, vale também rever riscos documentados em falhas como o GitSpawn, que afetou configurações Git de assistentes de programação.

Um erro comum nesta fase é tratar a deteção de segredos como um projeto isolado de segurança, sem envolver as equipas de engenharia na definição das regras. Na prática, quem melhor conhece os formatos de credenciais internas (tokens de serviços proprietários, por exemplo) é a própria equipa de desenvolvimento, não o departamento de segurança. Os projetos de migração que correm melhor são os que criam um canal rápido para os programadores assinalarem falsos positivos e ajustarem regras, em vez de depender só de uma lista de exceções gerida centralmente e sem contexto técnico.

Casos de uso recomendados

A escolha certa depende menos de “qual é a melhor ferramenta” e mais de que problema concreto a equipa está a tentar resolver agora. Vale a pena mapear primeiro o tamanho da equipa, o número de repositórios ativos, a exposição pública da organização e a existência (ou não) de obrigações de conformidade formais antes de escolher.

  • Projeto open source ou equipa individual: Gitleaks, pelo custo zero e pela instalação simples via CLI, sem dependência de conta SaaS.
  • Startup com menos de 25 programadores: plano gratuito da GitGuardian, que já cobre scan em tempo real ilimitado e 500 deteções históricas sem custo.
  • Equipa que já usa Semgrep para SAST: ativar o módulo Secrets dentro da mesma plataforma, evitando gerir uma ferramenta extra e um painel adicional.
  • Empresa regulada por NIS2 ou com obrigações de auditoria: GitGuardian Business ou Enterprise, pelos playbooks de remediação, honeytokens e relatórios centralizados exigidos em auditorias de conformidade.
  • Organização com marca pública forte (exposta a forks e colaboradores externos): Public Secrets Monitoring da GitGuardian, para detetar segredos que escaparam para repositórios fora do controlo direto da equipa.
  • Equipa com múltiplos clouds e forte dependência de CI/CD complexo: combinação de Gitleaks como gate gratuito no pipeline com GitGuardian ou Semgrep Secrets para validação ativa e cobertura de histórico mais profunda.
  • Agência governamental ou fornecedor de infraestrutura crítica: plataforma comercial com opção self-hosted e sem dependência de terceiros para armazenar segredos detetados, um requisito que a GitGuardian cobre no plano Enterprise e que o Semgrep Secrets, por ser puramente SaaS, não oferece.

Veredicto: qual escolher com base nos dados

Não há um vencedor único porque as três ferramentas competem em segmentos diferentes. O Gitleaks ganha em custo e simplicidade: é gratuito, open source, soma 29.658 estrelas no GitHub e corre em qualquer pipeline sem depender de uma conta externa. É a escolha certa quando o objetivo é apenas bloquear o óbvio, sem orçamento para licenças.

A GitGuardian ganha em profundidade e governação: cobre mais de 350 tipos de segredos, monitoriza exposições fora da organização e oferece honeytokens, um conjunto de funcionalidades que o Gitleaks não tenta replicar. O custo é a falta de transparência nos preços dos planos pagos, que exigem contacto comercial.

O Semgrep Secrets ganha quando a equipa já vive dentro do ecossistema Semgrep para análise estática de código: ativar o módulo Secrets por 15 dólares por contribuidor por mês custa menos do que gerir uma ferramenta separada, e a validação ativa de credenciais reduz o ruído de alertas falsos. Para quem parte do zero e não usa Semgrep para mais nada, a soma dos módulos Code, Supply Chain e Secrets pode ficar mais cara do que o equivalente noutras plataformas.

Com 28,65 milhões de segredos novos encontrados em código público só em 2025 e exploração ativa possível dentro de horas após a exposição, segundo a própria GitGuardian, a pergunta relevante em 2026 já não é se vale a pena correr um scanner de segredos. É qual combinação de ferramentas cobre melhor o perfil de risco específico da equipa, e com que rapidez consegue responder quando, não se, uma credencial escapar.

Para a maioria das equipas que estão a começar do zero, a recomendação prática é instalar o Gitleaks ainda esta semana, por ser gratuito e rápido de configurar, e usar o resultado dessa primeira auditoria para decidir se a escala do problema justifica subir para uma plataforma comercial. Se a auditoria revelar poucos segredos antigos e uma equipa pequena, o Gitleaks sozinho pode chegar durante muito tempo. Se revelar centenas de credenciais dispersas por dezenas de repositórios, múltiplas equipas e exposição pública real, o investimento num plano pago da GitGuardian ou num módulo Secrets do Semgrep deixa de ser um luxo e passa a ser, simplesmente, o custo de operar com responsabilidade.

Perguntas frequentes

O Gitleaks é mesmo totalmente gratuito, sem limites escondidos?

Sim. O Gitleaks é distribuído sob licença MIT e não existe camada paga, limite de utilizadores ou de repositórios. Todo o custo fica do lado da infraestrutura onde a equipa decide correr o scanner, localmente ou dentro do próprio CI/CD.

Qual destas ferramentas deteta mais segredos?

Não existe um benchmark independente público que compare diretamente a precisão das três ferramentas sob o mesmo conjunto de testes. A GitGuardian publica um número elevado de tipos de segredos cobertos, mais de 350, mas cobertura de tipos não é o mesmo que taxa de deteção real num repositório específico.

Preciso de pagar para ter deteção de segredos no meu pipeline de CI/CD?

Não necessariamente. O Gitleaks é gratuito e cobre o essencial de um gate em CI. Os planos gratuitos da GitGuardian, até 25 programadores, e do Semgrep, até 10 contribuidores e 10 repositórios, também chegam para equipas pequenas sem custo nenhum.

O que significa “validação ativa” de uma credencial?

É a verificação, junto do próprio fornecedor, por exemplo a AWS ou o GitHub, de que uma credencial detetada no código ainda está ativa e funcional, em vez de assumir que qualquer padrão parecido com uma chave é um risco real. O Semgrep Secrets destaca esta capacidade como diferencial comercial.

Remover o segredo do código já resolve o problema?

Não. Apagar a linha de código ou mesmo reescrever o histórico do Git não revoga a credencial junto do fornecedor que a emitiu. É preciso rotar ou revogar a chave diretamente no serviço em questão, como AWS, Stripe ou Slack, para eliminar o risco por completo.

Estas ferramentas também detetam segredos usados por agentes de IA ou configurações MCP?

A GitGuardian já trata esta categoria como prioridade, tendo documentado mais de 1,27 milhões de segredos de serviços de IA expostos em 2025 e mais de 24 mil segredos únicos em ficheiros de configuração MCP. O Gitleaks e o Semgrep conseguem cobrir estes casos através de regras personalizadas, mas sem uma categoria dedicada tão específica.

Posso usar o Gitleaks e a GitGuardian ao mesmo tempo?

Sim, e é uma combinação comum. Muitas equipas usam o Gitleaks como gate rápido e gratuito em pre-commit hooks e no CI, e reservam a GitGuardian ou o Semgrep Secrets para monitorização contínua, validação de credenciais e relatórios centralizados a nível organizacional.

Como se compara isto com uma falha de configuração de API, como as cobertas no OWASP Top 10?

São riscos relacionados mas distintos. Um segredo exposto em código é uma credencial concreta que um atacante pode usar diretamente. Uma falha de configuração, como as descritas no OWASP Top 10 e detalhadas no artigo sobre a atualização do OWASP Top 10 2025 vs 2021, pode abrir uma porta de entrada sem que exista necessariamente uma credencial roubada envolvida.