Nel contesto moderno dello sviluppo software, l’automazione tramite pipeline CI/CD è diventata uno standard. Ma con l’aumento della velocità arriva anche un aumento del rischio, specialmente per quanto riguarda la sicurezza delle API key e di altri secret sensibili.

In questo articolo vedremo come si verificano i leak di credenziali nelle pipeline DevOps e le best practice per proteggersi, con esempi reali e consigli pratici.

Cos’è un API Key Leak in CI/CD?

Un API key leak si verifica quando una credenziale sensibile viene esposta accidentalmente in un contesto non sicuro: log, file di configurazione, commit, o artefatti di build.

Nel contesto di CI/CD (Continuous Integration / Continuous Deployment), questi leak sono spesso il risultato di pipeline mal configurate, in cui variabili d’ambiente o file contenenti secret non sono gestiti correttamente.

Cause Comuni di API Key Leak

1. Variabili d’Ambiente Stampate nei Log

Un errore comune è stampare direttamente le variabili nei log della pipeline:

- name: Stampare variabile (NON SICURO)
  run: echo "API_KEY=${{ secrets.API_KEY }}"

Questi log possono essere accessibili pubblicamente o conservati troppo a lungo, diventando un rischio.

2. Commit Accidentali di File Sensibili

Molti leak avvengono per colpa di commit contenenti:

  • .env

  • config.js

  • secrets.yaml

Anche con .gitignore, errori umani o git add -f possono forzare l’aggiunta di file pericolosi.

3. Artifact e Build Contaminati

File generati (es. .zip, .tar.gz, container Docker) possono contenere:

  • Token embedded

  • Configurazioni errate

  • Log con secret esposti

Un attacker che scarica questi file può facilmente estrarre le chiavi.

4. Token di Accesso con Permessi Eccessivi

È frequente generare token con permessi amministrativi usati nelle pipeline per comodità. Ma se quel token viene compromesso, un attacker può:

  • Modificare il codice

  • Accedere a sistemi cloud

  • Creare ulteriori backdoor

 

Come Proteggere i Secret in CI/CD

1. Mascherare le Variabili nei Log

Sistemi come GitHub Actions o GitLab CI permettono di marcare i secret come "masked" per evitare che vengano stampati nei log.

2. Usare Secret Manager Esterni

Esempi:

  • GitHub Actions Secrets

  • AWS Secrets Manager

  • Doppler

  • Azure Key Vault

  • HashiCorp Vault

Evita di salvare i secret direttamente nel repository o in chiaro nei file .yaml.

3. Scansione Automatica dei Secret nel Codice

Strumenti consigliati:

Integra questi tool direttamente nel flusso CI per scansionare ogni push.

4. Rotazione Regolare dei Secret

Stabilisci policy per ruotare le chiavi periodicamente, come parte del ciclo di sicurezza.

5. Regola i Permessi

Applica il principio del minimo privilegio:

  • Un secret per ogni scopo

  • Scope limitati

  • Nessun permesso superfluo


Caso Reale: Mining Criptovalute su Cloud AWS

Nel 2024, una chiave AWS venne esposta nel log di una GitHub Actions. In meno di 12 ore, un bot automatico ha usato la chiave per lanciare istanze EC2 e minare criptovalute, generando oltre 300€ di spese cloud.

Questi attacchi sono spesso automatizzati: i bot monitorano in tempo reale le piattaforme pubbliche come GitHub per cercare secret esposti.

 

Checklist Finale: Sicurezza CI/CD

  • Mai stampare secret nei log

  • Usa strumenti di secret management

  • Scansiona ogni commit per secret esposti

  • Limita i permessi dei token

  • Ruota i secret periodicamente

  • Pulisci gli artifact e le build pubbliche

 

Conclusione

I secret leak tramite CI/CD sono tra le vulnerabilità più subdole perché non dipendono da un bug nel codice, ma da cattive pratiche operative. Investire nella sicurezza delle pipeline è fondamentale per proteggere le applicazioni moderne.