Saltar a contenido

Cadena de suministro

A partir de la versión 1.0.0, las imágenes de contenedor que Turbo EA publica en GHCR incluyen metadatos verificables de la cadena de suministro para que los operadores puedan confirmar que una imagen proviene del CI de este proyecto antes de instalarla en producción.

Esta página cubre qué está firmado, cómo verificarlo, dónde se encuentra el SBOM y cómo encaja el escaneo de Trivy (actualmente informativo).

Qué está firmado

Cada imagen construida por .github/workflows/docker-publish.yml y publicada en ghcr.io/vincentmakes/turbo-ea/<imagen> está firmada con cosign usando OIDC sin clave: no existe una clave de firma de larga duración. El certificado es emitido por Fulcio de Sigstore para la identidad del flujo de trabajo, registrado en el registro de transparencia público de Rekor, y descartado en cuanto se crea la firma.

Imágenes firmadas:

  • 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

La imagen ollama se reconstruye manualmente fuera de la matrix y no está firmada actualmente. Si depende del perfil Ollama incluido y necesita verificación, constrúyala desde el código fuente.

La firma se aplica al digest de la lista de manifiestos OCI, por lo que una sola firma cubre de forma transparente tanto linux/amd64 como linux/arm64.

Verificación de una imagen

Instale cosign y ejecute:

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

Qué hacen los parámetros:

  • --certificate-identity-regexp — acepta cualquier ruta de flujo de trabajo dentro de este repositorio. Para mayor restricción, reemplácelo por --certificate-identity 'https://github.com/vincentmakes/turbo-ea/.github/workflows/docker-publish.yml@refs/tags/v1.0.0'.
  • --certificate-oidc-issuer — fija el emisor OIDC al endpoint de tokens de GitHub. Una firma emitida por cualquier otro emisor (p. ej., el CI de un fork) fallará en la verificación.

Una verificación exitosa imprime el payload firmado y una URL del registro de transparencia de Rekor. Un fallo termina con código distinto de cero — falle su despliegue con ello.

También puede verificar por digest, que es la forma más estricta (inmune a la reasignación de etiquetas):

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 es generado automáticamente por buildkit (sbom: true en el paso de construcción) y adjuntado a cada imagen como referente OCI. No se requiere nada adicional.

Obténgalo con:

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

El SBOM lista todos los paquetes observados por buildkit en la imagen final (paquetes apk, wheels de Python, módulos de Node, etc.) con versiones y URLs de origen.

Escaneo de vulnerabilidades (Trivy)

El flujo de publicación ejecuta Trivy contra cada imagen construida para CVEs HIGH y CRITICAL y sube el resultado como SARIF a la pestaña Security del repositorio.

El escaneo es actualmente no bloqueante (exit-code: 0). Si los resultados de Trivy son relevantes para su entorno, ejecute su propio escáner contra la imagen descargada. El SBOM publicado es una entrada limpia.

Para colaboradores: si detecta una vulnerabilidad genuinamente explotable, repórtela mediante un aviso de seguridad privado en lugar de comentarlo en un issue público.

Fijación de SHA de Actions

Cada GitHub Action utilizada por el flujo de publicación está fijada a un SHA de commit de 40 caracteres, no a una etiqueta principal flotante. Las actualizaciones se gestionan mediante Dependabot del ecosistema github-actions con una cadencia mensual.