Aller au contenu

Chaîne d'approvisionnement

À partir de la version 1.0.0, les images de conteneurs publiées par Turbo EA sur GHCR contiennent des métadonnées de chaîne d'approvisionnement vérifiables permettant aux opérateurs de confirmer qu'une image provient du CI de ce projet avant de la déployer en production.

Cette page couvre ce qui est signé, comment le vérifier, où se trouve le SBOM, et comment le scan Trivy (actuellement informatif) s'intègre.

Ce qui est signé

Chaque image construite par .github/workflows/docker-publish.yml et poussée vers ghcr.io/vincentmakes/turbo-ea/<image> est signée avec cosign en utilisant OIDC sans clé : il n'existe pas de clé de signature à longue durée de vie. Le certificat est émis par Fulcio de Sigstore pour l'identité du workflow, enregistré dans le journal de transparence public Rekor, et supprimé dès que la signature est créée.

Images signées :

  • 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'image ollama est reconstruite manuellement hors de la matrix et n'est actuellement pas signée. Si vous dépendez du profil Ollama inclus et avez besoin d'une vérification, construisez-la depuis les sources.

La signature s'applique au digest de la liste de manifestes OCI, de sorte qu'une seule signature couvre de manière transparente linux/amd64 et linux/arm64.

Vérification d'une image

Installez cosign, puis :

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

Ce que font les paramètres :

  • --certificate-identity-regexp — accepte tout chemin de workflow dans ce dépôt. Pour plus de rigueur, remplacez par --certificate-identity 'https://github.com/vincentmakes/turbo-ea/.github/workflows/docker-publish.yml@refs/tags/v1.0.0'.
  • --certificate-oidc-issuer — fixe l'émetteur OIDC au point de terminaison de jetons de GitHub. Une signature émise par tout autre émetteur (p. ex. le CI d'un fork) échouera à la vérification.

Une vérification réussie affiche le payload signé et une URL d'entrée dans le journal de transparence Rekor. Un échec se termine avec un code non nul — faites échouer votre déploiement sur cette base.

Vous pouvez également vérifier par digest, ce qui est la forme la plus stricte (immunisée contre la réaffectation de tags) :

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

Une nomenclature logicielle SPDX est générée automatiquement par buildkit (sbom: true dans l'étape de build) et attachée à chaque image en tant que référent OCI. Aucune installation supplémentaire n'est requise.

Récupérez-la avec :

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

Le SBOM liste tous les paquets observés par buildkit dans l'image finale (paquets apk, wheels Python, modules Node, etc.) avec leurs versions et URLs sources.

Analyse de vulnérabilités (Trivy)

Le workflow de publication exécute Trivy contre chaque image construite pour les CVEs HIGH et CRITICAL et téléverse le résultat en SARIF dans l'onglet Security du dépôt.

L'analyse est actuellement non bloquante (exit-code: 0). Si les résultats Trivy sont importants pour votre environnement, exécutez votre propre scanner contre l'image tirée. Le SBOM publié est une entrée propre.

Pour les contributeurs : si vous détectez une vulnérabilité genuinement exploitable, signalez-la via un avis de sécurité privé plutôt que dans un problème public.

Épinglage des SHA d'Actions

Chaque GitHub Action utilisée par le workflow de publication est épinglée à un SHA de commit de 40 caractères, et non à un tag de version majeure flottant. Les mises à jour transitent par Dependabot pour l'écosystème github-actions avec une cadence mensuelle.