La estrategia de seguridad de código abierto de Astral

 (astral.sh)
1 puntos por GN⁺ 19 일 전 | 1 comentarios | Compartir por WhatsApp
  • Astral, que desarrolla herramientas como Ruff, uv y ty usadas por desarrolladores de todo el mundo, mantiene la seguridad y confiabilidad de todos sus productos como un valor central
  • En respuesta al reciente aumento de los ataques a la cadena de suministro, publicó sus técnicas internas para reforzar la seguridad en todo el proceso de compilación, despliegue y lanzamiento
  • En su CI/CD basado en GitHub Actions, aplica un sistema de protección en múltiples capas con fijación de hashes, privilegios mínimos y separación de secretos, entre otras medidas
  • En la etapa de lanzamiento, garantiza la integridad de la distribución con Trusted Publishing, attestations de Sigstore e Immutable Releases
  • Con este enfoque, Astral busca elevar el nivel de seguridad de todo el ecosistema open source y construir un sistema de defensa sostenible

El enfoque de seguridad open source de Astral

  • Astral desarrolla herramientas como Ruff, uv y ty, utilizadas por millones de desarrolladores en todo el mundo, y mantiene la seguridad y confiabilidad de estas herramientas como un valor central
  • A medida que aumentan los ataques a la cadena de suministro, incluidos casos como los hackeos de Trivy y LiteLLM, Astral publicó sus técnicas internas de seguridad para garantizar la seguridad de sus herramientas y de sus procesos de compilación y despliegue
  • Comparte buenas prácticas de seguridad que pueden servir como referencia para usuarios, mantenedores de open source y desarrolladores de sistemas CI/CD

Seguridad de CI/CD

  • Astral automatiza el desarrollo y el despliegue mediante amplios flujos de trabajo de CI/CD basados en GitHub Actions, y los utiliza como un componente clave de su seguridad
    • Esto permite que las compilaciones y pruebas se ejecuten en un entorno controlado y observable, en lugar de un entorno local
  • Reconociendo que la configuración de seguridad predeterminada de GitHub Actions es débil, aplica las siguientes medidas de refuerzo
    • Prohibición total de triggers riesgosos como pull_request_target y workflow_run
    • Fijación de todas las acciones a un hash de commit (SHA) específico y verificación cruzada para detectar si se trata de un impostor commit
    • Uso combinado de las herramientas de auditoría unpinned-uses e impostor-commit de zizmor junto con políticas de GitHub
    • Fijación por hash de todo el grafo de dependencias, incluidas las acciones dependientes indirectas que no pueden fijarse directamente
  • Como fijar hashes por sí solo no es suficiente, detecta defectos de inmutabilidad mediante revisión manual y, cuando hace falta, colabora con proyectos upstream para corregirlos
    • Ejemplo: mapear URLs de descarga de binarios y sus hashes para integrarlos de forma inmutable
  • Los permisos de los workflows se restringen a solo lectura por defecto, y a cada job se le otorgan únicamente los permisos mínimos necesarios
  • Los GitHub Secrets se gestionan como variables de entorno de despliegue separadas por entorno, para que tareas de prueba y lint no puedan acceder a secretos de lanzamiento
  • Como herramientas auxiliares, usa zizmor (análisis estático) y pinact (fijación automática por hash)

Seguridad del repositorio y de la organización

  • Astral minimiza la cantidad de cuentas con privilegios de administrador dentro de la organización, y la mayoría de los miembros solo tiene permisos de lectura y escritura en los repositorios que necesita
  • Exige autenticación de dos factores (2FA) fuerte para todos los miembros, usando al menos un método del nivel de TOTP
    • Si GitHub pasa a permitir únicamente métodos resistentes al phishing (WebAuthn, Passkeys), planea migrar de inmediato
  • Aplica reglas de protección de ramas en toda la organización
    • En la rama main no se permite force push y todos los cambios solo pueden entrar mediante PR
    • Se prohíbe crear patrones de ramas específicos como advisory-* e internal-*
  • Mediante reglas de protección de tags, los tags solo pueden crearse después de que el despliegue del release se complete correctamente
    • Está prohibido modificar o eliminar tags, y los releases solo pueden generarse desde la rama main
  • Ni siquiera los administradores del repositorio pueden saltarse las reglas de protección; toda la protección se impone a nivel de organización
  • Astral publicó este conjunto de reglas como gist para que otros proyectos puedan tomarlo como referencia

Automatización

  • Con GitHub Actions no es posible realizar de forma segura algunas tareas, como dejar comentarios en PRs de terceros
  • Para resolver esto, Astral usa la GitHub App astral-sh-bot para procesar eventos de forma segura fuera de Actions
    • La GitHub App recibe los mismos datos de eventos, pero se ejecuta en un entorno donde código y datos están separados
  • Aun así, la App no elimina las credenciales sensibles
    • Puede tener vulnerabilidades como SQLi o prompt injection, por lo que debe desarrollarse con el mismo nivel de seguridad que cualquier software general
    • Usar una App no significa automáticamente garantizar la seguridad al ejecutar código no confiable
  • El enfoque con GitHub App es ventajoso en términos de seguridad, pero aumenta la complejidad
    • Requiere desarrollar y alojar la App, lo que puede ser una carga para desarrolladores individuales o proyectos pequeños
    • El framework Gidgethub para Python simplifica el desarrollo
  • Astral planea publicar astral-sh-bot como open source y recomienda como referencia el tutorial de Mariatta

Seguridad de los releases

  • Las herramientas de Astral se distribuyen por varios canales además de GitHub, como PyPI, Homebrew e imágenes de Docker
  • Para prevenir ataques a la cadena de suministro, aplica las siguientes medidas
    • Usa Trusted Publishing para eliminar credenciales de registro
    • Genera attestations basadas en Sigstore para garantizar la vinculación criptográfica entre los artefactos de compilación y los workflows
      • Usa la función Immutable Releases de GitHub para impedir modificaciones después de la publicación
      • No usa caché de compilación, bloqueando ataques de contaminación de caché
      • El proceso de release está aislado en un deployment environment dedicado
      • Al activar el entorno de release, se requiere la aprobación de otro miembro del equipo, evitando releases maliciosos por el compromiso de una sola cuenta
      • Mantiene una aprobación multinivel con el entorno release-gate y un relay de aprobación basado en GitHub App
      • Los tags solo pueden crearse después de que el release se complete correctamente
      • El standalone installer verifica la integridad de los binarios con checksums integrados
      • Después del release, tareas como actualizar documentación, manifiestos de versión y hooks de pre-commit se realizan con una cuenta de bot dedicada y PATs granularizados
      • En el futuro planea añadir firma de código para macOS y Windows

Seguridad de dependencias

  • Astral usa Dependabot y Renovate para gestionar actualizaciones de dependencias y alertas de vulnerabilidades
  • Aplica un período de cooldown para retrasar actualizaciones justo después de nuevos releases y así mitigar riesgos temporales de ataques a la cadena de suministro
    • Renovate admite configuración de cooldown por grupo, y se aplica una mitigación a las dependencias propias
  • Mantiene colaboración continua y aportes de seguridad con proyectos upstream importantes
  • Colabora con entidades como la Python Packaging Authority y el Python Security Response Team para compartir información de seguridad
  • Evalúa con cuidado la incorporación de nuevas dependencias y promueve eliminar las innecesarias
    • En particular, evita dependencias que incluyan blobs binarios y desactiva funciones innecesarias
  • Brinda apoyo financiero a proyectos open source clave mediante OSS Fund

Conclusión y lecciones clave

  • La seguridad open source es una combinación de problemas técnicos y sociales y requiere una respuesta continua
  • Principios clave que Astral destaca
    • Reconocer los límites del CI/CD y, cuando sea inevitable, usar métodos de aislamiento externo como GitHub App
    • Eliminar y minimizar credenciales de largo plazo, aprovechando Trusted Publishing y autenticación OIDC
    • Reforzar el proceso de release, aplicando reglas de aprobación, tags, ramas e Immutable Release
    • Mantener visibilidad sobre las dependencias y, con herramientas y colaboración, fortalecer también la seguridad de los proyectos upstream
  • Astral seguirá evaluando y mejorando estas técnicas, y planea evolucionar sus defensas según cambie el comportamiento de los atacantes

Resumen de notas al pie

  • El PEP 740 de PyPI permite subir attestations, pero por ahora su adopción está en espera porque no es compatible con la implementación actual de Trusted Publishing de Astral
  • Los checksums dentro del script de instalación tienen una efectividad limitada cuando se ejecuta directamente con curl ... | bash, pero son útiles al hacer vendoring dentro de CI/CD

Lecturas relacionadas

1 comentarios

 
GN⁺ 19 일 전
Opiniones de Hacker News

  • Parece que hay que pasar por demasiados pasos para usar de forma segura el CI de GitHub
    Con una estructura así, creo que es imposible operarlo de forma segura desde el punto de vista de seguridad
    Da la impresión de que no se puede construir seguridad de la cadena de suministro sobre un sistema que ni siquiera respeta principios básicos como separación de privilegios o aislamiento

    • Yo pienso algo parecido. Hace poco estuve investigando cómo ejecutar de forma segura código escrito por agentes en GitHub Actions, y tuve cierto éxito con sandbox-action
      Pero la configuración es demasiado delicada, así que no parece un enfoque escalable. Si los valores predeterminados fueran más seguros, sería mucho mejor
    • Me pregunto si alguien ha visto algún sistema de build alternativo que valga la pena usar en lugar de este CI tan complejo de GitHub
      Después de leer todo el artículo, me quedó la sensación de que esta complejidad podría ser un problema inherente de esta área
    • En realidad, esto no es distinto del problema general de los registros de paquetes
      La mayoría no soporta releases inmutables, e incluso cuando lo hacen, su estructura de traer automáticamente versiones nuevas los deja expuestos a ataques
      Para hacerlo realmente seguro, habría que administrar dependencias verificadas con versiones fijas en un registro propio, pero eso es algo que prácticamente solo Google puede hacer

  • El binario de uv de stagex que hizo nuestro equipo es el único en el mundo construido con bootstrap completo desde el código fuente y artefactos deterministas con múltiples firmas
    Usa un esquema de firmas basado en smartcards, conectado por una red de confianza de 25 años y más de 5000 llaves
    Lo frustrante es que los voluntarios estén tomándose más en serio esta seguridad de la cadena de suministro

    • El mercado ya dio su respuesta. La gente quiere comodidad antes que seguridad
      Aunque herramientas como OpenClaw hagan posible filtrar llaves y secretos, la gente las sigue usando
      Tú intentas reducir la superficie de ataque, pero el mercado la está ampliando aún más
    • En realidad no es para enojarse. Tú estás creando una distribución Linux reproducible, y con eso tus socios venden servicios de soporte
      Sin voluntarios, proyectos como Debian tampoco existirían. En vez de quejarse, hay que competir con mejores resultados
    • (Soy el autor del artículo) La cantidad o antigüedad de las llaves no es una medida de confianza
      Si al final se trata de entregar artefactos construidos por un tercero, no queda claro cuál es el modelo de amenazas
      Todos los builds de uv salen de una resolución bloqueada y ofrecen artefactos firmados. No está claro cuál sería el valor de commits firmados por otro conjunto de identidades
    • La propia licencia open source está diseñada para que las empresas puedan usarlo gratis
      No hay motivo para que OpenAI gaste dinero reforzando la seguridad de la cadena de suministro
    • Apenas han pasado unas semanas desde la adquisición; si OpenAI hubiera cambiado ya el proceso de build, eso habría sido más raro
      Entiendo la crítica técnica, pero por el momento me parece exagerado atribuírselo a OpenAI

  • Como referencia, el Trusted Publishing de PyPI fue implementado en conjunto por William Woodruff y el equipo de Trail of Bits

  • Me gustaría preguntarle al equipo de Astral cómo gestionan una situación en la que, aun con tanto esfuerzo, siguen dependiendo bastante de GitHub
    ¿Cómo responderían si GitHub fuera hackeado o si un bug cambiara la configuración?

    • Nosotros también nos comunicamos directamente con GitHub. Como es infraestructura crítica, monitoreamos de cerca los cambios de la plataforma
    • GitHub de verdad tiene muchísimos bugs. Es común incluso que un workflow falle al clonar una rama de su propio repositorio

  • El ecosistema open source es resiliente, pero el sandboxing de código de terceros sigue siendo insuficiente
    Cada vez que uso uv se destaca la ventaja de poder manejar varias versiones de Python con facilidad, pero eso también significa que se ejecuta en la máquina host sin aislamiento, y eso me inquieta

    • Yo siempre uso uv dentro de Docker. En ese caso sí resulta bastante práctico

  • El gran problema actual de la cadena de suministro es que muchas herramientas y dependencias se descargan sin verificación de procedencia
    Por eso estoy desarrollando asfaload, una solución open source de verificación de archivos con multifirma
    Es una estructura que podría prevenir incidentes como el de axios

    • ¿No es justamente ese el propósito de las release attestations? Mira la documentación relacionada
    • Creo que la dirección es correcta. Pero como el código o el producto todavía no están públicos, es difícil evaluarlo
    • Más que verificar autores específicos, creo que sería mejor revisar todo el código con herramientas automáticas de auditoría de código

  • Aunque fijes GitHub Actions a un commit SHA, sigue habiendo riesgo si esa acción trae otras dependencias
    La solución real en el pipeline de CI es poseer directamente el código o hacer un fork y mantenerlo por cuenta propia

    • También se menciona en el artículo. Nosotros seguimos un enfoque de defense in depth
      Auditamos todas las actions y, si hay dependencias mutables, las corregimos o las reemplazamos (soy de Astral)
    • La seguridad siempre implica trade-offs
      Gestionar todo el stack por cuenta propia es lo más seguro, pero no es realista
      Fijar hashes es una mejora de seguridad que casi sale gratis
      Al final, lo importante es tener claro hasta dónde decides confiar
    • De todos modos, cuando usas actions de terceros, tienes que leer y verificar el código tú mismo. Hacer simplemente un fork no resuelve nada

  • Viendo los incidentes recientes de Trivy y litellm, de verdad hace falta una guía de seguridad para procesos de release
    Los consejos de este artículo son prácticos y se pueden aplicar de inmediato
    La clave de la seguridad de la cadena de suministro depende de qué tan seguras sean las configuraciones predeterminadas de las plataformas de las que dependemos

  • Es un excelente panorama general. Creo que también podría servir como material de referencia para otros proyectos open source

  • Mantengo repomatic, una herramienta CLI de Python y de workflows reutilizables
    Incluye por defecto la mayoría de las prácticas de seguridad de este artículo
    El objetivo es crear un entorno donde la seguridad sea el valor predeterminado
    Después de leer el artículo, añadí una verificación de la política de aprobación de PRs de forks
    Más detalles en el repositorio de GitHub