# Ruff·uv 만든 Astral이 공개한 오픈소스 보안 전략 전모 > Clean Markdown view of GeekNews topic #28340. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28340](https://news.hada.io/topic?id=28340) - GeekNews Markdown: [https://news.hada.io/topic/28340.md](https://news.hada.io/topic/28340.md) - Type: news - Author: [darjeeling](https://news.hada.io/@darjeeling) - Published: 2026-04-09T14:02:43+09:00 - Updated: 2026-04-09T14:02:43+09:00 - Original source: [astral.sh](https://astral.sh/blog/open-source-security-at-astral) - Points: 26 - Comments: 0 ## Summary **Ruff**와 **uv**를 만든 **Astral**이 자사의 오픈소스 보안 전략을 전면 공개한 글입니다. Trivy/LiteLLM 공급망 해킹 사건을 계기로, GitHub Actions의 위험한 트리거 금지, 액션 커밋 해시 고정, 최소 권한 원칙 같은 실천 방식을 구체적으로 설명합니다. 수백만 개발자가 의존하는 도구를 만드는 팀이 **어떤 수준으로 CI/CD와 릴리즈 파이프라인을 잠그고 있는지** 보여주는 글이라, 오픈소스를 운영하거나 공급망 보안이 신경 쓰이는 분에게 좋은 체크리스트입니다. ## Topic Body 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·쿨다운 정책·이중 승인 릴리즈 프로세스는 규모 있는 오픈소스 프로젝트라면 참고할 만하다. --- *원문: [Astral Blog, 2026.04.08](https://astral.sh/blog/open-source-security-at-astral)* ## Comments _No public comments on this page._