Astral: Seguridad Total en Open Source

Astral, creadora de herramientas de desarrollo open source como Ruff y uv que confían millones de desarrolladores, publicó en 2026 su estrategia completa de seguridad para protegerse contra supply chain attacks. El documento detalla cómo mantienen CI/CD workflows seguros en GitHub Actions, previenen compromiso de credenciales y garantizan que sus herramientas no se conviertan en punto de entrada para atacantes (algo que pasó con herramientas populares como tj-actions/changed-files y Trivy en los últimos años).

Quién es Astral y por qué su seguridad importa

Astral es una empresa que desarrolla herramientas open source de infraestructura para Python (principalmente Ruff, un linter y formatter escrito en Rust, y uv, un gestor de paquetes). Millones de desarrolladores confían en estas herramientas como parte de su flujo de trabajo diario. Si alguna de ellas se comprome, el impacto potencial es masivo: cualquier código que pase a través de un Ruff o uv comprometido podría estar en riesgo.

Eso es importante porque (y fijate en esto) una cadena de suministro de software es como una manguera de riego: si vos atacas un punto en el medio, el problema se propaga a todos los finales. No atacás un solo sitio web o una sola empresa, atacás todos los proyectos que usan esa herramienta.

El contexto es que en los últimos años hemos visto ataques reales a herramientas populares. En 2025, una acción de GitHub llamada tj-actions/changed-files fue comprometida y expuso secretos de CI/CD en más de 23,000 repositorios. Similar pasó con Trivy en 2026, un scanner de vulnerabilidades que miles de equipos usan en sus pipelines. El pánico fue real porque si tu herramienta de seguridad te pone en riesgo, tenemos un problema.

El riesgo: supply chain attacks y por qué pasan

Un supply chain attack en software es cuando un atacante compromete una herramienta o librería en el medio de tu cadena de suministro, no directamente tu código. Ponele que estás usando Ruff en tu CI/CD para limpiar y formatear código antes de deployar. Si un atacante logra inyectar malware en Ruff, ese malware se ejecutaría en el contexto de tu pipeline, con acceso a secretos, variables de entorno, y credenciales de deploy. Más contexto en estrategias de seguridad en capas.

Eso es lo que pasó con tj-actions. Un atacante ganó acceso, modificó la acción de GitHub, y de repente 23,000 repos que confiaban en «changed-files» estaban expuestos. ¿Cómo pasó? Credenciales débiles, falta de MFA, acceso demasiado amplio a repositorios, y probablemente (aunque nadie lo confirmó públicamente) automatización de deploy sin protecciones suficientes.

El problema más profundo es que la mayoría de developers no piensan en seguridad de CI/CD. Muchos todavía usan tokens de acceso personal (PAT) en lugar de credenciales rotativas. Muchos dejan secretos en variables de entorno sin cifrado. Muchos no hacen auditoría de quién tiene acceso a qué.

Cómo Astral asegura sus herramientas

Astral publicó un documento describiendo sus técnicas. Las principales:

Pinning de commits en lugar de tags

Acá viene lo bueno: Astral no usa tags mutables en sus acciones de GitHub. Un tag es como una etiqueta que puede moverse. Si atacás un repo, podés reescribir el tag para apuntar a tu código malicioso, y cualquiera que use ese tag pull tu código sin saberlo. Astral, en cambio, pina commits por SHA (el hash criptográfico único). Un SHA no puede cambiar sin cambiar el contenido, así que es imposible de reescribir.

Esto significa que si vos querés usar una acción de Astral, sacás el SHA específico del commit y lo hardcodeás en tu workflow. Más tedioso de mantener, pero mucho más seguro. Sobre eso hablamos en automatizar tareas de seguridad.

Separación de credenciales y contexts

Los secretos de deploy (claves de API, tokens, credenciales de servidores) no viven en el mismo context que el código en desarrollo. Están en variables cifradas de GitHub, no en el repo, y solo accesibles en ciertos workflows. Si alguien compromete un pull request, esos secretos siguen protegidos porque no están expuestos en memoria.

GitHub mejoró esto en 2026 agregando la capacidad de limitar secretos a ciertos workflows y branches. Astral usa esto: los secretos sensibles solo se descifran cuando se ejecuta el workflow de release, no en cada pull request.

Tag protection y monitoreo en runtime

Astral protege sus tags de release para que solo ciertos usuarios autorizados puedan crear o modificar releases. Esto previene que alguien con acceso limitado cree una release falsa.

Además, monitorean en tiempo real cualquier actividad sospechosa: cambios en repositorios protegidos, accesos inesperados, modificaciones a workflows. Si algo se ve raro, se dispara una alerta antes de que se ejecute. Para más detalles técnicos, mirá herramientas IA para desarrolladores.

Prácticas que podés implementar en tu proyecto open source

Según la guía de OpenSSF publicada después de los ataques a tj-actions y reviewdog, estos son los pasos concretos:

• Auditar accesos: Revisá quién tiene write/admin en tu repo. Eliminá cuentas inactivas y reduce permisos al mínimo. Si alguien necesita permiso de release, no le des admin del repo entero.
• Cambiar tags por SHAs: En tus workflows, reemplazá `uses: org/action@v1.0` por `uses: org/action@abc123def456…`. Más trabajo de mantenimiento, pero más seguro.
• Implementar SBOM: Software Bill of Materials (SBOM) es una lista de todas tus dependencias. Publicá un SBOM con cada release. Herramientas como Syft generan esto automáticamente.
• Secret scanning: GitHub tiene secret scanning nativo. Activalo en tu repo. Busca API keys, tokens privados, credenciales que podrían haberse comiteado accidentalmente.
• Testing automático pre-release: No publiques sin pruebas. Astral ejecuta tests extensivos antes de cada release. Cualquier cambio tiene que pasar security scanning, linting, y tests unitarios.

El roadmap de GitHub 2026: egress firewall y más

GitHub anunció en su roadmap de seguridad para 2026 varias mejoras. La más importante para supply chain: egress firewall. Significa que podés bloquear directamente que un workflow envíe datos afuera de tu red o de dominios permitidos. Si tu workflow intenta exfiltrar datos a un servidor sospechoso, la red lo bloquea antes de que suceda.

Esto es especialmente útil para builds complejos donde ejecutás código de terceros (plugins, librerías). Si un plugin compromometido intenta robar datos, el firewall lo detiene.

Herramientas complementarias para auditar tu cadena de suministro

Errores comunes en CI/CD que facilitaría un ataque

Error #1: Usar tokens de acceso personal (PAT) en lugar de OIDC

Mucha gente todavía genera un PAT, lo pone en su .env o en una variable de GitHub, y lo usa para todo. El problema es que si se filtra, dura indefinidamente hasta que lo rotés manualmente. GitHub implementó OIDC (OpenID Connect) que genera tokens de vida corta, automáticos, específicos a cada workflow. Muchísimo más seguro. Si usás PAT, cambiá.

Error #2: Ejecutar workflows de pull requests con secretos

Un PR es código no confiable. Si permitís que el workflow de un PR acceda a secretos, cualquiera que abra un PR puede robar tus credenciales. Solución: secretos solo en `push` a `main`, no en `pull_request`.

Error #3: No revisar permisos de workflows

Por defecto, un workflow tiene permisos sobre `contents` (puede escribir en el repo). Si publicás un workflow que hace deploy, pensá bien qué permisos necesita realmente. Reducí a `read` cuando sea posible. Esto es en la sección `permissions` del yaml del workflow. Complementá con extensiones de seguridad gratuitas.

Preguntas Frecuentes

¿Qué es un supply chain attack exactamente?

Es cuando un atacante compromete una herramienta o librería que usas, en lugar de atacar directamente tu código. Así infiltran malware en miles de proyectos de una sola vez. El ejemplo clásico de 2025 fue tj-actions/changed-files, una acción de GitHub popular usada en más de 23,000 repositorios. Cuando fue comprometida, expuso credenciales de CI/CD en todos esos repos simultáneamente.

Si querés profundizar, tenemos un artículo sobre Open Source Security at Astral que aborda esto en detalle.

¿Cómo detecta GitHub Actions código malicioso en workflows?

Depende de lo que haya. GitHub tiene code scanning nativo que detecta patterns comunes (inyecciones, credenciales hardcodeadas). Pero código arbitrario es imposible de detectar 100%. Por eso la defensa es en capas: secrets scanning, SBOM, secret rotation, y permisos restrictivos.

¿Debo pinar todos mis workflows con SHA o solo los críticos?

Lo ideal es hacerlo en todos. Pero si es impracticable, priorizá los workflows que acceden a secretos o que publican código a producción. Si un workflow solo ejecuta tests y no toca deploy, el riesgo es menor.

¿Qué significa SBOM y por qué necesito publicar uno?

SBOM (Software Bill of Materials) es un documento que lista todas tus dependencias y sus versiones. Es como la tabla de contenidos de tu aplicación. Si una dependencia tiene una vulnerabilidad descubierta después de que publicaste tu release, vos (y tus usuarios) pueden saber rápidamente si están afectados buscando en el SBOM. Herramientas como Syft generan esto automáticamente en cada build.

¿Cómo implemento egress firewall en GitHub Actions sin perder funcionalidad?

El egress firewall de GitHub (roadmap 2026) aún está en beta. Cuando esté disponible, configurarás whitelist de dominios que tus workflows pueden contactar. Lo importante es hacer whitelist responsable: si tu build descarga dependencias desde npm.org, agregá eso a la whitelist. Si descarga desde tu internal registry, agregá ese. Bloqueás todo lo demás.

Conclusión

Astral publicó su playbook de seguridad en 2026 porque el problema es real. Supply chain attacks pasaron, van a seguir pasando, y cualquier mantenedor de open source que no tome precauciones está en riesgo de comprometer a millones de desarrolladores indirectamente.

Lo bueno es que las defensa no son ciencia espacial. Pinar commits por SHA, usar OIDC en lugar de PAT, restringir secretos, publicar SBOM, auditar accesos — son pasos concretos que podés implementar esta semana. GitHub mejora sus herramientas constantemente (egress firewall, secret rotation automática), pero la responsabilidad principal está en vos como mantenedor.

Si tu proyecto es open source y millones de personas lo usan, el costo de no hacer esto es potencialmente masivo. Si es más chico, el costo relativo baja pero el riesgo sigue existiendo. O sea, implementá estas prácticas hoy.

¿Por qué debo usar SHAs en lugar de tags en mis workflows?

Los tags son mutables: un atacante puede reescribir la etiqueta para apuntar a código malicioso. Un SHA es el hash único del commit y no se puede falsificar. Requiere más mantenimiento pero es mucho más seguro para acciones críticas.

¿Por qué los tokens PAT son menos seguros que OIDC?

Los PAT duran indefinidamente, así que si se filtran tenés un problema permanente hasta rotarlos. OIDC genera tokens de corta vida automáticos, específicos a cada workflow. No necesitás guardar credenciales permanentes en GitHub.

¿Qué es el egress firewall y cómo protege mi CI/CD?

Es una barrera que bloquea conexiones salientes sospechosas desde tus workflows. Si una acción comprometida intenta robar datos, el firewall la detiene antes de que ocurra. GitHub lo agregó en su roadmap 2026.

Fuentes

• Open Source Security at Astral — Blog oficial de Astral
• Maintainers Guide: Securing CI/CD Pipelines — Open Source Security Foundation
• GitHub Actions 2026 Security Roadmap — Blog oficial de GitHub
• Detecting, investigating, and defending against the Trivy supply chain compromise — Microsoft Security Blog
• Software Supply Chain Security Overview — Google Cloud Documentation