Ruff·uv 만든 Astral이 공개한 오픈소스 보안 전략 전모
(astral.sh)Astral은 전 세계 수백만 개발자가 의존하는 도구(Ruff, uv, ty)를 만들고 있으며, 최근 Trivy와 LiteLLM 공급망 해킹 사건을 계기로 자신들의 보안 실천 방식을 공개했다. 대상 독자는 세 부류다: 사용자, 다른 오픈소스 메인테이너, CI/CD 시스템 개발자.
1. CI/CD 보안
GitHub Actions의 보안 기본값은 취약하며, Ultralytics·tj-actions·Nx 등의 침해 사고가 모두 pull_request_target 같은 위험한 트리거에서 비롯됐다. Astral의 대응 방식은 다음과 같다:
위험한 트리거 전면 금지
pull_request_target과 workflow_run 등 안전하게 사용하기 거의 불가능한 트리거를 조직 전체에서 금지한다. 대부분의 프로젝트가 이 트리거가 필요하다고 생각하지만, 실제로는 권한이 낮은 pull_request 트리거나 단순 워크플로우 로그로 충분한 경우가 대부분이다.
액션 커밋 해시 고정(Hash Pinning)
태그나 브랜치(변경 가능) 대신 특정 커밋 SHA에 고정하고, 해당 커밋이 실제 릴리즈 상태와 일치하는지 교차 검증하여 "임포스터 커밋"을 방지한다. zizmor와 GitHub 자체 정책을 함께 사용하며, 간접적으로 호출되는 중첩 액션까지 모두 해시 고정이 적용된다.
최소 권한 원칙
조직 레벨에서 기본 권한을 읽기 전용으로 설정하고, 모든 워크플로우는 permissions: {}로 시작해 잡 단위로만 필요한 권한을 추가한다. 비밀(Secret)도 조직·레포지터리 레벨 대신 배포 환경별로 격리하여 테스트 잡이 릴리즈 비밀에 접근하지 못하도록 한다.
2. 레포지터리 및 조직 보안
관리자·고권한 계정 수를 최소화하고, 대부분의 조직 멤버는 필요한 레포지터리에 대한 읽기·쓰기 권한만 갖는다. 2FA는 GitHub 기본값(어떤 방식이든)보다 강한 TOTP 이상을 요구하며, 향후 WebAuthn·패스키만 허용하는 방향으로 강화할 계획이다.
main 브랜치는 강제 푸시 불가·풀 리퀘스트 필수, 릴리즈 태그는 배포 성공 후에만 생성 가능하도록 보호 규칙을 적용한다. 특히 레포지터리 관리자도 이 규칙들을 우회할 수 없도록 조직 레벨에서 강제한다.
3. 자동화(GitHub App 활용)
서드파티 PR에 댓글을 남기는 것처럼 GitHub Actions에서 안전하게 할 수 없는 작업은 astral-sh-bot GitHub App으로 분리한다. 다만 GitHub App도 취약점이 없는 것은 아니며, 신뢰할 수 없는 코드 실행이 필요한 경우에는 반드시 pull_request 트리거를 사용해야 한다고 강조한다.
4. 릴리즈 보안
PyPI·crates.io·NPM에는 장기 자격증명 없이 배포할 수 있는 Trusted Publishing을 사용하고, 바이너리·Docker 이미지에는 Sigstore 기반 증명(attestation)을 첨부하여 릴리즈 아티팩트와 워크플로우 간의 암호학적 연결을 제공한다.
GitHub의 불변 릴리즈(immutable releases) 기능을 사용해 공개된 빌드의 사후 변조를 방지하고, 릴리즈 빌드 중 캐시 사용을 금지해 캐시 포이즈닝 공격을 차단한다.
릴리즈 프로세스 자체도 이중으로 보호된다: 릴리즈 환경 활성화에는 조직 내 다른 권한 있는 멤버 최소 1인의 수동 승인이 필요하다. 즉, 악의적인 릴리즈를 위해서는 강한 2FA를 갖춘 계정 두 개를 동시에 탈취해야 한다.
5. 의존성 보안
Dependabot·Renovate로 의존성 업데이트와 알려진 취약점 알림을 관리하되, 새 릴리즈 직후 즉시 업데이트하지 않는 "쿨다운(cooldown)" 정책을 함께 운용한다. 일시적으로 침해된 의존성의 영향을 최소화하기 위해서다. uv에는 이 기능이 내장되어 있다.
Python Packaging Authority(PyPA)·Python Security Response Team 등 인접 프로젝트·워킹그룹과 사회적 연결을 유지하여, pip에 보고된 이슈가 uv에도 영향을 미치는 경우처럼 정보를 공유한다. 새 의존성 추가는 보수적으로 접근하고, 바이너리 블롭을 포함하는 의존성을 피하며, 불필요한 기능은 비활성화한다.
의존하는 프로젝트의 지속 가능성을 위해 OSS Fund를 통한 재정적 기여도 이어가고 있다.
핵심 권고사항 요약
Astral이 강조하는 네 가지 핵심 원칙은 다음과 같다: CI/CD의 한계를 인식하고 안전하게 할 수 없는 작업은 과감히 포기하거나 GitHub App으로 분리할 것, 장기 자격증명은 가능하면 없애고 최소 범위로 격리할 것, 배포 환경·승인·불변 태그 등으로 릴리즈 프로세스를 강화할 것, 의존성 트리 전체의 건강 상태를 지속적으로 파악할 것.
시사점
PyPI·공급망 보안에 깊이 관여하는 입장에서 보면, 이 글은 단순 보안 가이드를 넘어 오픈소스 생태계 전체의 신뢰 구조를 어떻게 설계할 것인가에 대한 실전 사례다. 특히 Trusted Publishing·쿨다운 정책·이중 승인 릴리즈 프로세스는 규모 있는 오픈소스 프로젝트라면 참고할 만하다.