A qué puede acceder CRACI y qué conserva

Por qué esta pregunta merece una respuesta directa

Un runner de CI ve más que la mayoría de las herramientas de su stack. Descarga su código fuente, instala sus dependencias y guarda los secretos que usan sus workflows para publicar paquetes y desplegar. Cuando la GitHub Action tj-actions/changed-files fue comprometida en marzo de 2025, CISA informó de que el código malicioso expuso secretos como claves de acceso, tokens de acceso personal de GitHub, tokens de npm y claves RSA privadas. El runner es donde residen esos secretos mientras se ejecuta un job.

Por eso, antes de dirigir un workflow a CRACI, debe saber exactamente a qué puede acceder. Las respuestas están a continuación, y el CRACI Trust Center y docs.craci.com ofrecen los detalles.

Para qué sirve la GitHub App

CRACI sustituye al runner, no a GitHub Actions. Usted conserva sus workflows, cambia runs-on a craci en los jobs que elija y las ejecuciones siguen apareciendo en la interfaz de GitHub. Para que esto funcione, su organización instala la GitHub App de CRACI.

Al instalarla, concede a la App acceso a todos los repositorios o a un conjunto seleccionado. Solo los repositorios a los que conceda acceso pueden ejecutar workflows en CRACI.

Los permisos exactos que solicita la App se indican en la pantalla de instalación de GitHub, y puede revisarlos después en la configuración de su organización. En resumen, la App puede leer su código y sus ejecuciones de Actions, y gestiona los runners que registra para su organización.

Dónde se ejecuta su código

Los jobs se ejecutan en máquinas virtuales aisladas. La ejecución de los builds se realiza en infraestructura bare-metal europea. Su código fuente se procesa dentro de la VM del job durante el build.

Cada job se ejecuta en una de tres imágenes: CRACI Slim, CRACI Slim ARM64 o una imagen de Ubuntu 24.04 compatible con GitHub. Hoy los runners son solo de Linux; Windows y macOS están en la hoja de ruta.

Cómo se aíslan los jobs y qué ocurre con la VM de un job cuando termina se documenta en docs.craci.com y en el Trust Center.

Qué almacena CRACI y durante cuánto tiempo

CRACI procesa su código fuente en la VM del job mientras se ejecuta el build y no lo almacena. Lo que conserva son las evidencias que registra sobre cada build, además de las cachés que guardan sus workflows:

• Metadatos del build
• Datos de paquetes, es decir, las dependencias que descargó cada job
• Trazas de red del job
• SBOM
• Registros de procedencia
• Cachés
• Registros de auditoría

Una caché contiene lo que su workflow ponga en ella, así que trate su contenido como cualquier otra salida del build.

El periodo de retención predeterminado es de 180 días. Los planes Enterprise pueden fijar un periodo de retención personalizado. La eliminación de datos y el cifrado se tratan en el Trust Center.

Alojamiento y residencia de datos

CRACI está alojado en Europa y ofrece residencia de datos en la UE, con la ejecución de los builds en infraestructura bare-metal europea. La plataforma funciona en Hetzner, un proveedor alemán, en un centro de datos de Tuusula, Finlandia. Consulte la residencia de datos para saber qué datos gestiona CRACI.

Controles sobre el propio build

Un runner que ve sus secretos también debería permitirle limitar adónde pueden ir. Las políticas de egress de red de CRACI establecen para cada job un valor predeterminado de denegar o permitir, con 24 ajustes predefinidos para fuentes de software habituales y fuentes personalizadas tipadas para registros como npm, PyPI, Cargo, Go proxy y OCI. También puede escribir reglas explícitas de TLS, TCP, UDP e ICMP. Las políticas se validan antes de que empiece el job; si fallan, bloquean, y rechazan los campos desconocidos. Las alertas señalan las infracciones de las políticas.

Los jobs salen desde un rango estable de IP de egress, de modo que puede permitir los runners de CRACI en sus propios firewalls por dirección.

Acceso dentro de su organización

• Los planes Enterprise admiten el inicio de sesión único SAML, con Google Workspace como proveedor de identidad.
• Un registro de auditoría de administración recoge las acciones administrativas. Está disponible en la interfaz y todavía no se puede exportar.
• Los tokens de API los crean los administradores, se pueden revocar en cualquier momento y caducan a los 90 días.

Cómo mantener un alcance reducido

No tiene que dar a CRACI acceso a toda su organización para evaluarlo.

1. Instale en repositorios seleccionados. Elija «Only select repositories» al instalar la App y seleccione uno o dos. Más adelante puede ampliar o reducir el conjunto desde Settings de su organización, en GitHub Apps, CRACI, Configure. El cambio surte efecto de inmediato.
2. Mueva los jobs de uno en uno. Solo los jobs con runs-on: craci se ejecutan en CRACI. Todo lo demás sigue en el runner que usa hoy.
3. Empiece con un job que tenga pocos secretos. Un job de pruebas o de lint le muestra la SBOM y las evidencias de red sin poner credenciales de publicación o despliegue en un nuevo runner.
4. Active una política de egress con denegación por defecto. Permita las fuentes de paquetes que necesita el job y nada más.
5. Sepa cómo marcharse. En GitHub puede suspender la App, lo que bloquea su acceso aunque siga instalada, o desinstalarla, lo que elimina su acceso a su organización.

Nuestra postura de seguridad

Nuestra página de seguridad explica cómo la abordamos: documentada, no afirmada. El Trust Center reúne las políticas, los controles y la documentación en los que se basa la plataforma, y es donde puede solicitar material para una evaluación de proveedores.

Esta página no hace ninguna afirmación sobre certificaciones. Para conocer el estado actual de nuestro programa de seguridad y de cualquier trabajo de auditoría, consulte el Trust Center.