PyPI Trusted Publishing, 초록 체크로 믿으면 안 되는 이유

PyPI Trusted Publishing, 초록 체크로 믿으면 안 되는 이유

AI 뉴스 썸네일

오픈소스 패키지를 고를 때 초록색 체크나 “Trusted”라는 단어가 보이면 안전하다고 느끼기 쉬워요. 이번 글의 핵심은 그 반대에 가까워요. PyPI의 Trusted Publishing은 패키지를 믿어도 된다는 표시가 아니라, CI/CD가 패키지를 올릴 때 쓰는 인증 방식이에요. 1

핵심 요약

구분	핵심	왜 봐야 하나요
패키지 보안	Trusted Publishing은 업로드 인증 방식이에요	패키지 품질이나 악성코드 여부를 판단하는 신호가 아니에요
자격 증명 관리	장기 API 토큰 대신 짧고 좁은 권한의 게시 자격 증명을 써요	CI/CD에 오래 살아 있는 토큰을 넣는 위험을 줄일 수 있어요
오픈소스 생태계	PyPI 뒤로 npm, RubyGems, crates.io, NuGet도 비슷한 방식을 채택했어요	패키지 저장소 전반의 배포 방식이 바뀌고 있어요
사용자 판단	PyPI는 이 상태를 프로젝트 페이지의 큰 초록 체크로 보여주지 않아요	개발자가 “인증됨”을 “안전함”으로 잘못 읽는 일을 줄이려는 설계예요

1. Trusted Publishing은 패키지 평판 점수가 아니에요

Trusted Publishing이라는 이름만 보면 “이 패키지는 믿을 수 있어요”라는 뜻처럼 들려요. 원문 글은 이 해석이 틀렸다고 짚어요. 여기서 신뢰는 사람과 패키지 사이가 아니라, CI/CD 같은 머신 신원과 패키지 저장소 사이의 인증 관계를 뜻해요. 예를 들어 GitHub Actions 워크플로가 자신이 어떤 저장소와 브랜치에서 실행됐는지 OIDC 토큰으로 증명하면, PyPI가 그 신원을 확인하고 업로드용 자격 증명을 짧게 발급하는 구조예요. 2

이 방식이 필요한 이유는 분명해요. 예전 방식에서는 프로젝트가 PyPI API 토큰을 만들고 CI/CD 비밀값에 넣는 일이 흔했어요. 토큰이 오래 살고 권한 범위가 넓으면 유출 피해도 커져요. Trusted Publishing은 토큰을 미리 들고 있는 대신, 배포 순간에 필요한 권한만 짧게 받는 쪽으로 바꿔요. 장기 토큰 보관 문제를 줄이는 인증 개선이지, 패키지 자체가 안전하다는 보증은 아니에요. 3

중요한 차이는 여기서 나와요. 누구나 공개 저장소에 패키지를 올릴 수 있고, 누구나 자신이 제어하는 CI/CD 신원을 Trusted Publisher로 등록할 수 있어요. 악성 패키지도 그 절차를 써서 올라갈 수 있어요. 그래서 Trusted Publishing을 썼다는 사실만으로 “코드가 깨끗해요”, “유지보수가 좋아요”, “설치해도 안전해요”라고 읽으면 안 돼요.

728x90

PyPI가 초록 체크를 아끼는 데에는 이유가 있어요

원문은 PyPI의 UI 선택을 좋게 봐요. PyPI는 프로젝트 페이지에 Trusted Publishing 상태를 크게 강조하지 않아요. 파일 상세 화면에서 Yes/No 메타데이터로 볼 수 있을 뿐이에요. 반대로 프로젝트 링크처럼 PyPI가 “이 URL은 패키지 소유자가 제어하던 곳이에요”라고 확인한 항목에는 초록 체크를 붙여요. 이 체크도 URL 소유권 확인을 뜻할 뿐, 프로젝트 안전성을 뜻하지 않는다고 문서가 선을 그어요. 4

이런 차이는 사소해 보여도 중요해요. 보안 UI에서 초록색 표식은 사용자가 거의 자동으로 “괜찮음”이라고 읽는 신호예요. Trusted Publishing은 업로드 경로의 인증 정보를 말해줄 뿐이므로, PyPI가 이를 큰 배지처럼 만들면 오해가 커질 수 있어요.

Attestation도 같은 방식으로 조심해서 읽어야 해요

PyPI attestations도 비슷한 주의가 필요해요. Attestation은 패키지 파일이 어떤 빌드·게시 흐름에서 나왔는지 서명된 정보로 남기는 장치예요. 하지만 “서명이 있다”라는 말은 “그 서명자를 신뢰해도 된다”와 달라요. 공개 저장소에서는 누구나 자신이 제어하는 머신 신원으로 서명할 수 있어요. PyPI 문서도 attestation의 신뢰 모델에서 이 부분을 따로 설명해요. 5

따라서 개발자가 봐야 할 질문은 “Trusted Publishing이 켜져 있나요?” 하나가 아니에요. 누가 어떤 저장소에서 패키지를 만들었는지, 배포 워크플로가 보호돼 있는지, 릴리스 이력이 자연스러운지, 의존성 변경이 과하지 않은지까지 같이 봐야 해요. Trusted Publishing은 그중 업로드 인증 쪽 정보를 보태는 도구예요.

왜 중요한가요

오픈소스 공급망 보안은 요즘 개발팀의 실제 운영 문제가 됐어요. 작은 패키지 하나가 빌드 파이프라인 전체로 들어오고, CI/CD 토큰 하나가 유출되면 새 버전 배포 권한까지 흔들릴 수 있어요. Trusted Publishing은 이 위험을 줄이는 좋은 방향이에요. 장기 토큰을 덜 만들고, 게시 권한을 개인 메인테이너보다 소스 신원에 가깝게 묶을 수 있기 때문이에요. 2

다만 개발자가 이 신호를 패키지 평판처럼 쓰면 문제가 생겨요. “Trusted”라는 단어는 강하지만, 실제 의미는 좁아요. 패키지 선택에는 여전히 코드 리뷰, maintainer 이력, 릴리스 패턴, 다운로드 급증 여부, 취약점 공지, lockfile 관리가 필요해요. Trusted Publishing은 이 목록을 대체하지 않아요.

기업 보안팀에도 읽을 지점이 있어요. 정책 문서에서 “Trusted Publishing 사용 패키지는 허용”처럼 단순 규칙을 만들면 위험해요. 더 나은 기준은 내부 패키지 배포에 Trusted Publishing을 권장하되, 외부 패키지 평가는 별도 신뢰 기준으로 나누는 쪽이에요. 인증 경로의 안전성과 코드 사용의 안전성을 분리해서 봐야 해요.

참고 자료

1. PyPI의 Trusted Publishing을 패키지 신뢰 신호로 보면 안 됨 — GeekNews
2. You shouldn't trust Trusted Publishing — ENOSUCHBLOG
3. Trusted publishers — PyPI Docs
4. Project metadata, verified details — PyPI Docs
5. Attestation trustworthiness — PyPI Docs