Secrets en repositoris: com es filtren i com evitar-ho

Un secret (clau d'API, token, contrasenya de base de dades) pujat a un repositori públic cal donar-lo per compromès des del primer segon. Hi ha bots que llegeixen el flux de commits públics de GitHub en temps real buscant patrons de claus. I esborrar la línia al commit següent no arregla res: la clau continua a l'historial. L'única cosa que funciona és revocar-la i rotar-la.

GitGuardian, al seu informe State of Secrets Sprawl de 2025, va comptar més de 23 milions de secrets nous exposats en commits públics de GitHub durant el 2024. I no és només cosa de projectes personals: molts surten de repositoris d'empreses.

Per on s'escapen

• El .env que no era al .gitignore, o que s'hi va afegir després d'haver-lo comès una vegada.
• La clau «temporal» al codi per provar alguna cosa ràpid, que s'hi queda.
• Fitxers de configuració d'exemple amb valors reals en lloc de marcadors.
• Logs i sortides de CI que imprimeixen variables d'entorn.
• Un repositori privat que es fa públic anys després, amb tot el seu historial.

Detectar-los abans del push

El millor moment per trobar un secret és abans que surti de la teva màquina. Un hook de pre-commit amb gitleaks revisa cada commit i el bloqueja si hi troba alguna cosa:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.4
    hooks:
      - id: gitleaks

Al mateix GitHub, la push protection del secret scanning rebutja el push si detecta un patró d'un proveïdor conegut, i està activa per defecte als repositoris públics des del 2024. En aquest mateix portfolio hi ha un test de PHPUnit (NoSecretsTest) que recorre els fitxers versionats i falla si hi troba una clau d'API. Un hook local es pot saltar amb --no-verify; un test que corre a CI, no.

Revisar l'historial que ja existeix

Per a repositoris amb anys d'historial, gitleaks i TruffleHog escanegen tots els commits. TruffleHog a més pot verificar si una clau trobada continua sent vàlida, cosa que ajuda a prioritzar.

gitleaks detect --source . --log-opts="--all"

Si ja s'ha filtrat

1. Revocar i rotar primer. Abans que netejar l'historial. Cada minut compta.
2. Revisar els logs del servei afectat per veure si algú l'ha fet servir des que es va pujar. En una clau d'AWS, CloudTrail filtrant per aquell access key ID.
3. Netejar l'historial amb git filter-repo si el repositori és teu, sabent que qualsevol fork o clon anterior conserva la clau. Per això el pas 1 va primer.
4. Buscar la causa perquè no es repeteixi: faltava el .gitignore? No hi havia hook?

La solució de fons: que no hi hagi secrets per filtrar

Com menys secrets estàtics existeixin, menys n'hi ha per protegir. Un gestor de secrets (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) en lloc de fitxers, i a CI/CD federació OIDC en lloc de claus: GitHub Actions pot demanar credencials temporals a AWS o Azure sense guardar cap clau al repositori. I l'opció més segura continua sent no necessitar credencials: kev-digest només llegeix un catàleg públic, així que corre a Actions sense cap secret de tercers per protegir.

Preguntes freqüents

N'hi ha prou amb fer el repositori privat?

No. Qualsevol persona amb accés al repositori, o qualsevol integració amb permisos de lectura, veu el secret. I si algú el va clonar mentre era públic, ja el té.

Esborrar el commit elimina la clau?

No de manera fiable. El commit pot continuar accessible pel seu hash, en forks, en caches i en clons. Cal revocar la clau sempre.

Quina eina faig servir per començar?

gitleaks com a hook de pre-commit i a CI, més push protection a GitHub. Les dues són gratuïtes.