Un pipeline que solo compila y despliega puede terminar publicando imágenes vulnerables, sin trazabilidad y sin control claro de origen.
GitHub Actions, Trivy y Cosign permiten agregar controles clave antes del despliegue: revisión de dependencias, escaneo de imágenes y firma del artefacto. El objetivo es validar cada etapa antes de pasar a la siguiente, conservar evidencia del proceso y reducir cambios invisibles en producción.
Cuándo conviene aplicarlo
Este enfoque es útil para:
- Equipos que publican imágenes en un registry.
- Repositorios con despliegues frecuentes.
- Proyectos que necesitan evidencia básica de cadena de suministro.
Requisitos previos
Antes de implementar el flujo, conviene contar con:
- Un repositorio en GitHub.
- Un registry OCI disponible.
- Permisos para configurar secrets u OIDC.
- Un
Dockerfiledel servicio.
Arquitectura de trabajo
El flujo recomendado conecta las siguientes etapas:
- Pull request.
- Revisión de dependencias.
- Build de imagen.
- Escaneo.
- Firma.
- Push controlado.
La idea es validar cada paso antes de avanzar al siguiente. Así se mantiene un punto de retorno claro y se evita que cambios no revisados lleguen a producción.
Paso 1: definir permisos mínimos del workflow
El pipeline no debería tener más privilegios que los necesarios. Para este caso, necesita leer código, solicitar un token OIDC, publicar paquetes y reportar eventos de seguridad.
permissions:
contents: read
packages: write
id-token: write
security-events: writePaso 2: agregar revisión de dependencias en pull requests
La revisión de dependencias ayuda a bloquear cambios que introducen vulnerabilidades o licencias no permitidas antes del merge.
- name: Dependency review
uses: actions/dependency-review-action@v4
with:
fail-on-severity: highPaso 3: construir y etiquetar la imagen
Evita publicar únicamente con latest. Una etiqueta basada en el commit permite identificar con precisión qué versión del código generó la imagen.
IMAGE=ghcr.io/ORG/APP:${GITHUB_SHA}
docker build -t "$IMAGE" .Paso 4: escanear la imagen antes del push final
El escaneo debe cortar el flujo si aparecen vulnerabilidades críticas o altas que no fueron aceptadas previamente por el equipo.
trivy image --severity HIGH,CRITICAL --exit-code 1 "$IMAGE"Paso 5: firmar la imagen con identidad OIDC
La firma permite verificar que la imagen salió del workflow esperado y que no fue reemplazada en el registry.
cosign sign "$IMAGE"
cosign verify "$IMAGE" --certificate-identity-regexp 'https://github.com/ORG/REPO' --certificate-oidc-issuer https://token.actions.githubusercontent.comPruebas de funcionamiento
Antes de mover el cambio a producción, ejecuta las validaciones del último paso y revisa:
- Logs del workflow.
- Salida de los comandos.
- Estado del servicio.
- Resultado del escaneo.
- Verificación de la firma.
Si el cambio afecta datos, restaura o prueba primero en un entorno aislado antes de operar sobre información real.
Advertencias de seguridad
- No uses secrets de larga vida si puedes usar OIDC.
- Fija versiones de acciones externas y revisa permisos por job.
- No ignores hallazgos críticos sin una excepción documentada.
Problemas frecuentes
El escaneo falla por CVEs sin fix
Separa vulnerabilidades explotables, imagen base obsoleta y dependencias transitivas. Actualiza la imagen base cuando corresponda y registra excepciones temporales si el equipo decide aceptarlas.
Cosign pide autenticación interactiva
Verifica que el workflow tenga el permiso id-token: write y que se ejecute en un proveedor OIDC soportado.
Buenas prácticas para producción
- Usar branch protection.
- Publicar SBOM junto a la imagen.
- Mantener una política de expiración de excepciones.
- Registrar el digest de la imagen desplegada.
Cloud Serversby Donweb
Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.
- Performance que te sorprenderá
- Rápida escalabilidad y sin limitaciones
- Arquitectura de alta disponibilidad
- Soporte experto y ejecutivos de cuenta
- Pagos en tu moneda y facturación local
