Las GitHub Actions de terceros son una de las funcionalidades m\u00e1s convenientes del ecosistema de GitHub. Con una simple directiva Una action comprometida o maliciosa puede exfiltrar credenciales, inyectar c\u00f3digo en tus artefactos de compilaci\u00f3n, modificar variables de entorno para alterar pasos posteriores, o insertar puertas traseras en tus releases. A diferencia de las dependencias gestionadas por gestores de paquetes, las GitHub Actions carecen de un ecosistema robusto de verificaci\u00f3n, lo que las convierte en un objetivo principal para ataques a la cadena de suministro.<\/p>\n En este laboratorio pr\u00e1ctico, aprender\u00e1s a:<\/p>\n Al finalizar este laboratorio, tendr\u00e1s una estrategia de defensa en capas que reduce el riesgo de compromiso de la cadena de suministro a trav\u00e9s de GitHub Actions.<\/p>\n Antes de comenzar este laboratorio, aseg\u00farate de tener:<\/p>\n Crea un repositorio de prueba si no tienes uno:<\/p>\n Crea un archivo de workflow de ejemplo en Antes de comenzar a escanear y auditar, es importante entender c\u00f3mo las GitHub Actions se convierten en vectores de ataque. Existen varios m\u00e9todos de compromiso bien documentados:<\/p>\n Un atacante obtiene acceso a la cuenta de GitHub del mantenedor de una action \u2014 mediante credential stuffing, phishing o secuestro de sesi\u00f3n. Una vez que controla la cuenta, env\u00eda c\u00f3digo malicioso al repositorio de la action y actualiza los tags existentes para que apunten al commit comprometido. Cada workflow que referencia ese tag obtiene inmediatamente la versi\u00f3n maliciosa en su siguiente ejecuci\u00f3n.<\/p>\n Los tags de Git son mutables. Un mantenedor de action (o un atacante con acceso de escritura) puede eliminar un tag como Los atacantes crean actions con nombres confusamente similares a las populares. Por ejemplo:<\/p>\n Un solo error tipogr\u00e1fico en el YAML de tu workflow puede incorporar una action completamente diferente y maliciosa.<\/p>\n Muchas GitHub Actions est\u00e1n basadas en JavaScript y tienen sus propias dependencias en tj-actions\/changed-files (marzo 2023):<\/strong> Los atacantes comprometieron la ampliamente utilizada action codecov\/codecov-action (2021):<\/strong> El Bash Uploader de Codecov fue modificado por atacantes que obtuvieron acceso a trav\u00e9s de una imagen Docker comprometida utilizada en el proceso de CI de Codecov. El script manipulado exfiltr\u00f3 variables de entorno \u2014 incluyendo tokens de CI, claves API y credenciales \u2014 de los entornos de CI de los clientes. Esto afect\u00f3 a un gran n\u00famero de organizaciones que ejecutaban la action de Codecov en sus pipelines.<\/p>\n Estos incidentes comparten un patr\u00f3n com\u00fan: confianza en referencias mutables<\/strong>. Ambos podr\u00edan haberse mitigado fijando a SHAs inmutables y auditando el comportamiento de la action antes de adoptarla.<\/p>\n Las herramientas automatizadas son esenciales, pero no hay sustituto para entender lo que una action realmente hace. En este ejercicio, auditar\u00e1s manualmente tres actions de uso com\u00fan para desarrollar tu instinto para detectar patrones sospechosos.<\/p>\n Del workflow de ejemplo anterior, auditaremos:<\/p>\n Para cada action, comienza examinando el archivo Aspectos clave a buscar en Para actions de JavaScript\/TypeScript, examina el archivo compilado Usa esta lista de verificaci\u00f3n al auditar cualquier GitHub Action:<\/p>\n Aqu\u00ed tienes una auditor\u00eda resumida de Aplica este mismo proceso a cada nueva action antes de agregarla a tus workflows.<\/p>\nuses:<\/code>, puedes incorporar l\u00f3gica de compilaci\u00f3n compleja, desplegar en proveedores cloud o ejecutar esc\u00e1neres de seguridad. Pero esa conveniencia conlleva una contrapartida cr\u00edtica: cada action de terceros ejecuta c\u00f3digo en tu entorno de CI con acceso a tus secrets, tokens y c\u00f3digo fuente.<\/p>\n\n
Requisitos Previos<\/h2>\n
\n
gh<\/code>)<\/strong> \u2014 instalar desde cli.github.com<\/a><\/li>\nuses:<\/code><\/li>\n<\/ul>\ngh repo create actions-security-lab --public --clone\ncd actions-security-lab\nmkdir -p .github\/workflows<\/code><\/pre>\n.github\/workflows\/ci.yml<\/code> que usaremos a lo largo de este laboratorio:<\/p>\nname: CI Pipeline\non:\n push:\n branches: [main]\n pull_request:\n branches: [main]\n\npermissions:\n contents: read\n\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v4\n - uses: actions\/setup-node@v4\n with:\n node-version: '20'\n - uses: actions\/cache@v4\n with:\n path: ~\/.npm\n key: ${{ runner.os }}-npm-${{ hashFiles('**\/package-lock.json') }}\n - run: npm ci\n - run: npm test<\/code><\/pre>\nComprendiendo la Amenaza<\/h2>\n
Toma de Control de Cuenta del Mantenedor<\/h3>\n
Actualizaciones Maliciosas de Tags<\/h3>\n
v1<\/code> y recrearlo apuntando a un commit diferente. Si tu workflow usa uses: some-action\/tool@v1<\/code>, est\u00e1s confiando en que el tag siempre apunta a c\u00f3digo seguro. Esta confianza se viola f\u00e1cilmente.<\/p>\nTyposquatting<\/h3>\n
\n
actions\/checkout<\/code> (leg\u00edtima) vs. action\/checkout<\/code> (typosquat)<\/li>\nactions\/setup-node<\/code> vs. actions\/setup-nodejs<\/code><\/li>\ndocker\/build-push-action<\/code> vs. docker\/build-and-push-action<\/code><\/li>\n<\/ul>\nSecuestro de Dependencias<\/h3>\n
node_modules<\/code>. Si una dependencia de una action es comprometida (mediante un ataque a la cadena de suministro de npm), la propia action se convierte en un vector \u2014 incluso si el c\u00f3digo de la action en s\u00ed est\u00e1 limpio.<\/p>\nIncidentes Reales<\/h3>\n
tj-actions\/changed-files<\/code> al obtener acceso a la cuenta del mantenedor. Modificaron la action para exfiltrar secrets de CI\/CD volcando la memoria del runner y las variables de entorno a los logs del workflow. Miles de repositorios se vieron afectados porque referenciaban tags mutables en lugar de SHAs fijados.<\/p>\nEjercicio 1: Auditor\u00eda Manual de Actions<\/h2>\n
Paso 1: Seleccionar Actions a Auditar<\/h3>\n
\n
actions\/checkout@v4<\/code><\/li>\nactions\/setup-node@v4<\/code><\/li>\nactions\/cache@v4<\/code><\/li>\n<\/ol>\nPaso 2: Revisar
action.yml<\/code><\/h3>\naction.yml<\/code> en el repositorio de la action. Este archivo define las entradas, salidas y punto de entrada de la action.<\/p>\n# Clone the action to inspect locally\ngit clone --depth 1 https:\/\/github.com\/actions\/checkout.git \/tmp\/audit-checkout\ncat \/tmp\/audit-checkout\/action.yml<\/code><\/pre>\naction.yml<\/code>:<\/p>\n\n
node<\/code> (ejecuta JavaScript), composite<\/code> (ejecuta steps) o docker<\/code> (ejecuta un contenedor)? Cada tipo tiene un perfil de riesgo diferente.<\/li>\npost:<\/code>? Las post-actions se ejecutan incluso si el job falla, lo que las hace ideales para la exfiltraci\u00f3n.<\/li>\n<\/ul>\nPaso 3: Inspeccionar el C\u00f3digo Fuente<\/h3>\n
dist\/index.js<\/code> y el c\u00f3digo fuente en src\/<\/code>:<\/p>\n# Search for network calls\ngrep -rn 'https\\?:\/\/' \/tmp\/audit-checkout\/src\/ | grep -v 'github.com\\|api.github.com'\n\n# Search for secret access patterns\ngrep -rn 'GITHUB_TOKEN\\|process.env\\|getInput' \/tmp\/audit-checkout\/src\/\n\n# Search for file writes to sensitive locations\ngrep -rn 'GITHUB_ENV\\|GITHUB_OUTPUT\\|GITHUB_PATH' \/tmp\/audit-checkout\/src\/\n\n# Search for exec or spawn calls\ngrep -rn 'exec\\|spawn\\|child_process' \/tmp\/audit-checkout\/src\/<\/code><\/pre>\nPaso 4: Lista de Verificaci\u00f3n de Se\u00f1ales de Alerta<\/h3>\n
\n\n
\n \nSe\u00f1al de Alerta<\/th>\n Qu\u00e9 Buscar<\/th>\n Nivel de Riesgo<\/th>\n<\/tr>\n<\/thead>\n \n Llamadas de red a dominios desconocidos<\/td>\n fetch()<\/code>, http.request()<\/code>, curl<\/code> a dominios que no son de GitHub<\/td>\nCr\u00edtico<\/td>\n<\/tr>\n \n Acceso a secrets<\/td>\n Lectura de GITHUB_TOKEN<\/code>, secrets.*<\/code> o variables de entorno<\/td>\nAlto<\/td>\n<\/tr>\n \n Manipulaci\u00f3n del entorno<\/td>\n Escritura en GITHUB_ENV<\/code>, GITHUB_OUTPUT<\/code> o GITHUB_PATH<\/code><\/td>\nAlto<\/td>\n<\/tr>\n \n Ejecuci\u00f3n din\u00e1mica de c\u00f3digo<\/td>\n eval()<\/code>, exec()<\/code>, descarga y ejecuci\u00f3n de scripts<\/td>\nCr\u00edtico<\/td>\n<\/tr>\n \n C\u00f3digo ofuscado<\/td>\n Cadenas codificadas en Base64, c\u00f3digo minificado sin source maps<\/td>\n Alto<\/td>\n<\/tr>\n \n Hooks post-action<\/td>\n Punto de entrada post:<\/code> en action.yml<\/code><\/td>\nMedio<\/td>\n<\/tr>\n \n Permisos excesivos solicitados<\/td>\n La documentaci\u00f3n solicita permisos de write<\/code> m\u00e1s all\u00e1 de lo necesario<\/td>\nMedio<\/td>\n<\/tr>\n \n Sin verificaci\u00f3n ni firma<\/td>\n Action no proviene de un creador verificado, sin firmas Sigstore<\/td>\n Bajo-Medio<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Paso 5: Ejemplo de Auditor\u00eda \u2014
actions\/checkout@v4<\/code><\/h3>\nactions\/checkout@v4<\/code>:<\/p>\n# action.yml analysis\n# - Type: node20 (JavaScript action)\n# - Inputs: Accepts 'token' input (defaults to github.token)\n# - Post-action: Yes \u2014 runs cleanup to remove credentials\n\n# Network analysis\n# - Connects to: api.github.com (expected for git operations)\n# - No connections to third-party domains \u2713\n\n# Secret handling\n# - Uses GITHUB_TOKEN for authenticated git clone\n# - Token is persisted in git config by default (persist-credentials input)\n# - Post-action removes persisted credentials\n\n# Environment writes\n# - Does not write to GITHUB_ENV or GITHUB_PATH \u2713\n\n# Verdict: SAFE \u2014 behavior matches documented purpose\n# Recommendation: Set persist-credentials: false to minimize token exposure<\/code><\/pre>\nEjercicio 2: Escaneo de Actions con actionlint<\/h2>\n