Lieferkette¶
Ab Version 1.0.0 enthalten die von Turbo EA auf GHCR veröffentlichten Container-Images überprüfbare Lieferketten-Metadaten, mit denen Betreiber vor dem Einspielen in die Produktion bestätigen können, dass ein Image aus dem CI dieses Projekts stammt.
Diese Seite beschreibt, was signiert wird, wie die Überprüfung erfolgt, wo sich das SBOM befindet und wie der (derzeit informationelle) Trivy-Scan eingebunden ist.
Was signiert wird¶
Jedes Image, das von .github/workflows/docker-publish.yml gebaut und auf ghcr.io/vincentmakes/turbo-ea/<image> gepusht wird, ist mit cosign und keyless OIDC signiert: Es gibt keinen langlebigen Signierschlüssel. Das Zertifikat wird von Sigstores Fulcio für die Workflow-Identität ausgestellt, im öffentlichen Rekor-Transparenzprotokoll erfasst und sofort nach der Signaturerstellung verworfen.
Signierte Images:
ghcr.io/vincentmakes/turbo-ea/dbghcr.io/vincentmakes/turbo-ea/backendghcr.io/vincentmakes/turbo-ea/frontendghcr.io/vincentmakes/turbo-ea/nginxghcr.io/vincentmakes/turbo-ea/mcp-server
Das ollama-Image wird manuell außerhalb der Matrix neu gebaut und ist derzeit nicht signiert. Wenn Sie auf das gebündelte Ollama-Profil angewiesen sind und eine Überprüfung benötigen, bauen Sie es aus dem Quellcode.
Die Signatur gilt für den OCI-Manifest-Listen-Digest, sodass eine einzige Signatur transparent sowohl linux/amd64 als auch linux/arm64 abdeckt.
Überprüfung eines Images¶
Installieren Sie cosign, dann:
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
Was die Parameter bewirken:
--certificate-identity-regexp— akzeptiert jeden Workflow-Pfad in diesem Repository. Für eine strengere Prüfung ersetzen Sie durch--certificate-identity 'https://github.com/vincentmakes/turbo-ea/.github/workflows/docker-publish.yml@refs/tags/v1.0.0'.--certificate-oidc-issuer— pinnt den OIDC-Issuer auf den Token-Endpunkt von GitHub. Eine von einem anderen Issuer (z. B. dem CI eines Forks) ausgestellte Signatur schlägt fehl.
Eine erfolgreiche Überprüfung gibt das signierte Payload und eine Rekor-Transparenzprotokoll-URL aus. Bei einem Fehler wird mit einem Diagnosecode ungleich null beendet — lassen Sie Ihr Deploy daran scheitern.
Sie können auch per Digest überprüfen (die strengste Form, immun gegen Tag-Remapping):
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¶
Eine SPDX-Software-Stückliste wird automatisch von buildkit generiert (sbom: true im Build-Schritt) und als OCI-Referrer an jedes Image angehängt. Es ist keine zusätzliche Installation erforderlich.
Abrufen mit:
docker buildx imagetools inspect --format '{{ json .SBOM }}' \
ghcr.io/vincentmakes/turbo-ea/backend:1.0.0 | jq .
Das SBOM listet alle von buildkit im endgültigen Image beobachteten Pakete (apk-Pakete, Python-Wheels, Node-Module usw.) mit Versionen und Quell-URLs auf.
Schwachstellen-Scanning (Trivy)¶
Der Publish-Workflow führt Trivy für HIGH- und CRITICAL-CVEs gegen jedes gebaute Image aus und lädt das Ergebnis als SARIF auf den Security-Tab des Repositories hoch.
Der Scan ist derzeit nicht blockierend (exit-code: 0). Wenn Trivy-Ergebnisse für Ihre Umgebung relevant sind, führen Sie Ihren eigenen Scanner gegen das gezogene Image aus. Das veröffentlichte SBOM ist ein sauberer Input.
Für Beitragende: Wenn Sie eine tatsächlich ausnutzbare Schwachstelle entdecken, melden Sie diese bitte über einen privaten Sicherheitshinweis und nicht öffentlich.
Action-SHA-Pinning¶
Jede GitHub Action, die vom Publish-Workflow verwendet wird, ist auf einen 40-Zeichen-Commit-SHA gepinnt, nicht auf ein schwebendes Major-Tag. Aktualisierungen erfolgen über den github-actions-Ökosystem-Dependabot im monatlichen Rhythmus.