Una supply chain de Docker práctica: firmada, escaneada, atestada

«Mi imagen pasa el escaneo» no es una supply chain. Una supply chain es linaje demostrable desde el commit fuente hasta el contenedor en ejecución. Esto es el mínimo que entregamos a cada cliente.

Los cuatro artefactos

Para cada imagen que construimos producimos:

1. La imagen en sí, etiquetada de forma inmutable (SHA del commit, no latest)
2. Un SBOM (Software Bill of Materials) en formato SPDX o CycloneDX
3. Un informe de escaneo de vulnerabilidades (Trivy o Grype)
4. Una firma (Cosign) sobre el digest + una atestación firmada que vincula imagen con SBOM + scan + commit

Todo esto se publica junto a la imagen en el registry bajo las relaciones estándar OCI.

Pipeline de build

En GitHub Actions:

- run: docker buildx build --output type=registry,name=${IMG} .
- run: syft ${IMG} -o cyclonedx-json > sbom.json
- run: trivy image --format json ${IMG} > scan.json
- run: cosign sign --yes ${IMG}
- run: cosign attest --predicate sbom.json --type cyclonedx --yes ${IMG}
- run: cosign attest --predicate scan.json --type vuln --yes ${IMG}

La firma keyless vía Fulcio + Rekor implica que la identidad firmante es el token OIDC de GitHub Actions. Sin claves de larga vida que rotar.

Política de admisión

El clúster Kubernetes corre Kyverno (o OPA Gatekeeper) con una política que rechaza cualquier pod cuya imagen:

• No esté firmada por una identidad esperada (la workload identity del pipeline de build)
• Tenga alguna CVE crítica en su atestación de scan con más de 7 días
• No tenga atestación de SBOM en absoluto

Esto significa que un desarrollador no puede empujar una imagen sin firmar a producción aunque tenga permisos kubectl apply. El clúster rechazará el pod antes de programarlo.

Lo que monitorizamos

• Nuevas CVEs que afectan imágenes ya desplegadas (la BBDD de Trivy se actualiza diariamente; re-escaneamos en sitio)
• Imágenes en producción que no han sido re-construidas en N días
• Fallos de verificación de firma (alertas a PagerDuty)
• Drift entre el SBOM del momento de build y lo que realmente corre (normalmente un apt install colado)

El post completo en Medium tiene las políticas Kyverno literales, el setup Cosign keyless, y el dashboard que usamos para seguir la cobertura de firmas a través de toda la flota.