Sigstore en registros de imágenes: adopción y realidad

Actualizado: 2026-05-03

En apenas dos años, Sigstore^[1] ha pasado de curiosidad académica a pieza asumida en la cadena de suministro de software. Lo interesante del momento actual no es que exista la tecnología — en 2022 ya era utilizable — sino que los registros donde realmente viven las imágenes han terminado por aceptarla como ciudadana de primera clase. El cambio de tono es el que marca la diferencia: hasta hace poco, firmar una imagen era una declaración política dentro de un equipo; hoy se parece más a habilitar HTTPS en un servidor nuevo.

Puntos clave

• Kubernetes firma la totalidad de sus imágenes desde 1.24; PyPI, npm y Homebrew han adoptado Sigstore para provenance.
• GHCR es el registro mejor integrado: GitHub Actions emite OIDC tokens que cosign sign --yes consume sin fricción.
• Harbor 2.5+ y Quay ofrecen soporte nativo; AWS ECR es el menos amigable y empuja su propio esquema KMS.
• La verificación tiene valor en tres puntos: admission controller del cluster, capa GitOps y pipeline CI/CD.
• El Rekor público tiene rate limits que se quedan cortos en builds intensivos; a partir de cierto volumen hay que levantar Rekor propio.

Qué ha cambiado en el último año

El punto de inflexión no se explica por una sola release sino por una acumulación de señales:

• Kubernetes firma la totalidad de sus imágenes desde 1.24, un precedente copiado por buena parte del ecosistema CNCF.
• PyPI publicó el PEP 740 y empuja attestations con Sigstore para paquetes Python.
• npm incorporó provenance en el último trimestre de 2023 apoyándose en la misma infraestructura.
• Homebrew ha empezado a adjuntar provenance a sus fórmulas.
• Docker Hub ya sirve artifacts referenciados en beta.

La lectura conjunta es que la firma ha dejado de ser una excepción para convertirse en el estado por defecto que cualquier pipeline maduro debería producir, igual que nadie discute ya generar un SBOM durante la build. Este proceso conecta con DevsecOps con Sigstore y cosign, donde se describe el contexto más amplio de la cadena de suministro de software.

Estado registro por registro

GHCR es el registro mejor integrado. La razón es estructural: GitHub Actions emite un OIDC token identificando al workflow, al repositorio y al actor, y cosign sign --yes lo consume sin fricción. La firma queda atada a un identificador verificable en el log de transparencia de Rekor sin gestionar claves locales. Para proyectos open source publicando en GHCR, la adopción es ya mayoritaria.

Harbor ha hecho los deberes en el frente self-hosted. Desde la versión 2.5 soporta firmas Sigstore nativamente, permite enforcar políticas por proyecto, puede apuntar a un Fulcio y Rekor privados y refleja el estado de firma en la UI. Para cualquier organización que ya ejecute Harbor dentro de su red, añadir verificación no es una reescritura, es una casilla.

Quay (Red Hat) ofrece soporte similarmente maduro con buena integración con OpenShift. Google Artifact Registry encaja con Binary Authorization y admite attestations SLSA firmadas con Sigstore. AWS ECR es el patito feo: soporta Sigstore vía OCI artifacts pero no tiene UI ni integración first-class, y AWS empuja su propio esquema basado en KMS. Docker Hub tiene la tecnología pero no la UX: su búsqueda y vista de repositorio no sabe aún qué hacer con las firmas.

Verificar sin sobrediseñar

La parte interesante no es firmar sino verificar de forma que la firma se convierta en un gate real. Tres puntos donde la verificación tiene valor:

Admission controller: Kyverno expresa una política donde se declaran las identidades aceptadas (issuer OIDC más subject que encaje con la organización). Un Pod que intenta crearse con una imagen no firmada o firmada por una identidad fuera de la política es rechazado antes de que el scheduler lo vea. Esta política es gestionable como código en el mismo repositorio que los manifiestos de GitOps con Argo CD.

Capa GitOps: Flux 2 permite una ImagePolicy que exige verificación cosign y bloquea la reconciliación si la firma no encaja.

Pipeline: un paso previo al deploy que ejerza cosign verify:

cosign verify "$IMAGE" 
  --certificate-identity-regexp='^https://github.com/myorg/.+$' 
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com

Lo relevante no es el comando sino el contrato: solo imágenes construidas por workflows de la organización pasan. El comando es casi accesorio; la disciplina está en no tener ninguna ruta de deploy que no pase por ahí.

Provenance, SBOM y attestations

Firmar el digest es el primer nivel. El siguiente, donde está la acción real, es firmar attestations sobre ese digest: quién construyó la imagen, con qué builder, a partir de qué commit, qué tests se ejecutaron, qué vulnerabilidades encontró el escáner.

cosign attest permite adjuntar esos documentos con el mismo modelo de identidad que la firma base. El consumidor puede exigir no solo “está firmada” sino “está firmada y además tiene un SLSA provenance v1.0 que encaja con este repo”. Chainguard publica imágenes con SBOMs adjuntos por defecto.

Límites reales que no conviene ocultar

• El Rekor público tiene rate limits suficientes para proyectos pequeños pero insuficientes para organizaciones con builds intensivos: a partir de cierto volumen toca levantar Rekor propio.
• La distribución de identidades es un problema de governance: verificar exige mantener en algún sitio, versionado, qué issuers y subjects son legítimos.
• Rotar identidades en CI (un cambio de owner de repo, una migración a otra org) puede romper verificaciones hasta que las políticas se actualicen.
• En entornos regulados, Sigstore keyless apoyado en Fulcio público puede no encajar con los procedimientos de custodia; muchos equipos financieros o sanitarios prefieren claves en AWS KMS, GCP KMS o Vault.

Conclusión

Para una organización que empiece hoy, la ruta razonable es firmar keyless con cosign desde los workflows de CI, almacenar en GHCR o Harbor self-hosted, exigir verificación en admission con Kyverno, documentar las identidades aceptadas en el repositorio como política versionada y alertar sobre imágenes sin firma llegando a producción. Sigstore no resuelve el problema de supply chain por sí solo: resuelve el eslabón “esta imagen fue producida por este proceso en este momento”. Pero ese eslabón, que hasta hace nada era discutible, hoy no lo es: firmar artefactos OCI es lo normal, y no hacerlo empieza a necesitar justificación.

1. Sigstore