GitHub Actions CI/CD OIDC SLSA
Los pipelines CI/CD con GitHub Actions están en el centro de las cadenas de suministro de software modernas: por ellos pasa cada commit, cada versión y cada actualización de dependencias. Mal hechos, filtran secretos, publican artefactos sin firmar y se desmoronan a escala de monorepo. Diseñamos y reforzamos pipelines de GitHub Actions para equipos de producto de EE. UU. y la UE: despliegues sin claves con OIDC, procedencia SLSA, bibliotecas de workflows reutilizables, compilaciones en matriz y ciclos de retroalimentación inferiores al minuto en los que los equipos de ingeniería confían de verdad.
Los pipelines CI/CD con GitHub Actions están en el centro de las cadenas de suministro de software modernas: por ellos pasa cada commit, cada versión y cada actualización de dependencias. Mal hechos, filtran secretos, publican artefactos sin firmar y se desmoronan a escala de monorepo. Diseñamos y reforzamos pipelines de GitHub Actions para equipos de producto de EE. UU. y la UE: despliegues sin claves con OIDC, procedencia SLSA, bibliotecas de workflows reutilizables, compilaciones en matriz y ciclos de retroalimentación inferiores al minuto en los que los equipos de ingeniería confían de verdad.
Retos
Las variables de entorno y las salidas de acciones de terceros pueden imprimir secretos en texto plano en el log. Auditamos cada workflow en busca de pasos echo y run que puedan exponer secretos, añadimos llamadas ::add-mask:: e imponemos una composite action de depuración de logs en todos los repositorios.
Usar acciones con una etiqueta mutable (v3, main) significa que un repositorio upstream comprometido puede inyectar código malicioso en todos los pipelines en silencio. Fijamos todas las acciones por SHA de commit completo, automatizamos las actualizaciones de SHA con Dependabot y condicionamos las fusiones a una revisión obligatoria.
Los runners autoalojados que no son efímeros conservan estado entre trabajos: artefactos de compilación, credenciales y código fuente persisten en disco. Aprovisionamos runners efímeros (GitHub Actions Runner Controller o Buildjet) que terminan tras cada trabajo y nunca comparten estado del sistema de archivos.
Las instalaciones de dependencias sin caché, las compilaciones redundantes de capas de Docker y los trabajos secuenciales hacen que los pipelines sean tan lentos que los ingenieros dejan de esperarlos. Reestructuramos los trabajos para que se ejecuten en paralelo, añadimos caché por capas (npm/pip/Gradle/capas de Docker) y usamos el análisis de afectados de Turborepo o Nx para omitir los paquetes sin cambios.
Las pruebas no deterministas y las aserciones sensibles al entorno provocan compilaciones rojas espurias que erosionan la confianza en el CI y aumentan la latencia de la merge queue. Ponemos en cuarentena las pruebas inestables en un workflow aparte, añadimos lógica de reintentos con detección de inestabilidad en jUnit y abordamos las causas raíz de forma sistemática.
Ejecutar toda la suite de pruebas en cada commit de un monorepo grande desperdicia minutos por PR y satura la capacidad de los runners. Integramos el análisis del grafo de afectados de Turborepo o Nx con los filtros de ruta de GitHub Actions para ejecutar solo los pipelines que toca cada cambio.
Soluciones
Sustituya las credenciales cloud de larga duración por tokens OIDC de corta duración para AWS, GCP y Azure. Cada trabajo recibe un token acotado al repositorio, la rama y el entorno exactos: credenciales que caducan en minutos y no se pueden exfiltrar.
Extraiga su lógica de CI a un repositorio centralizado de workflows reutilizables. Los equipos llaman a una única referencia de workflow y reciben pasos coherentes de linting, pruebas, análisis de seguridad y despliegue, sin deriva por copiar y pegar entre decenas de repositorios.
Genere atestaciones de procedencia SLSA de nivel 3 para cada compilación de versión. Firme imágenes de contenedor y binarios con cosign (sin claves mediante Sigstore). Fije todas las acciones de terceros por SHA y automatice las actualizaciones con Dependabot.
Auditamos los grafos de dependencias de trabajos para detectar pasos secuenciales innecesarios, añadimos caché de dependencias por capas, pasamos a la caché de capas de Docker buildx mediante GHCR e integramos Turborepo o Nx para compilar solo lo que ha cambiado.
Generación dinámica de la matriz a partir del grafo de paquetes afectados: cada servicio tiene su propio trabajo aislado de pruebas y compilación, los resultados convergen en una única comprobación de estado de la puerta de fusión y los paquetes sin cambios se omiten por completo.
Versionado semántico automatizado, generación de changelogs, creación de GitHub Releases, etiquetado de imágenes de contenedor y promoción entre entornos desde staging hasta producción, todo condicionado por reglas de protección de entornos y flujos de aprobación.
Stack
GitHub Actions, workflows reutilizables, composite actions, OIDC, runners alojados por GitHub, runners autoalojados, Dependabot, CodeQL, secret scanning, entornos y reglas de protección, compilaciones en matriz, cosign, procedencia SLSA, Docker buildx, GHCR, caché de Turborepo, afectados de Nx, GitHub Packages.
Cumplimiento
Procedencia SLSA de nivel 3 · firma sin claves con OIDC · secret scanning en cada push · traza de auditoría SOC 2
Casos
Clientes nativos de firma electrónica para iOS y Android con un CRM en Symfony + React para un despacho de abogados internacional: onboarding con KYC y una cadena de evidencias defendible para asuntos de EE. UU. y la UE.
App multiplataforma de dieta y planificación de comidas en Flutter: motor de calorías, biblioteca de recetas, plan semanal de comidas y pedido de la compra.
App complementaria de TPV para una cadena de boutiques multimarca: búsqueda de inventario entre tiendas con ElasticSearch e integración con el sistema 1C.
Por qué YuSMP
Tratamos el propio pipeline de CI/CD como una superficie de ataque. Cada proyecto empieza con una auditoría de seguridad de los workflows — exposición de secretos, higiene de la fijación de versiones, aislamiento de los runners y configuración de OIDC — antes de empezar cualquier trabajo de funcionalidades.
Un CI lento es un CI ignorado. Medimos la duración base del pipeline, reestructuramos los grafos de trabajos para paralelizar y añadimos caché en cada capa hasta que el ciclo de retroalimentación es lo bastante rápido como para que los ingenieros lo esperen de verdad antes de fusionar.
Las soluciones puntuales que funcionan para un repositorio se rompen con 50. Creamos bibliotecas centralizadas de workflows reutilizables, registros de composite actions y políticas de Dependabot que los equipos de gobernanza pueden aplicar en toda la flota sin sobrecarga por repositorio.
Preguntas frecuentes
GitHub Actions es la opción por defecto adecuada cuando su código fuente ya está en GitHub: cero infraestructura que mantener e integración nativa con las pull requests, Dependabot y el grafo de seguridad de GitHub. Jenkins encaja con equipos con infraestructura local compleja y bibliotecas compartidas maduras. GitLab CI es la elección natural cuando toda la plataforma DevSecOps vive en GitLab. Migrar de Jenkins o GitLab CI a GitHub Actions suele llevar de una a dos semanas en un parque de pipelines de tamaño medio.
El despliegue sin claves con OIDC sustituye las credenciales cloud de larga duración (claves de acceso de AWS, JSON de cuentas de servicio de GCP) guardadas como secretos de GitHub por tokens de corta duración emitidos por el proveedor de identidad de GitHub. Cada trabajo solicita un token válido para el repositorio, la rama y el entorno exactos, acotado a los permisos de IAM mínimos. El token caduca al terminar el trabajo: no hay nada que rotar, nada que filtrar y nada que revocar tras una brecha.
Use runners alojados por GitHub para la mayoría de las cargas: cero mantenimiento y estado limpio en cada trabajo. Los runners autoalojados se justifican cuando las compilaciones requieren hardware específico (GPU, ARM, mucha memoria), acceso a recursos de red privada que no pueden exponerse públicamente u optimización de costes con un volumen de compilación muy alto. Cuando se usan runners autoalojados, deben ser efímeros: aprovisionados de nuevo para cada trabajo mediante GitHub Actions Runner Controller o un grupo de autoescalado en la nube.
La procedencia SLSA (Supply-chain Levels for Software Artefacts) es una declaración firmada que registra exactamente qué commit de origen, qué cadena de herramientas de compilación y qué entorno de compilación produjeron un artefacto determinado. GitHub Actions la genera con la acción slsa-framework/slsa-github-generator, que se ejecuta en un workflow reutilizable aislado y firma la atestación con cosign mediante el protocolo sin claves de Sigstore. Los consumidores pueden verificar la procedencia de forma independiente con la CLI de cosign antes de desplegar.
Seguimos un enfoque de cuatro capas: paralelizar los trabajos independientes del grafo del workflow, añadir caché de dependencias (actions/cache para npm, pip, Maven, Gradle), pasar a Docker buildx con caché de capas en GHCR para no reconstruir las capas sin cambios e integrar el análisis de afectados de Turborepo o Nx para omitir los paquetes sin cambios en los monorepos. Una auditoría inicial típica recupera entre el 40 y el 70 % de la duración del pipeline sin modificar nada del código de la aplicación.
Los secretos cifrados de GitHub son la base correcta: están enmascarados en los logs y nunca se exponen a las pull requests de forks. Para los despliegues en producción, sustituya los secretos estáticos por tokens OIDC (sin ningún secreto). Para los secretos que deban existir (claves de API, certificados de firma), use secretos con alcance de entorno y reglas de protección que exijan aprobación manual antes de que un trabajo pueda acceder a ellos. El secret scanning en cada push detecta commits accidentales antes de que lleguen al remoto.
Integramos Turborepo o Nx con GitHub Actions mediante la generación dinámica de la matriz. Un trabajo de preparación ejecuta el análisis del grafo de afectados y emite una matriz JSON de paquetes modificados. Los trabajos posteriores se abren en abanico por la matriz en paralelo: cada paquete tiene un trabajo aislado de pruebas y compilación. Los paquetes sin cambios se omiten por completo. Los resultados vuelven a converger en una única comprobación de estado obligatoria que condiciona las fusiones, de modo que la merge queue ve una sola señal verde con independencia del tamaño del monorepo.
Respuesta en 1 día hábil. NDA a petición.
Cuéntenos algunos detalles y un consultor sénior le responderá en un día hábil.