Astral의 오픈소스 보안 전략

• 전 세계 개발자들이 사용하는 Ruff, uv, ty 등의 도구를 개발하는 Astral은 모든 제품의 보안성과 신뢰성을 핵심 가치로 유지함
• 최근 공급망 공격 증가에 대응해, 빌드·배포·릴리스 전 과정의 보안 강화를 위한 내부 기법을 공개함
• GitHub Actions 기반 CI/CD에서 해시 고정, 최소 권한, 비밀정보 분리 등 다층적 보호 체계를 적용함
• 릴리스 단계에서는 Trusted Publishing, Sigstore attestations, Immutable Releases 등으로 배포 무결성을 확보함
• Astral은 이러한 접근을 통해 오픈소스 생태계 전반의 보안 수준 향상과 지속 가능한 방어 체계 구축을 목표로 함

Astral의 오픈소스 보안 접근

• Astral은 전 세계 수백만 개발자가 사용하는 Ruff, uv, ty 등의 도구를 개발하며, 이들 도구의 보안성과 신뢰성을 핵심 가치로 유지함
• 최근 Trivy와 LiteLLM 해킹 사례 등 공급망 공격이 증가함에 따라, Astral은 자사 도구와 빌드·배포 프로세스의 안전성을 보장하기 위한 내부 보안 기법을 공개함
• 사용자, 오픈소스 유지관리자, CI/CD 시스템 개발자 모두가 참고할 수 있는 보안 모범 사례를 공유함

CI/CD 보안

• Astral은 GitHub Actions 기반의 광범위한 CI/CD 워크플로우를 통해 개발과 배포를 자동화하며, 이를 보안의 핵심 구성요소로 활용함
  • 로컬 환경이 아닌 통제되고 관찰 가능한 환경에서 빌드와 테스트가 수행되도록 함
• GitHub Actions의 기본 보안 설정이 취약하다는 점을 인식하고 다음과 같은 강화 조치를 시행함
  • pull_request_target, workflow_run 등 위험한 트리거 전면 금지
  • 모든 액션을 특정 커밋 해시(SHA) 에 고정하고 impostor commit 여부를 교차 검증
  • zizmor의 unpinned-uses, impostor-commit 감사 도구와 GitHub 정책을 병행 적용
  • 해시 고정이 불가능한 간접 의존 액션까지 포함해 전체 의존 그래프를 해시 고정
• 해시 고정만으로는 충분하지 않기 때문에 수동 검토를 통해 불변성 결함을 탐지하고, 필요 시 상위 프로젝트와 협력해 수정
  • 예: 바이너리 다운로드 URL과 해시를 매핑해 불변 상태로 내장
• 워크플로우 권한은 기본 읽기 전용으로 제한하고, 각 작업(job) 단위로 필요한 최소 권한만 부여
• GitHub Secrets는 환경별로 분리된 배포 환경 변수로 관리해, 테스트·린트 작업이 릴리스 비밀정보에 접근하지 못하도록 함
• 보조 도구로 zizmor(정적 분석)과 pinact(자동 해시 고정)을 사용

저장소 및 조직 보안

• Astral 조직 내 관리자 권한 계정 수를 최소화하고, 대부분의 구성원은 필요한 저장소에만 읽기·쓰기 권한을 가짐
• 모든 구성원에게 강력한 2단계 인증(2FA) 을 요구하며, 최소 TOTP 수준 이상의 인증 방식을 사용
  • GitHub이 피싱 저항형(WebAuthn, Passkeys)만 허용할 경우 즉시 전환 예정
• 브랜치 보호 규칙을 조직 전체에 적용
  • main 브랜치는 강제 푸시 불가, 모든 변경은 PR을 통해서만 가능
  • advisory-*, internal-* 등 특정 브랜치 패턴 생성 금지
• 태그 보호 규칙을 통해 릴리스 배포 성공 후에만 태그 생성 가능
  • 태그 수정·삭제 금지, main 브랜치에서만 릴리스 가능
• 저장소 관리자도 보호 규칙을 우회할 수 없음, 모든 보호는 조직 수준에서 강제됨
• Astral은 이러한 규칙 세트를 gist로 공개해 타 프로젝트가 참고 가능

자동화

• GitHub Actions로는 제3자 PR에 댓글 남기기 등 일부 작업을 안전하게 수행할 수 없음
• Astral은 이를 위해 astral-sh-bot GitHub App을 사용해 Actions 외부에서 이벤트를 안전하게 처리
  • GitHub App은 동일한 이벤트 데이터를 수신하지만 코드와 데이터가 분리된 환경에서 실행됨
• 단, App도 민감한 자격증명을 제거하지 않음
  • SQLi, 프롬프트 인젝션 등 취약점이 존재할 수 있으므로 일반 소프트웨어와 동일한 보안 수준으로 개발 필요
  • App 사용이 곧 비신뢰 코드 실행의 안전성 보장을 의미하지 않음
• GitHub App 방식은 보안상 유리하지만 복잡성 증가
  • App 개발·호스팅이 필요하며, 개인 개발자나 소규모 프로젝트에는 부담
  • Python용 Gidgethub 프레임워크가 개발을 단순화
• Astral은 astral-sh-bot을 오픈소스로 공개할 계획이며, Mariatta의 튜토리얼을 참고 자료로 추천

릴리스 보안

• Astral 도구는 GitHub 외에도 PyPI, Homebrew, Docker 이미지 등 다양한 채널로 배포됨
• 공급망 공격 방지를 위해 다음과 같은 조치를 시행
  • Trusted Publishing을 사용해 레지스트리 자격증명 제거

  • Sigstore 기반 attestations을 생성해 빌드 산출물과 워크플로우 간의암호학적 연계성 보장

    • GitHub의 Immutable Releases 기능으로 게시 후 수정 방지
    • 빌드 캐시 미사용으로 캐시 오염 공격 차단
    • 릴리스 과정은 전용 배포 환경(deployment environment) 에서 격리
    • 릴리스 환경 활성화 시 다른 팀원의 승인 필요, 단일 계정 탈취로 인한 악성 릴리스 방지
    • release-gate 환경과 GitHub App 기반 승인 중계로 다단계 승인 유지
    • 태그는 릴리스 성공 후에만 생성 가능
    • 독립 설치 프로그램(standalone installer) 은 내장된 체크섬으로 바이너리 무결성 검증
    • 릴리스 후 문서, 버전 매니페스트, pre-commit 훅 업데이트 등은 전용 봇 계정과 세분화된 PAT으로 수행
    • 향후 macOS·Windows용 코드 서명 추가 예정

의존성 보안

• Astral은 Dependabot과 Renovate를 사용해 의존성 업데이트 및 취약점 알림을 관리
• 쿨다운(cooldown) 기간을 두어 새 릴리스 직후 업데이트를 지연, 일시적 공급망 공격 위험 완화
  • Renovate는 그룹별 쿨다운 설정을 지원, 자체 의존성에는 완화 적용
• 주요 상위 프로젝트와 지속적인 협력 및 보안 기여 수행
  • 예: apache/opendal-reqsign CI/CD 보안 강화 기여
• Python Packaging Authority, Python Security Response Team 등과 협력해 보안 정보 공유
• 새 의존성 추가를 신중히 검토, 불필요한 의존성 제거 추진
  • 특히 이진 블롭 포함 의존성 회피, 불필요 기능 비활성화
• OSS Fund를 통해 핵심 오픈소스 프로젝트에 재정 지원

결론 및 핵심 교훈

• 오픈소스 보안은 기술적·사회적 문제의 복합체이며 지속적 대응이 필요
• Astral이 강조하는 주요 원칙
  • CI/CD의 한계를 인식하고, 불가피한 경우 GitHub App 등 외부 격리 방식 사용
  • 장기 자격증명 제거 및 최소화, Trusted Publishing과 OIDC 인증 활용
  • 릴리스 프로세스 강화, 승인·태그·브랜치 규칙 및 Immutable Release 적용
  • 의존성 인식 유지, 도구와 협력으로 상위 프로젝트의 보안도 함께 강화
• Astral은 이러한 기법들을 지속적으로 평가·보완하며, 공격자 행태 변화에 맞춰 방어 체계 진화 예정

각주 요약

• PyPI의 PEP 740은 attestations 업로드를 허용하지만, 현재 Astral의 Trusted Publishing 구현과 호환되지 않아 적용 대기 중
• 설치 스크립트 내 체크섬은 curl ... | bash 직접 실행 시 효과가 제한되지만, CI/CD 내 벤더링 시 유용