Perché tenere i segreti in Git è rischioso e come Semaphore Key Store risolve il problema

Gli sviluppatori continuano a inserire token API, password e credenziali direttamente nel codice o in file .env e a pusharli su Git. Succede sia nei progetti personali che in produzione.

Il motivo è semplice: senza un modo corretto per passare i segreti ai flussi di automazione e deploy, Git sembra l’unica opzione affidabile. «Sistemiamo dopo». Ma in Git nulla sparisce davvero.

Perché Git è pericoloso per i segreti #

Git è un sistema di controllo versione. Tutto ciò che viene committato resta nella cronologia. Puoi rimuovere un token dall’ultimo commit: i commit precedenti lo contengono già. E la cronologia si copia ovunque: repository locali, agent di automazione, mirror, fork. Appena un segreto finisce in un commit, è esposto.

L’accesso al repository tende ad essere più ampio del necessario. Contractor esterni, contributori temporanei, fork di test: tutti potrebbero vedere credenziali che non dovrebbero.

GitHub e GitLab scansionano attivamente alla ricerca di credenziali. Se la piattaforma segnala un token, trattalo come compromesso e revocalo subito.

Cosa dovrebbe sostituire Git #

Un segreto non è un file statico. È una credenziale di accesso che deve vivere fuori dal codice, con permessi controllati, supporto alla rotazione e isolamento per ambiente.

Potresti usare Vault o OpenBao — ma significa infrastruttura, manutenzione e onere operativo.

Semaphore ha un Key Store integrato direttamente nei workflow di automazione. I segreti possono stare in uno di due posti:

• database crittografato di Semaphore (predefinito)
• archivio esterno come HashiCorp Vault, Devolutions o OpenBao (funzionalità PRO)

Scegli l’opzione integrata semplice oppure collega il sistema aziendale esistente. Funziona senza configurazioni complesse.

Cosa memorizza Key Store #

• token API
• chiavi SSH
• password
• variabili d’ambiente
• JSON e altri file di configurazione

I segreti non toccano mai la codebase. Vengono iniettati solo al runtime del job. Puoi definire credenziali separate per dev, staging e produzione e limitare l’accesso a utenti, team o workflow specifici.

Come funziona in pratica #

Crei un Key Store, aggiungi un segreto e lo referenzi nella configurazione del workflow. Semaphore inietta il valore a runtime.

Durante un deploy AWS, ad esempio, le chiavi di accesso esistono solo mentre gira quel job specifico, solo sull’agent che lo esegue. Gli sviluppatori non vedono il segreto. Non passa mai da Git.

Esempio #

Crea un secret dall’interfaccia: Secrets → New Secret, poi aggiungi le variabili:

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Referenzia il segreto per nome nel workflow — Semaphore inietta i valori come variabili d’ambiente a runtime:

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

Per SSH, crea un segreto con il file della chiave privata. Semaphore lo posiziona automaticamente in ~/.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 rispetto ad altri approcci #

Metodo	Sicuro	Visibilità	Revocabile
.env in Git	No	Tutto il team	No
GitHub Actions Secrets	Parziale	Dipende	Sì
Semaphore Key Store	Sì	Limitata	Sì

In più: ruotare i token senza toccare il codice, controllare l’accesso per ruolo o team, segreti diversi per ambiente.

Conclusione #

Ogni token committato in Git va considerato compromesso. La cronologia si propaga tra contributor, fork, mirror e agent di automazione: ogni copia è un altro punto di esposizione.

Key Store tiene i segreti fuori dai repository, li inietta solo a runtime e ti dà controllo su rotazione e accesso. Per team che usano Ansible, Terraform, OpenTofu o PowerShell non è infrastruttura opzionale: è la base.

Twitter

Opzione 1

Segreti in Git = segreti esposti. Per sempre.

La cronologia Git si replica su fork, mirror e agent CI. Un token in un commit è un token compromesso a tempo indeterminato.

Abbiamo spiegato perché succede ancora — e come Semaphore Key Store risolve il problema.

Opzione 2

Come Semaphore Key Store gestisce i segreti:

→ Memorizzare token, chiavi SSH e variabili d’ambiente fuori dal repo

→ Referenziare con {{ your_secret }} nella config del job

→ Iniettare a runtime, sull’agent, solo per quel job

Gli sviluppatori non lo vedono. Non tocca mai Git.
Approfondimento → [link]

LinkedIn

Abbiamo pubblicato un approfondimento su come funziona Semaphore Key Store — e perché esiste.

In sintesi: i segreti non appartengono a Git. Mai. Ma senza un’alternativa adeguata, gli sviluppatori continuano a metterceli.

Key Store si integra direttamente nei workflow di automazione di Semaphore. Il flusso è:

1. Creare un Key Store nell’interfaccia
2. Aggiungere i segreti — token API, chiavi SSH, variabili d’ambiente, file di config
3. Referenziarli nella config del job con {{ your_secret }}
4. Semaphore li inietta a runtime, sull’agent, solo per quel job

Lo sviluppatore non vede il segreto. Non tocca il repository. A fine job sparisce dall’ambiente di esecuzione.

Puoi limitare l’accesso per utente, team o ambiente. Ruotare un token senza cambiare una riga di codice. Usare credenziali separate per dev, staging e prod.

Per team su Ansible, Terraform o OpenTofu — è il pezzo mancante tra «funziona» e «è davvero sicuro».

Approfondimento →