123% más CVE notificadas al día en 2026 que el año pasado.

Seguridad de CI/CD

Cómo frenar la exfiltración desde GitHub Actions con una política de egress

Un job de CI guarda secretos y ejecuta código que descargó hace un minuto: acciones, paquetes y sus scripts de instalación. Si alguna parte de ese código es maliciosa, la forma más fácil de robar los secretos es enviarlos a un servidor. Una política de egress decide a qué servidores puede llegar un job y bloquea el resto.

Actualizado el

Cómo salen los secretos de un job de CI

Un job tiene acceso al token del repositorio, a los secretos que se le pasan y a las credenciales de nube que asume. El código que se ejecuta en el job puede leerlos. Después puede sacarlos de varias formas:

  • Por la red. Una petición a un servidor que controla el atacante. Este es el canal que cierra una política de egress.
  • A través de los logs. Imprimir los secretos, a menudo codificados, en el log del job. En marzo de 2025, CISA informó de que la acción comprometida tj-actions/changed-files expuso secretos de esta forma.
  • A través de las salidas. Artefactos, cachés o commits enviados con el token del job.

El código no tiene por qué ser un paquete malicioso. Un agente de IA en el workflow puede ser manipulado mediante una inyección de prompts oculta en una issue o una pull request, y usar después los mismos canales.

Qué hace una política de egress

La mayoría de los jobs necesitan llegar a una lista corta de destinos: registros de paquetes, registros de contenedores, hosts de código fuente y algunos servicios. Una política de egress permite esa lista y bloquea todo lo demás. Con una política de denegación por defecto, una petición a un host desconocido falla y los secretos se quedan en el job.

What happens when malware in a build tries to send your secrets out Left, a runner that allows all outbound traffic: the build reaches its package registry and publishes its output, then a malicious install hook sends the build's secrets to an attacker's server, and they arrive. Right, CRACI with a default-deny egress policy: the registry and publish connections are allowed, the connection to the attacker's server is blocked at the policy, and an alert is sent. The policy allows only what the build needs, so it works even against an attack nobody has seen before. Any outbound allowed build job holds your tokens and keys malicious install hook runs no egress policy package registry publish output attacker server allowed allowed secrets sent to the attacker CRACI default-deny egress policy build job on CRACI holds your tokens and keys malicious install hook runs egress policy: only what the build needs package registry publish output attacker server allowed allowed blocked blocked, and you get an alert
The policy allows only what the build needs, instead of looking for known-bad hosts, so it stops a new attack the first time it runs.

No cierra todas las puertas:

  • No impide que los secretos se impriman en los logs. Mantenga los logs privados y fije las acciones a SHA de commit.
  • Un destino permitido aún puede sacar datos, así que mantenga la lista de permitidos ajustada.
  • No le dice qué paquetes eran maliciosos. Eso corresponde al examen de paquetes y a una SBOM.

Tres formas de aplicarla

  • Un agente en el runner. StepSecurity Harden-Runner se añade como primer paso de un job. Asocia cada conexión con el paso que la hizo, crea una línea de base en modo de auditoría y bloquea el egress a todo lo que no esté en una lista de permitidos.
  • Un runner con una política integrada. CRACI aplica la política como el propio runner. Otros proveedores de runners también ofrecen controles de red, como el filtrado de egress en los runners Linux de Depot y las políticas de egress de bloqueo o de aviso en Namespace.
  • Su propia red. Runners autoalojados detrás de un firewall o proxy que usted configura y mantiene.

Cómo implantarla sin romper los builds

  1. Observe. Registre todas las conexiones que hace un job a lo largo de varias ejecuciones.
  2. Permita. Elabore la lista de permitidos a partir de lo que el job necesita realmente.
  3. Bloquee. Pase a la denegación por defecto y esté atento a las infracciones.
  4. Revise. Trate cada nueva infracción como una fuente que falta o como un incidente.

Cómo lo hace CRACI

En CRACI, la política de egress forma parte del runner. Se valida antes de que empiece el job, los campos desconocidos se rechazan y, si falla, bloquea. Los presets integrados cubren las fuentes de paquetes habituales, y las fuentes y conexiones personalizadas añaden el resto. La traza del job enumera todas las conexiones, y cada una de las bloqueadas como infracción con su motivo. Como el proxy entiende de paquetes, ese mismo registro se convierte en la SBOM del job. La API devuelve SBOM, trazas de red y procedencia.

CRACI aún no tiene un modo de auditoría específico; está en la hoja de ruta. Sin una política de red, el tráfico de un job se permite y se registra en la traza, de modo que puede ver lo que necesita una política antes de aplicarla. CRACI ejecuta jobs de GitHub Actions en Linux. Consulte la comparativa de herramientas de seguridad de CI/CD y CRACI frente a StepSecurity.

Políticas de egress en CI: preguntas frecuentes

¿Qué es una política de egress en CI?

Un conjunto de reglas sobre las conexiones de red salientes que puede hacer un job de CI. El job puede llegar a los registros de paquetes y servicios que necesita, y cualquier otro destino queda bloqueado.

¿Una política de egress habría detenido el ataque a tj-actions?

No por sí sola. En ese caso, CISA informó de que los secretos quedaron expuestos a través de los logs del workflow, no enviados a un servidor externo. Una política de egress cierra el canal de red; fijar las acciones a SHA de commit y mantener privados los logs se ocupan del canal de los logs.

¿Bloquear el egress rompe los builds?

Puede hacerlo, si a la política se le escapa una fuente que el build necesita. Empiece por registrar a qué se conecta el job, elabore la lista de permitidos a partir de ello y luego bloquee. En CRACI, los presets integrados cubren las fuentes de paquetes habituales, y una conexión bloqueada aparece en la traza del job con el motivo.

¿Puedo usar una política de egress en runners alojados por GitHub?

Sí, con un agente añadido al job, como StepSecurity Harden-Runner. O bien traslade el job a un runner que aplique la política por sí mismo, como CRACI.

Ponga un job tras una política de egress

Ejecute un workflow en CRACI y vea todas las conexiones que hizo, cuáles bloquearía una política de denegación por defecto y la SBOM de lo que descargó.

Reservar una demo