Astral, creadores de Ruff y uv, revela por completo su estrategia de seguridad open source
(astral.sh)Astral crea herramientas de las que dependen millones de desarrolladores en todo el mundo (Ruff, uv, ty), y recientemente, a raíz de los incidentes de hackeo a la cadena de suministro de Trivy y LiteLLM, dio a conocer sus prácticas de seguridad. El texto apunta a tres tipos de lectores: usuarios, otros maintainers de open source y desarrolladores de sistemas CI/CD.
1. Seguridad de CI/CD
Los valores predeterminados de seguridad de GitHub Actions son vulnerables, y los incidentes de compromiso en Ultralytics, tj-actions y Nx surgieron todos de triggers riesgosos como pull_request_target. La respuesta de Astral es la siguiente:
Prohibición total de triggers peligrosos
Prohíben en toda la organización triggers como pull_request_target y workflow_run, que son casi imposibles de usar de forma segura. La mayoría de los proyectos cree que necesita estos triggers, pero en la práctica, en la mayoría de los casos basta con el trigger de menor privilegio pull_request o incluso con logs simples del workflow.
Hash pinning de commits de Actions
En lugar de usar tags o ramas (que pueden cambiar), fijan cada acción a un SHA de commit específico y verifican de forma cruzada que ese commit realmente coincida con el estado del release para evitar "commits impostores". Usan zizmor junto con las políticas nativas de GitHub, y el hash pinning se aplica también a todas las acciones anidadas que se invocan indirectamente.
Principio de mínimo privilegio
A nivel organización, configuran los permisos predeterminados como solo lectura, y todos los workflows empiezan con permissions: {} para agregar únicamente los permisos necesarios por job. Los secretos tampoco se dejan a nivel organización o repositorio, sino que se aíslan por entorno de despliegue para que los jobs de prueba no puedan acceder a los secretos de release.
2. Seguridad de repositorios y de la organización
Minimizan la cantidad de administradores y cuentas con privilegios elevados, y la mayoría de los miembros de la organización solo tiene permisos de lectura y escritura sobre los repositorios que necesita. Para 2FA exigen al menos TOTP, un nivel más fuerte que el valor predeterminado de GitHub (cualquier método), y planean endurecerlo más adelante para permitir solo WebAuthn y passkeys.
La rama main está protegida con reglas que impiden el force push y exigen pull requests, y los tags de release solo pueden crearse después de que el despliegue se complete con éxito. En particular, estas reglas se hacen cumplir a nivel organización para que ni siquiera los administradores del repositorio puedan saltárselas.
3. Automatización (uso de GitHub App)
Las tareas que no pueden hacerse de forma segura desde GitHub Actions, como dejar comentarios en PRs de terceros, se separan en la GitHub App astral-sh-bot. Aun así, Astral subraya que las GitHub Apps tampoco están libres de vulnerabilidades, y que cuando sea necesario ejecutar código no confiable se debe usar obligatoriamente el trigger pull_request.
4. Seguridad de releases
Para publicar en PyPI, crates.io y NPM usan Trusted Publishing, que permite desplegar sin credenciales de largo plazo, y adjuntan attestations basadas en Sigstore a binarios e imágenes de Docker para proporcionar una conexión criptográfica entre los artefactos de release y los workflows.
Usan la función de immutable releases de GitHub para impedir modificaciones posteriores a builds ya publicados, y prohíben el uso de caché durante el build de release para bloquear ataques de cache poisoning.
El proceso de release en sí también está protegido por duplicado: para activar el entorno de release se requiere la aprobación manual de al menos otro miembro autorizado de la organización. Es decir, para producir un release malicioso habría que comprometer al mismo tiempo dos cuentas protegidas con 2FA fuerte.
5. Seguridad de dependencias
Gestionan las actualizaciones de dependencias y las alertas de vulnerabilidades conocidas con Dependabot y Renovate, pero además aplican una política de "cooldown" que evita actualizar de inmediato justo después de un nuevo release. Esto busca minimizar el impacto de dependencias comprometidas temporalmente. uv ya incorpora esta función.
Mantienen vínculos sociales con proyectos y grupos de trabajo cercanos, como Python Packaging Authority (PyPA) y el Python Security Response Team, para compartir información, por ejemplo cuando un problema reportado en pip también puede afectar a uv. Abordan con cautela la incorporación de nuevas dependencias, evitan dependencias que incluyan binary blobs y desactivan funciones innecesarias.
También siguen realizando contribuciones financieras mediante OSS Fund para apoyar la sostenibilidad de los proyectos de los que dependen.
Resumen de recomendaciones clave
Astral destaca cuatro principios centrales: reconocer los límites de CI/CD y abandonar sin miedo las tareas que no pueden hacerse de forma segura o separarlas en una GitHub App; eliminar en lo posible las credenciales de largo plazo y aislarlas al mínimo alcance necesario; reforzar el proceso de release con entornos de despliegue, aprobaciones y tags inmutables; y mantener visibilidad continua sobre el estado de salud de todo el árbol de dependencias.
Implicaciones
Visto desde la perspectiva de quien está profundamente involucrado en PyPI y en la seguridad de la cadena de suministro, este texto va más allá de una simple guía de seguridad: es un caso práctico sobre cómo diseñar la estructura de confianza de todo el ecosistema open source. En especial, Trusted Publishing, la política de cooldown y el proceso de releases con doble aprobación son prácticas que vale la pena considerar en proyectos open source de cierta escala.
Original: Astral Blog, 2026.04.08
Aún no hay comentarios.