Trusted Publishing을 패키지 신뢰 신호로 보면 안 되는 이유 — PyPI OIDC가 푸는 문제와 남기는 함정

들어가며: “Trusted”라는 단어가 오해를 부른다

2026년 7월 긱뉴스에 올라온 블로거 yossarian.net의 글이 패키지 생태계에서 굉장히 중요한 포인트를 짚었다. 핵심은 이렇다 — Trusted Publishing의 “신뢰”는 패키지를 사람이 믿어도 된다는 뜻이 아니라, CI/CD 같은 외부 머신 신원과 패키지 인덱스 사이의 업로드 인증 관계를 가리킨다. 즉 우리가 흔히 “이 패키지를 신뢰할 수 있느냐?”라고 물을 때 떠올리는 “이 라이브러리가 안전한가?”와는 다른 차원의 이야기다.

이걸 오해하면 인프라 운영자도, 오픈소스 사용자도, 심지어 보안 담당자도 잘못된 결론에 도달할 수 있다. 오늘은 긱뉴스 본문을 바탕으로 Trusted Publishing이 정확히 무엇을 보장하고 무엇을 보장하지 않는지, 그리고 어떤 함정이 남아 있는지를 정리한다.

Trusted Publishing은 “머신 간 신뢰”다

블로그 원문은 Trusted Publishing을 사람의 신뢰가 아니라 머신 신원(machine identity) 간의 인증 메커니즘이라고 정의한다. PyPI가 2023년에 이 기능을 공개했을 때 의도한 것도 정확히 이것이었다. 기존에는 패키지를 인덱스에 게시하기 위해 장기 API 토큰을 발급받아야 했다. 이 토큰은:

• 만료 기간이 길고
• 과권한으로 발급되기 쉬우며
• CI/CD 같은 외부 시스템에 들어가면 유출 위험이 크다

Trusted Publishing은 이 문제를 OIDC(OpenID Connect) 연합 위에서 해결한다. 흐름은 다음과 같다.

1. 패키지 인덱스(PyPI 등)에 CI/CD 머신 신원인 Trusted Publisher를 한 번 등록한다.
2. CI/CD 워크플로가 OIDC ID 토큰을 제시하면, 인덱스가 이를 검증한다.
3. 검증이 통과되면 짧고 범위가 좁은 게시 자격 증명을 발급한다.

핵심은 장기 토큰을 외부 시스템에 보관할 필요가 없어진다는 점이다. PyPI 입장에서 “신뢰”하는 것은 GitHub Actions나 GitLab CI 같은 특정 워크플로의 신원이지, 패키지 자체의 품질이 아니다.

PyPI의 설계: “초록 체크”를 일부러 안 보여준다

블로그에서 특히 인상적인 부분은 PyPI가 의도적으로 안전성 신호처럼 보이지 않게 만들었다는 점이다. 패키지 페이지에 초록 체크 표시 같은 시각적 강조를 하지 않고, 파일 상세의 단순 Yes/No 메타데이터로만 Trusted Publishing 여부를 노출한다.

이건 의도된 설계 선택이다. Trusted Publishing이 활성화되어 있다고 해서 “이 패키지는 안전하다”는 의미가 아니기 때문이다. 오히려 사용자가 이 둘을 혼동하지 못하게 신중하게 UI를 제한한 셈이다. 이 접근은 npm, RubyGems, crates.io, NuGet 등 다른 패키지 인덱스도 모방했다 — 모두 같은 데이터 모델과 OIDC 연합 위에서 Trusted Publishing을 구현했다.

남은 제약: 데이터 모델 복잡성, OIDC 제공자별 처리, CI/CD 침해

물론 Trusted Publishing이 만능은 아니다. 블로그에서 짚은 구조적 복잡성은 세 가지다.

• 첫째, 데이터 모델 복잡성*이다. PyPI의 “pending publishers”는 존재하지 않는 프로젝트 문제를 해결하지만, 일반 Trusted Publishing보다 사용자에게 혼란스러울 수 있다. 패키지를 처음 만들 때 Trusted Publisher를 등록하려고 해도 프로젝트가 아직 인덱스에 없으면 등록 자체가 막히는데, 이를 우회하기 위한 “pending” 상태가 모델을 복잡하게 만든다.

• 둘째, OIDC 제공자별 처리가 다르다*. 공통 claim 일부를 제외하면 각 IdP는 자기만의 claim set을 자유롭게 정의할 수 있다. 그래서 인덱스는 각 제공자의 고유한 형태를 별도로 처리해야 하고, 머신 신원은 OIDC IdP 간에 서로 대체 가능하지 않다. 이 때문에 PyPI가 새 Trusted Publishing 제공자를 천천히 추가하는 것이다 — 통합 비용이 만만치 않다.

• 셋째, CI/CD 침해 가능성이다. 워크플로가 침해되면 공격자가 Trusted Publishing 자격 증명이나 그 씨앗이 되는 OIDC ID 토큰을 유출할 수 있다. 다만 PyPI는 pull_request_target처럼 쉽게 악용될 수 있는 트리거에는 토큰 교환을 거부해 위험을 완화한다. 이건 일종의 신원 자체에 대한 화이트리스트*라고 보면 된다.

그럼에도 Trusted Publishing이 “잘한” 이유

블로그는 이 모든 제약을 나열하면서도 Trusted Publishing이 “큰 성공을 거둔 접근”이었다고 평가한다. 이유는 명확하다.

• 장기 자격 증명을 직접 관리하지 않아도 된다 — 만료, 회전, 유출 감시 같은 운영 부담이 사라진다.
• 소스 신원에 게시 권한이 연결된다 — 메인테이너 개인의 계정이 아니라 워크플로의 신원에 권한이 묶이므로, 메인테이너가 바뀌어도 게시 흐름이 유지된다.
• 과거 방식보다 본질적으로 안전하다 — 비록 완벽하지는 않지만, “API 토큰을 GitHub Secrets에 5년째 넣어두는” 패턴보다는 분명히 우월하다.

특히 “소스 신원에 권한이 연결된다”는 속성은 멀티 메인테이너 오픈소스 프로젝트에서 큰 의미가 있다. 개인이 아니라 저장소 자체가 신뢰 단위이기 때문에, 조직 변화나 인원 교체가 일어나도 게시 흐름이 깨지지 않는다.

그럼에도 남는 질문

블로그 글 말미에 “그럼에도 패키지 자체의 안전성은 누가 보장하나?”라는 질문이 남는다. 이건 Trusted Publishing이 답하지 못하는 영역이다. 패키지 인덱스 입장에서는 업로드 신원이 신뢰할 만한지 검증할 수 있을 뿐, 그 패키지의 코드가 안전한지, 메인테이너가 신뢰할 만한 사람인지, 의존성 그래프가 안전한지 등은 별개의 문제다. attestations, SBOM, 서명 검증 같은 다른 메커니즘들이 이 영역을 담당한다.

또한 블로거가 스스로 던진 질문도 흥미롭다 — 자체 호스팅 Forgejo에서 Trusted Publishing을 못 할 이유가 있냐고. 사실 Forgejo Actions도 OIDC ID 토큰을 발급할 수 있고, PyPI가 Forgejo를 Trusted Publisher로 받기만 하면 된다. 다만 앞서 말한 “OIDC 제공자별 처리” 비용 때문에 PyPI가 즉각적으로 Forgejo를 추가하지는 않을 가능성이 높다.

마무리: “Trusted Publishing = 패키지 안전”은 거짓 등식

Trusted Publishing은 머신 신원 간의 업로드 인증 메커니즘이지, 패키지 자체의 품질이나 안전성을 보증하는 신호가 아니다. 이 둘을 분리해서 이해하지 않으면 보안 의사결정이 잘못된 방향으로 갈 수 있다.

운영자 관점에서는:

• 장기 API 토큰을 CI/CD 시크릿에 넣는 패턴을 가능하면 빨리 Trusted Publishing으로 옮기는 게 맞다.
• 다만 Trusted Publishing이 활성화되어 있다고 해서 패키지 품질을 단정짓는 건 위험하다.

사용자 관점에서는:

• “이 패키지가 Trusted Publishing을 쓴다”는 사실을 CI/CD 신원만 검증했다는 신호로 받아들이고,
• “이 패키지의 코드가 안전한가”는 별도의 검증(attestations, SBOM, 의존성 감사 등)으로 따져야 한다.

블로그 원문이 던지는 핵심 질문은 결국 이것이다 — “우리는 지금 무엇을 신뢰하고 있는가?” Trusted Publishing은 이 질문에 절반의 답만 줄 수 있다. 나머지 절반은 우리가 직접 채워야 한다.

---

📰 원본 출처 · https://news.hada.io/topic?id=31238 (#N=31238)

이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.