Seguridad Open Source en Astral: cómo protegen Ruff, uv y ty frente a ataques a la cadena de suministro

Astral comparte sus prácticas de seguridad para proteger herramientas como Ruff y uv. Descubre técnicas de CI/CD, lanzamientos seguros y gestión de dependencias.

En un ecosistema donde los ataques a la cadena de suministro de software se multiplican —como demuestran los recientes incidentes en Trivy y LiteLLM—, la confianza en las herramientas de desarrollo se ha convertido en un activo crítico.

Astral, la organización detrás de herramientas ampliamente adoptadas como Ruff, uv y ty, ha decidido compartir públicamente las técnicas que emplea para garantizar la seguridad de sus proyectos.

El objetivo es triple: informar a los usuarios sobre las medidas de protección, ofrecer recursos a otros mantenedores de código abierto y ayudar a los desarrolladores de sistemas CI/CD a diseñar flujos de trabajo más robustos por defecto.

Seguridad en CI/CD: Las bases de la protección

Astral mantiene su velocidad de desarrollo mediante flujos de trabajo extensivos de integración y entrega continua (CI/CD) ejecutados en GitHub Actions.

Estos procesos no solo aceleran las revisiones y pruebas, sino que constituyen un pilar fundamental de su postura de seguridad: mantienen los procesos críticos de desarrollo y lanzamiento fuera de las máquinas locales de los desarrolladores, dentro de entornos controlados y observables.

Sin embargo, GitHub Actions presenta desafíos importantes: sus configuraciones por defecto no son seguras, y compromisos como los de Ultralytics, tj-actions o Nx comenzaron explotando debilidades conocidas, como los triggers pull_request_target.

Para mitigar estos riesgos, Astral implementa varias prácticas clave:

• Prohibición de triggers peligrosos: Bloquean a nivel de organización el uso de triggers como pull_request_target y workflow_run, que son difíciles de asegurar y frecuentemente abusados por atacantes.
• Pinning de acciones a commits específicos: Todas las acciones deben referenciarse mediante hashes de commit inmutables, no mediante tags o ramas modificables. Esta práctica se verifica con herramientas como zizmor y con la política nativa de GitHub.
• Revisión manual de dependencias de acciones: Aunque el pinning garantiza inmutabilidad del código, no previene que una acción inmutable tome decisiones mutables (como descargar la última versión de un binario). Astral revisa manualmente estas dependencias y colabora con los mantenedores para cerrar brechas.
• Permisos mínimos por defecto: Los workflows comienzan con permissions: {} y solo se amplían a nivel de job cuando es estrictamente necesario.
• Aislamiento de secretos: En lugar de usar secretos a nivel de organización o repositorio, emplean entornos de despliegue con secretos específicos, limitando el radio de impacto de un posible compromiso.

Protección de repositorios y organización

Más allá de CI/CD, Astral aplica medidas estrictas para reducir la probabilidad y el impacto de compromisos en cuentas y repositorios:

• Acceso mínimo privilegiado: La mayoría de los miembros de la organización solo tienen permisos de lectura y escritura en los repositorios que necesitan, reduciendo la superficie de ataque.
• Autenticación de dos factores reforzada: Exigen métodos 2FA más seguros que el mínimo de GitHub, como TOTP, con planes de migrar exclusivamente a métodos resistentes a phishing (WebAuthn, Passkeys) cuando la plataforma lo permita.
• Reglas de protección de ramas: Los cambios a main requieren pull requests y prohíben force-push. También bloquean patrones de ramas específicos (como advisory-*) para prevenir filtraciones prematuras de trabajo de seguridad.
• Protección de tags de lanzamiento: Los tags de release solo pueden crearse tras un despliegue exitoso aprobado manualmente por al menos otro miembro del equipo. Una vez creados, los tags son inmutables.
• Protecciones a nivel de organización: Todas estas reglas se aplican a nivel organizativo, lo que significa que incluso un atacante que comprometa una cuenta con permisos de administrador en un repositorio específico no podrá desactivar estos controles.

Automatizaciones seguras: Cuándo salir de GitHub Actions

Existen tareas que GitHub Actions puede realizar, pero no de forma segura (como dejar comentarios en issues o pull requests de terceros). En estos casos, Astral opta por aislar estas operaciones fuera de GitHub Actions mediante astral-sh-bot, una GitHub App que recibe los mismos eventos de webhook pero con mayor control y menos estado implícito.

No obstante, las GitHub Apps no eliminan por completo los riesgos: simplemente trasladan las credenciales sensibles a un entorno donde el código y los datos no se mezclan tan pervasivamente.

Una App podría seguir siendo vulnerable a inyecciones SQL, prompt injection u otras debilidades. Por ello, Astral enfatiza que el desarrollo de GitHub Apps debe abordarse con la misma mentalidad de seguridad que cualquier otro software.

Para proyectos que necesiten ejecutar código no confiable, la recomendación es usar triggers “seguros” como pull_request, que no proporcionan credenciales privilegiadas a pull requests de terceros. Aunque desarrollar y alojar una GitHub App añade complejidad, Astral considera que el patrón vale la pena para casos de uso específicos y recomienda frameworks como Gidgethub para simplificar el desarrollo.

Seguridad en lanzamientos: Protegiendo la cadena de suministro

Muchos usuarios instalan las herramientas de Astral a través de múltiples canales: PyPI, Homebrew, imágenes Docker, etc. Cada uno de estos eslabones requiere consideraciones de seguridad específicas:

• Trusted Publishing: Siempre que es posible, utilizan publicación confiable (Trusted Publishing) para registrar paquetes en PyPI, crates.io o NPM. Esta técnica elimina la necesidad de credenciales de larga duración, mitigando uno de los vectores más comunes de toma de control de paquetes.
• Atestados Sigstore: Para binarios e imágenes Docker, generan atestados basados en Sigstore que establecen un vínculo criptográficamente verificable entre el artefacto publicado y el workflow que lo produjo.
• Releases inmutables en GitHub: Habilitan la función de releases inmutables para prevenir modificaciones posteriores a los builds publicados, una técnica que atacantes han usado para reemplazar versiones legítimas con código malicioso.
• Sin caché en lanzamientos: Evitan el uso de caché durante los procesos de release para prevenir ataques de envenenamiento de caché en GitHub Actions.
• Aprobaciones multi-persona: Los despliegues de release requieren aprobación manual de al menos otro miembro privilegiado, reduciendo el riesgo de que una cuenta comprometida publique una versión maliciosa.
• Entornos de despliegue dedicados: El proceso de release se aísla en un entorno de despliegue específico de GitHub, al que solo tienen acceso los jobs autorizados.

Para usuarios que instalan uv mediante el instalador independiente, Astral incluye checksums embebidos directamente en el código fuente del instalador, permitiendo verificar la integridad de los binarios descargados.

Gestión de dependencias: El eslabón más débil

Como casi todo el software moderno, las herramientas de Astral dependen de un ecosistema de dependencias de terceros, cada una en una posición implícita de confianza. Para medir y mitigar estos riesgos upstream, implementan:

• Actualización automatizada con cooldowns: Usan Dependabot y Renovate para mantener dependencias actualizadas, pero aplican períodos de enfriamiento para evitar actualizar inmediatamente después de un nuevo release, momento en que las dependencias comprometidas temporalmente son más peligrosas.
• Conexiones sociales con mantenedores upstream: Mantienen relaciones activas con muchos de sus proyectos dependientes, contribuyendo regularmente con mejoras de seguridad y procesos CI/CD.
• Participación en grupos de trabajo del ecosistema: Colaboran con organizaciones como Python Packaging Authority y Python Security Response Team para compartir información sobre vulnerabilidades y coordinar respuestas.
• Conservadurismo en nuevas dependencias: Son selectivos al añadir nuevas dependencias y buscan eliminar aquellas que no son estrictamente necesarias o que introducen blobs binarios.
• Apoyo financiero al ecosistema: Contribuyen a través de su OSS Fund a la sostenibilidad de proyectos de los que dependen o que impulsan el ecosistema open source en general.

Lecciones clave para la comunidad open source

Astral concluye compartiendo reflexiones que merecen especial atención para cualquier proyecto que busque fortalecer su seguridad:

1. Respeta los límites de CI/CD: Es tentador hacerlo todo en CI/CD, pero hay tareas que GitHub Actions no puede realizar de forma segura. En esos casos, es preferible omitirlas o aislarlas mediante GitHub Apps.
2. No descartes CI/CD por completo: A pesar de sus desafíos, CI/CD es crítico para la seguridad y la velocidad de desarrollo. El esfuerzo por asegurar GitHub Actions vale la pena frente a los riesgos de no usar CI/CD alojado.
3. Elimina o aísla credenciales de larga duración: El abuso de credenciales persistentes es el vector más común de propagación post-compromiso. Usa Trusted Publishing u OIDC cuando sea posible; si no, aísla las credenciales en entornos específicos con permisos mínimos.
4. Fortalece los procesos de lanzamiento: En GitHub, combina entornos de despliegue, aprobaciones manuales, reglas de ramas/tags y releases inmutables para reducir las opciones de un atacante tras un compromiso.
5. Mantén conciencia de tus dependencias: Comprender la salud general de tu árbol de dependencias es esencial para evaluar tu perfil de riesgo. Usa herramientas y esfuerzo manual para mantener seguras tanto tus dependencias como las de tus dependencias.

Conclusión

La seguridad en el código abierto es un problema complejo que abarca dimensiones técnicas y sociales. Las prácticas compartidas por Astral no representan una solución definitiva, sino un punto en el tiempo de un proceso continuo de adaptación frente a amenazas dinámicas.

Lo más valioso de este enfoque es su transparencia: al documentar y compartir sus técnicas, Astral no solo fortalece sus propios proyectos, sino que eleva el estándar para toda la comunidad.

En un mundo donde la confianza en el software es cada vez más frágil, iniciativas como esta demuestran que la seguridad no es un lujo, sino una responsabilidad compartida que requiere colaboración, vigilancia constante y voluntad para evolucionar.