Por que guardar segredos no Git é arriscado e como o Semaphore Key Store resolve o problema

Os desenvolvedores ainda codificam tokens de API, palavras-passe e credenciais diretamente no código ou em ficheiros .env e fazem push para o Git. Acontece em projetos pequenos e em produção.

A razão é simples: sem uma forma adequada de passar segredos para a automação e para os fluxos de implementação, o Git parece a única opção fiável. «Arrumamos mais tarde.» Mas no Git nada desaparece de verdade.

Porque o Git é perigoso para segredos #

O Git é um sistema de controlo de versões. Tudo o que é commitado faz parte do histórico. Pode remover um token do último commit — os commits anteriores já o contêm. E o histórico replica-se por todo o lado: repositórios locais, agentes de automação, espelhos, forks. No momento em que um segredo entra num commit, fica exposto.

O acesso ao repositório tende a ser mais amplo do que devia. Contratados externos, contribuidores temporários, forks de teste — todos podem ver credenciais que não deviam.

O GitHub e o GitLab procuram ativamente credenciais. Se a plataforma assinalar um token, trate-o como comprometido e revogue-o de imediato.

O que deve substituir o Git #

Um segredo não é um ficheiro estático. É uma credencial de acesso que deve viver fora da base de código, com permissões controladas, rotação e isolamento por ambiente.

Pode usar Vault ou OpenBao — mas isso implica infraestrutura, manutenção e trabalho de operações.

O Semaphore tem um Key Store integrado diretamente nos fluxos de automação. Os segredos podem ficar num de dois sítios:

• base de dados encriptada do Semaphore (predefinição)
• armazém externo como HashiCorp Vault, Devolutions ou OpenBao (funcionalidade PRO)

Escolha a opção integrada simples ou ligue o sistema corporativo de segredos. Funciona sem configuração pesada.

O que o Key Store guarda #

• tokens de API
• chaves SSH
• palavras-passe
• variáveis de ambiente
• JSON e outros ficheiros de configuração

Os segredos nunca tocam na base de código. São injetados apenas em tempo de execução do job. Pode definir credenciais separadas para desenvolvimento, staging e produção e restringir o acesso a utilizadores, equipas ou fluxos específicos.

Como funciona na prática #

Cria um Key Store, adiciona um segredo e referencia-o na configuração do workflow. O Semaphore injeta o valor em tempo de execução.

Numa implementação na AWS, por exemplo, as chaves de acesso existem apenas enquanto esse job corre, apenas no agente que o executa. Os programadores não veem o segredo. Nunca passa pelo Git.

Exemplo #

Crie um segredo na interface: Secrets → New Secret e adicione as variáveis:

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Referencie o segredo pelo nome no workflow — o Semaphore injeta os valores como variáveis de ambiente em tempo de execução:

blocks:
  - name: Deploy
    task:
      secrets:
        - name: aws-credentials
      jobs:
        - name: deploy
          commands:
            - aws s3 sync ./dist s3://my-bucket

Para SSH, crie um segredo com o ficheiro da chave privada. O Semaphore coloca-o automaticamente em ~/.ssh/:

blocks:
  - name: Deploy via SSH
    task:
      secrets:
        - name: production-ssh-key
      jobs:
        - name: deploy
          commands:
            - ssh deploy@production-server "cd /app && git pull"

Key Store face a outras abordagens #

Método	Seguro	Visibilidade	Revogável
.env no Git	Não	Toda a equipa	Não
GitHub Actions Secrets	Parcial	Depende	Sim
Semaphore Key Store	Sim	Restrita	Sim

Além disso: rodar tokens sem alterar código, controlar acesso por função ou equipa, segredos diferentes por ambiente.

Conclusão #

Qualquer token commitado no Git deve ser tratado como comprometido. O histórico propaga-se por colaboradores, forks, espelhos e agentes — cada cópia é mais um ponto de exposição.

O Key Store mantém segredos fora dos repositórios, injeta-os apenas em tempo de execução e dá controlo sobre rotação e acesso. Para equipas com Ansible, Terraform, OpenTofu ou automação em PowerShell não é infraestrutura opcional: é a base.

Twitter

Opção 1

Segredos no Git = segredos expostos. Para sempre.

O histórico do Git replica-se por forks, espelhos e agentes de CI. Um token num commit é um token comprometido por tempo indefinido.

Explicámos porque isto continua a acontecer — e como o Semaphore Key Store resolve.

Opção 2

Como o Semaphore Key Store trata os segredos:

→ Guardar tokens, chaves SSH e variáveis de ambiente fora do repositório

→ Referenciar com {{ your_secret }} na configuração do job

→ Injetar em tempo de execução, no agente, só para esse job

Os programadores não veem. Nunca toca no Git.
Análise completa → [ligação]

LinkedIn

Acabámos de publicar uma análise de como o Semaphore Key Store funciona — e porque existe.

Em resumo: segredos não pertencem ao Git. Nunca. Mas sem uma alternativa séria, as equipas continuam a colocá-los lá.

O Key Store integra-se diretamente nos fluxos de automação do Semaphore. O fluxo real:

1. Criar um Key Store na interface
2. Adicionar segredos — tokens API, chaves SSH, variáveis de ambiente, ficheiros de configuração
3. Referenciá-los na configuração do job com {{ your_secret }}
4. O Semaphore injeta-os em tempo de execução, no agente, só para esse job

O programador não vê o segredo. Não toca no repositório. Quando o job termina, desaparece do ambiente de execução.

Pode restringir o acesso por utilizador, equipa ou ambiente. Rodar um token sem alterar uma linha de código. Credenciais separadas para dev, staging e prod.

Para equipas com Ansible, Terraform ou OpenTofu — é a peça em falta entre «funciona» e «é realmente seguro».

Análise completa →