09 - CI/CD Security Pipeline - Securing the Build and Deploy Process

CI/CD Security: Proteggere il Processo di Build e Deploy

La pipeline CI/CD e il cuore del processo di delivery del software. Se un attaccante compromette la pipeline, può iniettare codice malevolo in ogni build e deploy successivo. La sicurezza della pipeline non riguarda solo cosa la pipeline testa, ma come la pipeline stessa e protetta da manomissioni.

In questo articolo esploreremo le pratiche per rendere sicura la pipeline CI/CD: dal branch protection ai signed commits, dall'OIDC al least privilege, fino all'audit logging e all'approval workflow per i deploy in produzione.

Threat Model della Pipeline CI/CD

Per proteggere la pipeline, dobbiamo capire dove sono le superfici di attacco:

• Codice sorgente: un contributor malevolo inietta codice in una PR
• Dipendenze: una dipendenza compromessa viene installata durante il build
• Pipeline configuration: modifica dei workflow file per esfiltrare secret
• Runner: compromissione del build agent per persistenza nell'infrastruttura
• Artifact: sostituzione dell'artifact build con uno malevolo
• Deploy credentials: furto delle credenziali di deploy per accesso diretto all'infrastruttura

Branch Protection Rules

Le branch protection rules sono la prima linea di difesa. Garantiscono che nessun codice raggiunga il branch principale senza review e controlli automatici.

OIDC: Autenticazione Senza Secret Statici

OpenID Connect (OIDC) permette ai workflow CI/CD di autenticarsi con i cloud provider senza utilizzare secret statici (API key, service account key). Il workflow ottiene un token temporaneo basato sull'identità del repository e del branch.

# .github/workflows/deploy-oidc.yml
name: Deploy with OIDC
on:
  push:
    branches: [main]

permissions:
  id-token: write   # Necessario per OIDC
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS Credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-deploy
          aws-region: eu-west-1
          # Nessun secret! Il token OIDC viene usato automaticamente

      - name: Deploy to AWS
        run: |
          aws s3 sync dist/ s3://my-bucket/
          aws cloudfront create-invalidation --distribution-id E123 --paths "/*"
      

Least Privilege per Workflow

Ogni workflow GitHub Actions ha permessi predefiniti che possono essere troppo ampi. Il principio del least privilege richiede di limitare i permessi al minimo necessario per ogni job:

# Permessi globali restrittivi
permissions:
  contents: read  # Solo lettura del repository

jobs:
  test:
    runs-on: ubuntu-latest
    # Nessun permesso aggiuntivo per i test
    steps:
      - uses: actions/checkout@v4
      - run: npm test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    permissions:
      id-token: write      # Solo per OIDC
      contents: read
      packages: write      # Solo per push immagini
    environment: production  # Richiede approvazione manuale
    steps:
      - uses: actions/checkout@v4
      - name: Deploy
        run: ./deploy.sh
      

Signed Commits

I signed commits garantiscono l'identità del contributor attraverso la firma crittografica GPG o SSH. Senza firma, chiunque può creare un commit con un nome e email arbitrari, impersonando altri developer.

# Configurare GPG per signed commits
gpg --full-generate-key
gpg --list-secret-keys --keyid-format=long

# Configurare Git per firmare automaticamente
git config --global user.signingkey YOUR_KEY_ID
git config --global commit.gpgsign true
git config --global tag.gpgsign true

# Alternativa: firmare con SSH key
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
      

Deployment Approval Workflows

I deploy in produzione dovrebbero richiedere approvazione esplicita da parte di persone autorizzate. GitHub Environments permette di configurare approvazioni manuali obbligatorie:

# Deploy con approvazione manuale
jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - name: Deploy to staging
        run: ./deploy.sh staging

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://myapp.com
    # Richiede approvazione da un reviewer designato
    steps:
      - name: Deploy to production
        run: ./deploy.sh production

      - name: Notify team
        run: |
          curl -X POST "${{ secrets.SLACK_WEBHOOK }}" \
            -H "Content-Type: application/json" \
            -d '{"text": "Production deploy completed successfully"}'
      

Pipeline Security Hardening Checklist

Pinning delle GitHub Actions

# INSICURO: usa un tag mutabile
- uses: actions/checkout@v4

# SICURO: usa il commit SHA (immutabile)
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
      

Best Practice per CI/CD Security

1. OIDC everywhere: eliminare tutti i secret statici per l'autenticazione ai cloud provider
2. Minimal permissions: ogni job ha solo i permessi necessari, niente di più
3. Pin actions by SHA: mai usare tag mutabili per le actions di terze parti
4. Separate environments: staging e production con configurazioni e approvazioni diverse
5. Audit everything: log di ogni build, deploy, approvazione e modifica alla pipeline
6. Ephemeral runners: i runner devono essere ricreati ad ogni job per evitare persistenza

Conclusioni

La sicurezza della pipeline CI/CD e spesso trascurata, ma e un vettore di attacco critico. Una pipeline compromessa può iniettare codice malevolo in ogni build successivo. Con branch protection, OIDC, least privilege e deployment approvals, si costruisce una pipeline resiliente e verificabile.

Nel prossimo articolo esploreremo IaC Scanning, analizzando come validare le configurazioni Terraform, CloudFormation e ARM per prevenire misconfiguration di sicurezza.