- Trusted Publishing의 신뢰는 사람이 아닌 CI/CD 머신 신원과 인덱스 사이의 업로드 인증 관계를 뜻한다.
- PyPI가 2023년 도입했고 npm, RubyGems, crates.io, NuGet으로 확산되며 OIDC 단기 자격 증명으로 과권한 토큰 노출을 줄인다.
- 분산된 데이터 모델, OIDC 제공자별 차이, CI/CD 침해 가능성은 남아 있고 PyPI는 Trusted Publishing 상태를 시각적으로 노출하지 않는다.
Trusted Publishing은 안전 배지가 아니라 업로드 인증 방식이라는 시각이 공급망 보안 논의를 정확하게 분리한다는 점에서 의미가 있다.
Trusted Publishing이 약속하는 것과 약속하지 않는 것
최근 패키지 생태계에서 Trusted Publishing이라는 용어가 마치 품질 보증 라벨처럼 쓰이는 경우가 있다. 그러나 원문은 이 용어가 사람 사이의 신뢰가 아니라 CI(Continuous Integration)/CD(Continuous Deployment) 같은 외부 머신 신원과 패키지 인덱스 사이의 업로드 인증을 의미한다고 못박는다. 즉 신뢰의 대상은 패키지를 배포한 개발자가 아니라 워크플로를 돌리는 빌드 시스템이며, 이 차이를 흐리면 위험 평가 자체가 빗나가게 된다.
사람의 신뢰와 머신 신원의 신뢰는 다르다
전통적인 API 토큰 모델에서는 비밀값을 장기간 보유한 인력이 발행 주체가 되었다. Trusted Publishing은 이 인력을 워크플로 단위로 대체해 짧고 범위가 좁은 OIDC(OpenID Connect) 기반 자격 증명을 발급한다. 이는 사람 신뢰가 사라지는 것이 아니라 신뢰 주체가 옮겨간 것으로 이해해야 한다.
Trusted Publishing 활성화 시 권장될 환경 변수와 시크릿 제거
운영자 입장에서는 PyPI 공식 문서를 따라 트러스트드 퍼블리셔를 등록한 뒤 저장소 시크릿에서 장기 API 토큰을 삭제해야 한다. 토큰이 남아 있으면 OIDC 경로와 동시에 우회 경로가 생겨 공격 표면이 두 배가 되므로, 마이그레이션 직후 회수 절차까지 묶어서 점검하는 편이 안전하다.
OIDC 연합 위에서 동작하는 발행 파이프라인
Trusted Publishing의 기술적 토대는 OIDC(OpenID Connect) 연합이다. GitHub Actions, GitLab CI 등 각 제공자가 발급한 단기 토큰을 패키지 인덱스가 검증해 사전 등록된 신뢰 관계와 매칭한다. 이 모델 덕분에 만료가 짧은 자격 증명이 사용되고,泄露된 비밀값이 사후 공격에 그대로 쓰일 가능성을 줄일 수 있다.
감사 로그와 환경 격리 전략
다만 OIDC 토큰은 만료가 짧다는 점에서 누설 위험이 낮아 보이지만, 워크플로가 실행되는 러너 환경 자체는 여전히 침해 표면으로 남는다. 캐시, 임시 파일, 환경 변수까지 망라한 격리와 빌드 단계별 감사 로그 확보가 권장되며, 이는 OIDC 도입 전후로 본질적으로 달라지지 않는 과제로 남아 있다.
여전히 남은 위험: OIDC 제공자 차이, 데이터 모델 복잡성, CI/CD 침해
원문은 OIDC 제공자별 구현 차이, 분산된 데이터 모델, CI/CD 침해 가능성을 Trusted Publishing이 해결하지 못하는 구조적 위험으로 제시한다. PyPI, npm, RubyGems, crates.io, NuGet이 같은 이름 아래 OIDC를 도입했더라도 발급 정책과 보존 기간은 제각각이므로 인덱스별 가이드를 분리해 관리해야 한다는 것이 필자의 주장이다.
분산된 데이터 모델과 인덱스별 구현 차이
예컨대 같은 트러스트드 퍼블리셔 설정이라도 프로젝트 키와 발급자 subject의 매핑 방식이 인덱스마다 미세하게 다르다. 따라서 한 곳에서 검증된 설정이 다른 인덱스에서 그대로 통하지 않을 수 있으며, 멀티 레지스트리 운영에서는 인덱스별 모델 차이를 표로 정리해 두는 편이 효율적이다.
| 인덱스 | 도입 시기 | 자격 증명 형태 | 운영 시 주의점 |
|---|---|---|---|
| PyPI | 2023년 도입 | OIDC 단기 토큰 | 프로젝트 페이지에 시각적 배지 없음, 시크릿 잔존 점검 필요 |
| npm | 이후 확산 | OIDC 기반 게시 자격 증명 | 인덱스별 발급자 매핑 확인 |
| RubyGems | 이후 확산 | OIDC 단기 자격 증명 | 레거시 토큰 회수 절차 필요 |
| crates.io | 이후 확산 | OIDC 단기 자격 증명 | 워크플로 권한 최소화 권장 |
| NuGet | 이후 확산 | OIDC 단기 자격 증명 | 서명 정책과의 충돌 여부 점검 |
운영자 입장에서의 자가 점검 체크리스트
Trusted Publishing은 도구이고 정책은 운영자가 짜야 한다. 다음 점검은 원문과 공식 문서를 결합한 최소 자가 진단 항목으로 정리된다.
- 프로젝트 페이지의 게시자가 사전 등록한 OIDC 제공자와 정확히 일치하는지 확인한다.
- 장기 API 토큰이 저장소 시크릿에 남아 있지 않은지 CI 설정과 저장소 시크릿을 함께 점검한다.
- 워크플로가 pull_request 같은 비신뢰 트리거에서 publish를 호출하지 못하게 권한을 최소화한다.
- OIDC 토큰의 aud, iss, sub 클레임을 인덱스 정책에 맞게 명시적으로 제한한다.
- 장애 대응 매뉴얼에 “토큰 회수 → 트러스트드 퍼블리셔 재등록” 단계를 포함한다.
프로젝트 페이지에 표시되지 않는 보안 신호
원문은 PyPI가 프로젝트 페이지에서 Trusted Publishing 상태를 초록 체크 표시 같은 시각적 배지로 강조하지 않는다는 점을 관찰한다. 이는 사용자에게 안심 신호를 주지 않으려는 정책적 선택으로도 읽히고, 동시에 운영자가 스스로 검증해야 하는 부담을 의미하기도 한다. 결과적으로 신뢰 신호는 사용자 인터페이스가 아니라 발행 로그와 메타데이터에서 확인해야 한다는 해석이 가능하다.
정리하면
- Trusted Publishing은 안전 배지가 아니라 업로드 인증 약식이라는 정의를 먼저 고정해야 한다.
- OIDC 단기 자격 증명은 과권한 토큰 노출을 줄이지만 워크플로 침해와 제공자 차이라는 잔여 위험은 남는다.
- 운영자는 토큰 회수, 권한 최소화, 클레임 제한, 장애 대응까지 자가 점검 체크리스트로 묶어야 한다.