GitHub Actions se ha convertido en una de las plataformas de CI\/CD m\u00e1s ampliamente adoptadas. Su flexibilidad, su estrecha integraci\u00f3n con los repositorios de GitHub y su rico ecosistema la hacen atractiva para equipos de todos los tama\u00f1os.<\/p>\n
Al mismo tiempo, los GitHub Actions runners han surgido como una superficie de ataque cr\u00edtica en los ataques modernos a la cadena de suministro de software.<\/p>\n
Los runners ejecutan c\u00f3digo no confiable, manejan secretos sensibles y a menudo operan con amplios permisos en repositorios, registros de artefactos y entornos cloud.<\/p>\n
Este art\u00edculo explica c\u00f3mo funcionan los GitHub Actions runners, por qu\u00e9 son frecuentemente atacados y c\u00f3mo dise\u00f1ar arquitecturas de runners que reduzcan significativamente el riesgo sin afectar los flujos de trabajo de los desarrolladores.<\/p>\n
Un runner es el entorno de ejecuci\u00f3n donde realmente se ejecutan los workflows de GitHub Actions. Cada job en un workflow se ejecuta en un runner.<\/p>\n
Desde una perspectiva de seguridad, los runners son el componente m\u00e1s sensible de la arquitectura de GitHub Actions porque:<\/p>\n
Si un runner se ve comprometido, el atacante podr\u00eda:<\/p>\n
Comprender la seguridad de los runners comienza por comprender los tipos de runners. GitHub Actions soporta m\u00faltiples modelos de runners, cada uno con diferentes caracter\u00edsticas de confianza y riesgo.<\/p>\n
Los GitHub-hosted runners son gestionados por GitHub y proporcionados como m\u00e1quinas virtuales ef\u00edmeras. Cada job normalmente se ejecuta en una VM nueva que se destruye despu\u00e9s de la ejecuci\u00f3n.<\/p>\n
Caracter\u00edsticas de seguridad:<\/p>\n
Desde el punto de vista de la seguridad, los GitHub-hosted runners proporcionan una base s\u00f3lida para cargas de trabajo no confiables como los pull requests.<\/p>\n
Sin embargo, no est\u00e1n libres de riesgo. La exposici\u00f3n de secretos, el uso indebido de permisos y la l\u00f3gica maliciosa en workflows a\u00fan pueden llevar a un compromiso.<\/p>\n
Los self-hosted runners se ejecutan en infraestructura gestionada por la organizaci\u00f3n: VMs, servidores f\u00edsicos o contenedores.<\/p>\n
Se utilizan frecuentemente para:<\/p>\n
Desde una perspectiva de seguridad, los self-hosted runners introducen riesgos significativos:<\/p>\n
Sin un aislamiento fuerte, un solo job comprometido puede afectar futuras compilaciones u otros repositorios.<\/p>\n
Los ephemeral self-hosted runners combinan la flexibilidad de los self-hosted runners con los beneficios de seguridad de la efimeralidad.<\/p>\n
Cada job se ejecuta en un runner reci\u00e9n aprovisionado que se destruye despu\u00e9s de completarse.<\/p>\n
Este modelo reduce significativamente:<\/p>\n
Desde el punto de vista de la seguridad, los ephemeral self-hosted runners son fuertemente preferidos sobre los runners persistentes.<\/p>\n
Los runners se sit\u00faan en la intersecci\u00f3n de entradas no confiables y operaciones privilegiadas. Esto los convierte en objetivos atractivos para los atacantes.<\/p>\n
Los workflows pueden ejecutar c\u00f3digo proveniente de:<\/p>\n
Cualquiera de estos puede ser influenciado por un atacante. Si c\u00f3digo no confiable se ejecuta en un runner con secretos o permisos elevados, el compromiso es inmediato.<\/p>\n
Los secretos se exponen com\u00fanmente a los runners a trav\u00e9s de variables de entorno.<\/p>\n
Si las condiciones del workflow est\u00e1n mal configuradas, los secretos pueden ser accesibles para:<\/p>\n
Una vez que un secreto se expone, a menudo es dif\u00edcil detectarlo o contenerlo.<\/p>\n
Los runners compilan y empaquetan artefactos de software.<\/p>\n
Si un atacante modifica la salida de compilaci\u00f3n, el artefacto resultante puede distribuirse con plena confianza en los sistemas posteriores.<\/p>\n
Sin verificaciones de integridad de artefactos, puede no haber forma de detectar el compromiso.<\/p>\n
El modelado de amenazas de los runners revela patrones de ataque recurrentes.<\/p>\n
Un atacante env\u00eda un pull request que modifica la l\u00f3gica del workflow o introduce pasos de compilaci\u00f3n maliciosos.<\/p>\n
Si el workflow expone secretos o tokens privilegiados a las compilaciones de PR, el atacante puede exfiltrar credenciales.<\/p>\n
Este ataque no requiere ninguna vulnerabilidad, solo una mala configuraci\u00f3n de confianza.<\/p>\n
Los workflows utilizan frecuentemente third-party actions.<\/p>\n
Si una action se ve comprometida en origen o se referencia sin fijarla a un commit espec\u00edfico, el atacante puede inyectar comportamiento malicioso en los workflows.<\/p>\n
El runner ejecuta la action con los mismos permisos que el c\u00f3digo de workflow propio.<\/p>\n
En self-hosted runners persistentes, un atacante puede:<\/p>\n
Los workflows futuros pueden ejecutar sin saberlo c\u00f3digo controlado por el atacante.<\/p>\n
Los self-hosted runners a menudo tienen acceso de red a sistemas internos o entornos cloud.<\/p>\n
Un runner comprometido puede utilizarse como punto de pivote para atacar otros servicios internos.<\/p>\n
Asegurar los GitHub Actions runners es un problema arquitect\u00f3nico, no un problema de checklist.<\/p>\n
La seguridad efectiva de los runners se basa en unos pocos principios fundamentales.<\/p>\n
Los runners ejecutan entradas no confiables por dise\u00f1o.<\/p>\n
Nunca deben ser impl\u00edcitamente confiables, incluso si se ejecutan dentro de infraestructura interna.<\/p>\n
Los secretos, el acceso de red y los privilegios deben ser limitados en consecuencia.<\/p>\n
Intentar \u00ablimpiar\u00bb un runner comprometido no es fiable.<\/p>\n
Destruir y recrear runners despu\u00e9s de cada job proporciona una garant\u00eda de seguridad mucho m\u00e1s fuerte.<\/p>\n
Los runners ef\u00edmeros eliminan la persistencia y reducen significativamente el tiempo de permanencia del atacante.<\/p>\n
Cada job debe recibir solo los permisos que necesita.<\/p>\n
Esto incluye:<\/p>\n
Evitar otorgar permisos de escritura globales o por defecto.<\/p>\n
Las compilaciones de pull requests, las contribuciones externas y el c\u00f3digo no confiable deben ejecutarse en entornos separados de los jobs confiables de release o deployment.<\/p>\n
Esta separaci\u00f3n puede aplicarse mediante:<\/p>\n
Minimizar lo que est\u00e1 disponible en los runners:<\/p>\n
Una superficie de ataque m\u00e1s peque\u00f1a limita las opciones del atacante.<\/p>\n
Las siguientes pr\u00e1cticas abordan los riesgos m\u00e1s comunes de los runners sin cambiar fundamentalmente los flujos de trabajo de los desarrolladores.<\/p>\n
Para pull requests y contribuciones externas, los GitHub-hosted runners proporcionan un fuerte aislamiento y efimeralidad autom\u00e1tica.<\/p>\n
Evitar exponer secretos a estos jobs a menos que sea estrictamente necesario.<\/p>\n
Si se requieren self-hosted runners, hacerlos ef\u00edmeros.<\/p>\n
Cada job debe:<\/p>\n
Este modelo reduce dr\u00e1sticamente el riesgo de persistencia.<\/p>\n
Utilizar el modelo de permisos granulares de GitHub.<\/p>\n
Definir permisos a nivel de workflow o job en lugar de depender de los valores por defecto.<\/p>\n
Revisar los cambios de permisos con la misma atenci\u00f3n que los cambios de c\u00f3digo.<\/p>\n
Siempre fijar las actions a un commit SHA espec\u00edfico.<\/p>\n
Evitar usar actions que:<\/p>\n
Tratar las actions como parte de tu cadena de suministro.<\/p>\n
Evitar exponer secretos a workflows activados por:<\/p>\n
Preferir credenciales de corta duraci\u00f3n y acceso basado en identidad sobre secretos est\u00e1ticos.<\/p>\n
No asumir que los artefactos producidos por los runners son confiables.<\/p>\n
Utilizar:<\/p>\n
Esto asegura que los runners comprometidos no puedan envenenar silenciosamente los releases.<\/p>\n
La seguridad de los runners es una parte de la seguridad del pipeline, pero no puede funcionar de forma aislada.<\/p>\n
Debe combinarse con:<\/p>\n
Sin estos elementos, incluso los runners bien asegurados pueden producir resultados no confiables.<\/p>\n
Los GitHub Actions runners son una poderosa primitiva de automatizaci\u00f3n, pero tambi\u00e9n representan un entorno de ejecuci\u00f3n de alto riesgo.<\/p>\n
Ejecutan c\u00f3digo no confiable, manejan credenciales sensibles y producen artefactos en los que los sistemas posteriores conf\u00edan.<\/p>\n
Asegurar los runners requiere decisiones arquitect\u00f3nicas: efimeralidad, aislamiento, m\u00ednimo privilegio y separaci\u00f3n expl\u00edcita de niveles de confianza.<\/p>\n
Las organizaciones que tratan a los runners como entornos de ejecuci\u00f3n desechables y no confiables, en lugar de infraestructura confiable, est\u00e1n mucho mejor posicionadas para defenderse contra los ataques modernos de CI\/CD y cadena de suministro.<\/p>\n