Trusted Publishing을 패키지 신뢰 신호로 보면 안 됨

• Trusted Publishing의 “신뢰”는 패키지를 사람이 믿어도 된다는 뜻이 아니라, CI/CD 같은 외부 머신 신원과 패키지 인덱스 사이의 업로드 인증 관계를 가리킴
• PyPI의 구현은 OIDC 연합 위에서 동작하며, 장기 API 토큰 대신 짧고 범위가 좁은 게시 자격 증명을 발급해 장기·과권한 자격 증명 노출을 줄임
• PyPI가 2023년에 공개한 뒤 npm, RubyGems, crates.io, NuGet 등으로 확산됐지만, 데이터 모델 복잡성, OIDC 제공자별 처리, CI/CD 침해 가능성은 남아 있음
• PyPI는 Trusted Publishing 상태를 프로젝트 페이지의 초록 체크 표시로 강조하지 않고, 파일 상세의 단순 Yes/No 메타데이터로만 보여 안전성 신호로 오해될 여지를 줄임
• Trusted Publishing과 PyPI attestations는 업로드 인증이나 머신 신원 기반 서명 여부만 말해주며, 별도로 그 신원을 신뢰하기 전에는 패키지 안전성이나 품질을 판단할 수 없음

Trusted Publishing이 다루는 신뢰의 범위

• Trusted Publishing은 사람에게 패키지를 신뢰하라고 말하는 기능이 아니라, 머신 간 신뢰를 다루는 인증 방식임
• Trusted Publishing을 사람이 믿을 수 있느냐 없느냐의 문제로 보면 범주가 어긋남
• 핵심은 CI/CD 워크플로 같은 외부 머신 신원과 패키지 인덱스의 프로젝트 신원 사이에 업로드 인증용 신뢰 관계를 세우는 데 있음

PyPI의 Trusted Publishing 구조

• “Trusted Publishing”은 PyPI가 OpenID Connect 연합 위의 인증 방식을 설명할 때 쓰는 용어임
• PyPI는 이를 2023년에 공개했고, 이후 npm, RubyGems, crates.io, NuGet 등도 채택함
• 출발점은 두 가지 문제임
  • 장기 자격 증명인 인덱스 API 토큰은 안전하게 관리하기 어렵고, 사용자가 최소 권한과 만료 기간을 정하기 어려워 과권한으로 설정되기 쉬움
  • 많은 사용자는 CI/CD 플랫폼에 넣기 위해 자격 증명을 만들며, CI/CD 플랫폼도 OIDC를 통해 특정 머신 신원 제어를 증명하는 메커니즘을 갖고 있음
• 사용자는 패키지 인덱스에 CI/CD 머신 신원인 Trusted Publisher를 한 번 등록하고, CI/CD가 신원 토큰을 제시하면 인덱스가 이를 검증해 짧고 범위가 좁은 게시 자격 증명을 발급함

장점과 남는 제약

• 짧고 자체 범위가 정해지는 자격 증명 방식은 PyPI 사용자에게 큰 성공을 거둔 접근으로 평가됨
  • 사용자는 필요 없을 때 자격 증명을 직접 관리하지 않는 방식을 선호함
  • 대형 오픈소스 프로젝트와 기업은 게시 권한이 개인 메인테이너가 아니라 소스 신원에 연결되는 속성을 선호함
• Trusted Publishing에도 구조적 복잡성은 남아 있음
  • PyPI의 “pending publishers”는 존재하지 않는 프로젝트 문제를 해결하지만, 데이터 모델을 복잡하게 만들고 일반 Trusted Publishing보다 사용자에게 더 혼란스러움
  • OIDC 제공자는 공통 claim 일부 외에 claim set에 다양한 값을 넣을 수 있어, 인덱스는 각 제공자의 고유한 형태를 별도로 처리해야 함
  • 이 때문에 머신 신원은 OIDC IdP 간에 서로 대체 가능하지 않으며, PyPI가 새 Trusted Publishing 제공자를 천천히 추가하는 이유 중 하나가 됨
• CI/CD 워크플로가 침해되면 공격자가 Trusted Publishing 자격 증명이나 그 씨앗이 되는 OIDC ID 토큰을 유출할 수 있음
  • 장기 자격 증명이 워크플로에 들어 있을 때와 유사하지만, Trusted Publishing 자격 증명은 같은 범위·수명 위험을 갖지 않음
  • PyPI는 pull_request_target처럼 쉽게 악용될 수 있는 트리거에 해당하는 머신 신원에는 토큰 교환을 거부해 CI/CD 침해 위험을 완화함

패키지 신뢰 신호가 아닌 이유

• Trusted Publishing은 인증 방법일 뿐이며, 패키지가 안전한지, 품질이 높은지, 사용할 만한지에 대한 정보를 주지 않음
• PyPI는 공개 인덱스라 누구나 업로드할 수 있고, 누구나 Trusted Publisher를 사용해 업로드할 수 있음
  • Trusted Publisher로도 악성코드나 취약한 코드를 업로드할 수 있음
  • 이 점에서는 PyPI의 다른 업로드 인증 방법인 API 토큰과 같음
• PyPI에서 Trusted Publishing은 필수가 아니며 앞으로도 필수가 될 수 없음
  • 사용자에게 Trusted Publishing을 강제하는 것은 엔지니어링상 실현 불가능하고, 기술적·사회적으로도 바람직하지 않음
  • Trusted Publishing은 항상 선택 사항임

PyPI UI가 오해를 줄이는 방식

• PyPI는 사용자가 Trusted Publishing 상태를 패키지 신뢰 신호로 오해하지 않도록 조심함
• 프로젝트 페이지에는 Trusted Publishing 상태를 나타내는 초록 체크 표시가 없음
• 사용자 제어 상태에 대한 초록 체크 표시는 패키지 자체와 같은 출처에서 왔음을 PyPI가 증명할 수 있는 링크에만 사용됨
• 검증된 URL은 검증 시점에 해당 URL이 PyPI 패키지 소유자의 제어 아래 있었다는 것만 증명하며, URL이나 프로젝트에 대한 추가 안전성을 뜻하지 않음
• 특정 파일의 Trusted Publishing 상태는 파일 상세에서 단순한 Yes/No 값으로 표시됨
  • 파일 메타데이터 영역은 사용자 신뢰 판단에 중요한 정보처럼 렌더링되지 않음
  • 업로드 클라이언트의 user agent에서 온 JSON blob도 제대로 렌더링하지 않음

attestations와의 구분

• 이 논점은 PyPI의 attestations와 별개임
• attestations도 현재 OIDC 머신 신원을 사용하지만, 신뢰 신호는 아님
• attestation은 머신 신원 위의 서명과 비슷하지만, PyPI에는 누구나 업로드할 수 있으므로 누구나 자신이 제어하는 머신 신원으로 서명할 수 있음
• Trusted Publisher가 있다고 해서 attestation이 반드시 존재하는 것은 아니며, attestation이 있다고 해서 최종 사용자가 특정 신원을 신뢰해도 된다는 뜻도 아님
• PyPI의 attestation 신뢰성 모델도 이 점을 문서화하고 있음