Vai al contenuto

Catena di approvvigionamento

A partire dalla versione 1.0.0, le immagini container che Turbo EA pubblica su GHCR contengono metadati verificabili della catena di approvvigionamento, in modo che gli operatori possano confermare che un'immagine proviene dal CI di questo progetto prima di distribuirla in produzione.

Questa pagina descrive cosa viene firmato, come verificarlo, dove si trova il SBOM e come si inserisce la scansione Trivy (attualmente informativa).

Cosa viene firmato

Ogni immagine costruita da .github/workflows/docker-publish.yml e inviata a ghcr.io/vincentmakes/turbo-ea/<immagine> è firmata con cosign usando OIDC senza chiave: non esiste una chiave di firma a lunga durata. Il certificato viene emesso da Fulcio di Sigstore per l'identità del workflow, registrato nel registro di trasparenza pubblico Rekor e rimosso non appena la firma viene creata.

Immagini firmate:

  • ghcr.io/vincentmakes/turbo-ea/db
  • ghcr.io/vincentmakes/turbo-ea/backend
  • ghcr.io/vincentmakes/turbo-ea/frontend
  • ghcr.io/vincentmakes/turbo-ea/nginx
  • ghcr.io/vincentmakes/turbo-ea/mcp-server

L'immagine ollama viene ricostruita manualmente al di fuori della matrix e non è attualmente firmata. Se dipendete dal profilo Ollama incluso e avete bisogno della verifica, costruitela dal codice sorgente.

La firma si applica al digest della lista di manifesti OCI, quindi una singola firma copre in modo trasparente sia linux/amd64 che linux/arm64.

Verifica di un'immagine

Installate cosign, poi:

cosign verify \
  --certificate-identity-regexp 'https://github.com/vincentmakes/turbo-ea/.+' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  ghcr.io/vincentmakes/turbo-ea/backend:1.0.0

Cosa fanno i parametri:

  • --certificate-identity-regexp — accetta qualsiasi percorso di workflow in questo repository. Per maggiore rigore, sostituite con --certificate-identity 'https://github.com/vincentmakes/turbo-ea/.github/workflows/docker-publish.yml@refs/tags/v1.0.0'.
  • --certificate-oidc-issuer — fissa l'emittente OIDC all'endpoint dei token di GitHub. Una firma emessa da qualsiasi altro emittente (es. il CI di un fork) fallirà la verifica.

Una verifica riuscita stampa il payload firmato e un URL nel registro di trasparenza Rekor. Un fallimento termina con codice non zero — fate fallire il vostro deploy su di esso.

Potete anche verificare per digest, che è la forma più rigorosa (immune alla rimappatura dei tag):

DIGEST=$(docker buildx imagetools inspect ghcr.io/vincentmakes/turbo-ea/backend:1.0.0 --format '{{ .Manifest.Digest }}')
cosign verify \
  --certificate-identity-regexp 'https://github.com/vincentmakes/turbo-ea/.+' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  ghcr.io/vincentmakes/turbo-ea/backend@${DIGEST}

SBOM

Un software bill of materials SPDX viene generato automaticamente da buildkit (sbom: true nel passaggio di build) e allegato a ogni immagine come referente OCI. Non è necessaria alcuna installazione aggiuntiva.

Recuperatelo con:

docker buildx imagetools inspect --format '{{ json .SBOM }}' \
  ghcr.io/vincentmakes/turbo-ea/backend:1.0.0 | jq .

Il SBOM elenca tutti i pacchetti osservati da buildkit nell'immagine finale (pacchetti apk, wheel Python, moduli Node, ecc.) con versioni e URL sorgente.

Scansione delle vulnerabilità (Trivy)

Il workflow di pubblicazione esegue Trivy contro ogni immagine costruita per CVE HIGH e CRITICAL e carica il risultato come SARIF nella scheda Security del repository.

La scansione è attualmente non bloccante (exit-code: 0). Se i risultati di Trivy sono rilevanti per il vostro ambiente, eseguite il vostro scanner sull'immagine scaricata. Il SBOM pubblicato è un input pulito.

Per i contributori: se individuate una vulnerabilità genuinamente sfruttabile, segnalatela tramite un avviso di sicurezza privato anziché in un issue pubblico.

Blocco degli SHA delle Actions

Ogni GitHub Action utilizzata dal workflow di pubblicazione è bloccata a un SHA di commit di 40 caratteri, non a un tag di versione principale mobile. Gli aggiornamenti transitano tramite Dependabot per l'ecosistema github-actions con cadenza mensile.