DevSecOps practico con Sigstore y cosign
Actualizado: 2026-05-03
Sigstore[1] y su CLI cosign[2] han dejado de ser experimento. Hoy grandes proyectos — Kubernetes, Istio, NPM con provenance, Python con PEP 740 — firman sus artefactos con la cadena Sigstore. Pero entre “existe” y “mi equipo lo usa bien” sigue habiendo un salto. Este artículo es sobre cerrar ese salto: firmar imágenes y binarios de forma que la firma signifique algo y no se convierta en otra casilla de checklist.
Puntos clave
- Sigstore es tres piezas: cosign (CLI de firma), Fulcio (CA efímera ligada a OIDC) y Rekor (log transparente inmutable).
- El modelo keyless elimina la gestión de claves privadas persistentes; la identidad OIDC es el ancla.
- Firmar sin verificar en despliegue es trabajo sin beneficio — tan peligroso como no firmar.
- La verificación correcta valida identidad (quién firmó), no solo existencia de firma.
- Para entornos regulados o air-gapped, KMS o Sigstore privado son las opciones adecuadas.
De qué se ocupa Sigstore realmente
Sigstore es un conjunto de tres piezas que encajan:
- cosign: la CLI que firma y verifica artefactos — imágenes OCI, blobs, SBOMs.
- Fulcio: una autoridad certificadora que emite certificados de corta vida (~10 minutos) vinculados a una identidad OIDC: tu cuenta de GitHub, Google o tu proveedor corporativo.
- Rekor: un log transparente e inmutable donde las firmas se registran con un timestamp auditado.
La magia práctica: no necesitas gestionar claves privadas persistentes. Firmas con una identidad OIDC, obtienes un certificado efímero, firmas, el certificado expira y el registro queda en Rekor para que cualquiera verifique después. Este modelo keyless elimina la mayor fuente de incidentes de firma: claves comprometidas o pérdidas.
Firmar una imagen OCI
El caso de uso más común: firmar una imagen Docker/OCI tras construirla.
# Build + push como siempre
docker build -t registry.example.com/myapp:1.2.3 .
docker push registry.example.com/myapp:1.2.3
# Firma keyless (usa OIDC automáticamente)
cosign sign registry.example.com/myapp:1.2.3Cosign detecta el entorno (GitHub Actions, GitLab CI, local) y obtiene el token OIDC apropiado. La firma se adjunta al registry como artefacto adicional referenciado, no como etiqueta distinta.
Verificar:
cosign verify registry.example.com/myapp:1.2.3
--certificate-identity=ci@example.com
--certificate-oidc-issuer=https://token.actions.githubusercontent.comLa verificación no es “¿tiene firma?”. Es “¿tiene firma de la identidad que espero?”. Sin la parte de identidad, la firma es decorativa.
Integrar en un pipeline real
Tres patrones que funcionan en equipos con volumen:
- Firma automática en CI: cada build exitoso firma. El workflow tiene permiso OIDC al emisor Sigstore. Si el build pasa, la firma es gratis en complejidad.
- Policy en admission controller: Kyverno[3] o Gatekeeper[4] en Kubernetes rechazan pods cuya imagen no esté firmada por identidades autorizadas.
- Verificación en GitOps: Flux[5] y Argo CD[6] pueden verificar firmas antes de reconciliar — la firma se convierte en un gatekeeper real.
El error más común es firmar pero no verificar en despliegue. Firma sin verificación es trabajo sin beneficio.
Firma de SBOMs y provenance
Además de imágenes, Sigstore firma:
- SBOMs (Software Bill of Materials) generados con Syft[7].
- Provenance SLSA generado por el builder — prueba de cómo se construyó la imagen, qué commit, qué workflow.
- Binarios directos con
cosign sign-blob.
Para cumplir SLSA Level 3 necesitas provenance firmada no-falsificable. Sigstore es el mecanismo natural para conseguirla sin montar infraestructura propia.
Claves vs keyless: cuándo usar cuál
- Keyless: por defecto para la mayoría de equipos cloud-native. Sin gestión de claves, sin riesgo de compromiso. Dependencia de Sigstore público.
- Keypair: clave persistente (RSA o ECDSA), totalmente offline, tú gestionas la custodia. Útil para air-gapped o requisitos estrictos.
- KMS: clave en HashiCorp Vault, AWS KMS o GCP KMS. Buen balance entre gestión centralizada y firma verificable. El camino habitual en entornos regulados.
Errores comunes
Los errores que más se ven en equipos que adoptan DevSecOps con firmas:
- Firmar todo, verificar nada: la firma sin verificación es teatro.
- Aceptar cualquier identidad: verificar “tiene firma” sin validar quién firmó equivale casi a no firmar.
- Olvidar rotar: en el modelo keypair, sin rotación anual pierdes el beneficio.
- No guardar el log de Rekor: para auditoría a largo plazo, necesitas el UUID de Rekor entry como evidencia.
- Sin runbook cuando falla: si Sigstore público tiene un incidente, tu CI se para. Ten plan B.
Checklist mínima
Un equipo que quiera empezar sin complicaciones:
- Firma en CI keyless sobre imágenes principales.
- Verificación en despliegue (Kyverno, Flux, Argo).
- Lista de identidades autorizadas versionada en Git.
- Alerta si una imagen sin firma llega a producción.
- Revisión trimestral de qué se firma y qué no.
Con eso ya estás por delante de la media del sector.
Relacionado: la firma de imágenes complementa bien el service mesh con mTLS para Zero Trust completo entre servicios, y el GitOps con ArgoCD puede ser el punto de verificación donde las firmas se validan antes de desplegar.
Conclusión
Sigstore pasó de proyecto experimental a infraestructura de facto para firmar software. La fricción de adopción ha caído. Lo que queda es integrarlo de forma que signifique algo: verificando de verdad, con identidades bien definidas y runbooks claros cuando falla. Firmar por firmar es peor que no firmar: da la ilusión de seguridad sin los beneficios. Bien aplicado, cierra una de las puertas que los atacantes de supply chain llevan años explotando.
