06 - Supply Chain Security - SBOM e Sigstore per Artifact Integrity

Supply Chain Security: Proteggere la Catena del Software

La supply chain security nel software si riferisce alla protezione dell'intero processo di creazione, distribuzione e consumo del software. Gli attacchi alla supply chain sono in crescita esponenziale: compromettere un singolo componente nella catena permette di colpire migliaia di organizzazioni a valle.

L'attacco SolarWinds del 2020 e l'incidente XZ Utils del 2024 hanno dimostrato quanto la supply chain sia vulnerabile. In questo articolo esploreremo gli standard e gli strumenti per proteggere la catena del software: SBOM per l'inventario dei componenti, Sigstore per la firma degli artifact e il framework SLSA per la verifica della provenienza.

SBOM: Software Bill of Materials

Un SBOM (Software Bill of Materials) e un inventario completo di tutti i componenti che compongono un software: librerie, framework, tool e le loro versioni esatte. Come una lista ingredienti per il cibo, l'SBOM permette di sapere esattamente cosa c'e dentro il software.

L'SBOM e diventato un requisito legale in molti contesti: l'Executive Order 14028 degli Stati Uniti lo richiede per i fornitori del governo federale, e le normative europee (NIS2, Cyber Resilience Act) lo stanno rendendo obbligatorio per i prodotti digitali venduti nell'UE.

Standard SBOM: CycloneDX vs SPDX

Generare SBOM con Syft

# Installare Syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh

# Generare SBOM da un'immagine Docker (CycloneDX)
syft myapp:latest -o cyclonedx-json > sbom-cyclonedx.json

# Generare SBOM in formato SPDX
syft myapp:latest -o spdx-json > sbom-spdx.json

# Generare SBOM dal filesystem locale
syft dir:. -o cyclonedx-json > sbom-project.json

# Generare SBOM da un lock file
syft file:package-lock.json -o cyclonedx-json > sbom-deps.json
      

SBOM nella Pipeline CI/CD

# .github/workflows/sbom.yml
name: SBOM Generation
on:
  push:
    branches: [main]
    tags: ["v*"]

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

      - name: Build Docker image
        run: docker build -t myapp:${{ github.sha }} .

      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          image: myapp:${{ github.sha }}
          format: cyclonedx-json
          output-file: sbom.json

      - name: Upload SBOM as artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.json

      - name: Attach SBOM to release
        if: startsWith(github.ref, 'refs/tags/')
        uses: softprops/action-gh-release@v1
        with:
          files: sbom.json
      

Sigstore: Firma degli Artifact

Sigstore e un progetto della Linux Foundation che fornisce strumenti per la firma crittografica e la verifica degli artifact software. L'obiettivo e rendere la firma del software facile come il commit del codice, eliminando la complessità della gestione delle chiavi.

Sigstore si compone di tre componenti principali:

• Cosign: firma e verifica di container image e artifact OCI
• Fulcio: Certificate Authority che emette certificati effimeri basati su identità OIDC
• Rekor: transparency log immutabile che registra tutte le firme

# .github/workflows/sign-and-verify.yml
name: Sign and Publish
on:
  push:
    tags: ["v*"]

jobs:
  build-sign-publish:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write  # Necessario per Sigstore keyless
    steps:
      - uses: actions/checkout@v4

      - name: Install Cosign
        uses: sigstore/cosign-installer@v3

      - name: Login to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and Push
        id: build
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/myorg/myapp:${{ github.ref_name }}

      - name: Sign image (keyless)
        run: cosign sign --yes ghcr.io/myorg/myapp@${{ steps.build.outputs.digest }}

      - name: Attach SBOM
        run: |
          syft ghcr.io/myorg/myapp@${{ steps.build.outputs.digest }} -o cyclonedx-json > sbom.json
          cosign attach sbom --sbom sbom.json ghcr.io/myorg/myapp@${{ steps.build.outputs.digest }}
      

SLSA Framework

SLSA (Supply-chain Levels for Software Artifacts), pronunciato "salsa", e un framework di sicurezza che definisce livelli crescenti di garanzia sulla provenienza e l'integrita degli artifact software. Sviluppato da Google, SLSA definisce 4 livelli:

VEX: Vulnerability Exploitability eXchange

VEX e un formato che permette ai produttori di software di comunicare se una vulnerabilità nota in un componente e effettivamente sfruttabile nel loro prodotto. Questo riduce il rumore per i consumatori che altrimenti dovrebbero triagare ogni CVE manualmente.

Best Practice per Supply Chain Security

1. Generare SBOM per ogni release: automatizzare la generazione e l'allegazione dell'SBOM ad ogni rilascio
2. Firmare tutti gli artifact: usare Cosign/Sigstore per firmare immagini container, binari e SBOM
3. Verificare le firme al deploy: configurare admission controller che rifiutano immagini non firmate
4. Monitorare le dipendenze: usare l'SBOM per ricevere alert immediati quando viene scoperta una nuova CVE
5. Raggiungere SLSA 3+: implementare build isolati con provenienza verificabile
6. Pubblicare VEX: comunicare lo stato delle vulnerabilità ai consumatori del software

Conclusioni

La supply chain security e diventata un imperativo per ogni organizzazione che sviluppa software. SBOM, Sigstore e SLSA forniscono gli strumenti e i framework per costruire una catena del software trasparente, verificabile e resistente agli attacchi.

Nel prossimo articolo esploreremo Secret Management, analizzando come gestire credenziali, API key e certificati in modo sicuro con HashiCorp Vault e strategie di rotazione automatica.