Compromiso de TJ Actions: autoridad de ejecución y divulgación en registros

Descripción del Incidente

Tier A (confirmed): Entre el 14 y el 15 de marzo de 2025, etiquetas de versión de changed-files se redirigieron a código malicioso que extraía secretos del ejecutor hacia registros de workflows. El mantenedor identifica la versión 46.0.0 como corregida. Aviso del mantenedor.

Tier A (confirmed): StepSecurity registra confirmación a las 17:00 UTC del 14 de marzo, retirada del repositorio a las 14:00 UTC del 15 y restauración a las 22:00 UTC. Son hitos de investigación, no un intervalo de exposición medido para cada consumidor. Investigación.

Tier C (unknown): Ejecuciones por organización, reutilización de credenciales y pérdidas posteriores requieren telemetría privada. Este análisis arquitectónico es retrospectivo; la fecha de publicación no es la del incidente.

Tier B (inferred), supuesto delimitado: el modelo de aislamiento se aplica a jobs que ejecutan código de terceros; la exposición de claves de entrega depende de credenciales alcanzables en ese contexto de ejecución.

Mapeo de la Superficie de Falla

Defina S = {C, N, K, I, O}: plano de control, capa de red, ciclo de vida de claves, frontera de identidad y orquestación operativa. Tier B (inferred): el mecanismo dominante es la filtración de privilegios de CI/CD mediante admisión de dependencias ejecutables y acceso compartido a credenciales.

| Capa | Clase de falla y frontera | | --- | --- | | C | Referencia de dependencia bizantina; autoridad externa de versiones influye en ejecución local | | N | Obtención de payload y transporte de registros; no requiere caída de red | | K | La divulgación exige revocación; se desconoce la integridad de la rotación | | I | La ejecución de la acción alcanza autoridad más allá de comparar archivos | | O | La omisión de admisión/aislamiento permite propagación; el tiempo de detección prolonga exposición |

La falla por parada no es necesaria en este modelo. Bizantina describe conducta maliciosa del componente, no compromiso del consenso de la plataforma.

Modelado Formal de Fallas

Tier B (inferred): S_t = (E_t, A_t, K_t, L_t) representa digests ejecutables admitidos, digests aprobados, credenciales accesibles y contenido de registros. T(S_t) resuelve dependencias, ejecuta código y persiste salida. R(E_t) representa alcance de credenciales; K_release es el conjunto de credenciales de entrega.

I(S_t):\quad E_t \subseteq A_t \quad\land\quad R(E_t)\cap K_{\mathrm{release}}=\varnothing

El invariante propuesto exige contenido ejecutable aprobado y ausencia de acceso a claves de entrega desde el código de análisis. Una etiqueta desplazada puede admitir un digest no aprobado; autoridad compartida puede violar la segunda cláusula. No se afirma que cada consumidor afectado tuviera claves de entrega. La admisión debe rechazar digests desconocidos antes de ejecutar. La aprobación debe abarcar código transitivo y descargas en ejecución; fijar solo el componente externo es insuficiente.

Modelo de Explotación Adversaria

Tier B (inferred): A_supply_chain altera código ejecutable upstream; A_passive lee registros accesibles; A_active usa una credencial expuesta aún válida; A_internal abusa del acceso existente a registros o ejecutores; A_economic busca valor en autoridad sobre entregas o artefactos. Solo la cadena de suministro y la divulgación están sustentadas por el incidente; las otras clases son extensiones condicionales.

X = \Delta t \times W \times P_s

Δt es el tiempo entre primera exposición e invalidación efectiva, W cuenta dominios de confianza alcanzables y P_s es una puntuación de privilegio normalizada localmente. X prioriza respuesta; no estima probabilidad de intrusión ni pérdida monetaria. Compare únicamente con la misma escala. Reduzca primero la latencia de invalidación para credenciales que cruzan fronteras de producción. La ausencia de tiempos de detección requiere un intervalo, no un valor puntual inventado.

Fragilidad Arquitectónica Raíz

Tier B (inferred): la fragilidad estructural es la compresión de confianza: una utilidad de comparación hereda el contexto de ejecución de un job con credenciales. Las etiquetas expresan intención de selección, pero no establecen contenido revisado inmutable. Los registros crean otra frontera, desde ejecución transitoria hasta retención con lectores potencialmente numerosos.

GitHub recomienda fijar commits completos y tokens de mínimo privilegio. Estos controles reducen riesgos distintos; ninguno demuestra que el código seleccionado sea benigno. Guía de la plataforma. Un digest malicioso fijado sigue siendo malicioso. Un paso posterior en el mismo ejecutor comprometido no constituye una frontera independiente de entrega.

Reconstrucción a Nivel de Código

Tier B (inferred): el flujo vulnerable es referencia mutable -> ejecución privilegiada -> acceso a credenciales -> salida retenida. El diseño siguiente propone admisión y promoción; no es código recuperado del incidente. Las funciones de política deben denegar ante fallas y operar bajo administración independiente del workflow enviado.

# Policy pseudocode; enforcement lives outside the workflow checkout.
admit(job, policy):
    closure = resolve_transitive_code(job, network_fetches="deny")
    require closure.complete
    require every_digest(closure) in policy.reviewed_digests
    require no_digest(closure) in policy.revoked_digests
    require job.runner.is_ephemeral and job.runner.has_no_host_credentials
    require job.permissions <= policy.analysis_permissions
    require job.release_secrets == empty
    require job.oidc_token_minting == disabled
    return isolated_run(job, timeout=policy.max_runtime,
                        egress=policy.analysis_allowlist)

promote(artifact, evidence, approval):
    require verify_digest_and_provenance(artifact, evidence)
    require evidence.builder in policy.release_builders
    require approval.binds(artifact.digest, policy.version)
    # A signature alone does not establish that a build was trustworthy.
    require independent_release_checks(artifact)
    return isolated_deploy(artifact, credential_ttl=policy.release_ttl)

El ejecutor de análisis no debe ejecutar código de despliegue después de emitir credenciales. Los artefactos permanecen no confiables hasta superar verificaciones de entrega. Comparaciones de reproducibilidad requieren constructores independientes y toolchain definida; salidas iguales no prueban seguridad del código fuente.

Análisis de Impacto Operacional

Tier B (inferred): un nodo corresponde a una ejecución distinta de job en un ejecutor dentro de una ventana fija de revisión, no a la instalación en un repositorio.

B = \frac{\text{affected\_nodes}}{\text{total\_nodes}}

Cuente ejecuciones del digest malicioso en el numerador y todas las ejecuciones del alcance en el denominador. Tier C (unknown): ninguna población está disponible aquí; no se justifica un B numérico. Adopción no sustituye exposición por ejecución.

La exposición de credenciales exige un inventario separado por identidad, intervalo de validez y alcance de recursos. Efectos sobre latencia y rendimiento dependen de suspensión y reconstrucción, no solo de divulgación. Para capacidad, la cola Q se vacía en Q/(μ−λ) únicamente si la tasa de servicio posterior a recuperación μ supera la llegada λ; de lo contrario, restrinja admisión. La pérdida financiera sigue sin determinarse.

Capa de Traducción Empresarial

Tier B (inferred), decisiones propuestas:

CTO: exigir frontera documentada entre análisis y despliegue; bloquear entregas con procedencia ejecutable sin resolver.
CISO: inventariar credenciales alcanzables, revocarlas y verificar invalidación con evidencia del emisor. Eliminar registros no invalida secretos copiados.
DevSecOps: imponer política de digests fuera del control del repositorio, reconstruir en ejecutores limpios y medir tiempo entre exposición y revocación.
Consejo: exigir evidencia de cobertura de contención y aceptación explícita del alcance de credenciales sin resolver antes de restablecer autoridad de entrega de alto impacto.

Modelo STIGNING de Hardening

Tier B (inferred), controles propuestos: aislar administración de políticas de mantenedores de workflows; separar credenciales de análisis de identidades de despliegue; exigir dos aprobadores independientes para excepciones y promociones de alto impacto. Este quórum es un control organizativo, no consenso bizantino.

External action -> digest review -> admission policy
                                      |
                                      v
                            ephemeral analysis runner
                            no release credentials
                                      |
                              untrusted artifact
                                      v
                    provenance + independent release checks
                                      |
                             protected approval
                                      v
                         isolated deployment identity

Definir tolerancia cero para digests ejecutables no revisados y credenciales de entrega en jobs de análisis. Restringir destinos de salida, tratando también el canal autorizado de registros como vía de divulgación. Monitorizar digests resueltos, procesos, emisión de tokens y acceso a registros sin registrar secretos sin procesar.

Definir techo de concurrencia c por tenant según capacidad de ejecutores limpios y limitar colas; el exceso debe rechazarse o aplazarse antes de emitir credenciales. Definir SLO de revocación medido por emisor, sin asumir plazo universal. Usar identidades de despliegue breves con restricciones de repositorio, entorno y audiencia.

El rollback debe restaurar conjuntamente workflow revisado, imagen del ejecutor y versión de política. Nunca restaurar credenciales revocadas ni un digest bloqueado por compromiso. Preservar evidencia forense restringida antes de eliminar registros expuestos; verificar migraciones necesarias antes de revertir estado de aplicación.

Implicación Estratégica

Tier B (inferred): tipo primario: falla de gobernanza. La clasificación trata admisión de ejecutables y autoridad de credenciales, no atribuye negligencia organizativa. La perspectiva Infrastructure Doctrine trata dependencias de build como privilegios delegados de ejecución.

En un horizonte de 5–10 años, conservar procedencia desde artefacto hasta código fuente, revisiones de dependencias, versiones de políticas y evidencia de revocación a través de migraciones de herramientas. Es un horizonte de diseño, no previsión de frecuencia de ataques. Superficie institucional primaria: Mission-Critical DevSecOps. Líneas de capacidad: Reproducible and signed build pipelines; Policy-as-code enforcement; Immutable rollout and rollback control.

Referencias

Conclusión

El objetivo de control es impedir que un compromiso de dependencias se convierta en autoridad de entrega o divulgación duradera de credenciales. Tier A establece el mecanismo histórico; Tier B especifica controles condicionales; Tier C impide estimaciones de exposición sin soporte. La recuperación solo termina con evidencia de procedencia ejecutable, invalidación de credenciales y separación de entrega.

STIGNING Infrastructure Risk Commentary Series
Engineering Under Adversarial Conditions