PEP 811 – Python 보안 대응 팀의 구성원 자격 및 책임 정의

Author:: Seth Michael Larson <seth at python.org>
Sponsor:: Gregory P. Smith <greg at krypto.org>
Discussions-To:: Discourse thread
Status:: Active
Type:: Process
Topic:: Governance
Created:: 22-Oct-2025
Post-History:: 06-Oct-2025, 28-Oct-2025
Resolution:: 04-Dec-2025

Table of Contents

초록
동기
근거
- 운영 위원회와 활동에 따른 구성원 자격 결정
- GitHub Security Advisories (GHSA) 사용
사양
거부된 아이디어
- 비활성 구성원을 더 적극적으로 정리해야 합니까?
Copyright

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain or CC0-1.0, whichever is more permissive 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

초록

이 PEP는 Python 보안 대응 팀(PSRT)의 구성원 자격 및 책임 정책을 공식화할 것을 제안합니다. PSRT는 security@python.org 메일링 리스트로 보안 취약점 공개를 처리하는 “높은 신뢰를 받는 Python 개발자들의 비공개 집단”입니다.

PSRT는 CPython 및 pip에 영향을 미치는 알려진 취약점이 공개되기 전에 이에 접근할 수 있습니다. 이 정보는 민감하며, 유출될 경우 공격자가 방어 담당자에게 수정 사항이 통지되고 업그레이드할 기회를 얻기 전에 악용 가능한 취약점에 접근할 수 있는 제로데이 공격을 통해 Python 사용자에게 피해를 줄 수 있습니다.

그러나 PSRT는 취약점을 해결하기 위해 특정 분야의 핵심 개발자에게 도움을 요청해야 하는 경우가 많습니다. 이 PEP는 새로운 “Coordinator” 역할을 포함하여 PSRT의 정의된 구성원 자격 및 의무를 제안하고, 취약점에 관해 PSRT, 제보자 및 핵심 개발자 간의 표준 보고, 추적 및 협업 방식으로 GitHub Security Advisories (GHSA)를 채택할 것을 제안합니다.

동기

공개 전 취약점 보고서에 대한 접근 제한

공개 전 취약점 보고서 정보는 민감하며, 취약점이 악용될 경우 Python 사용자는 상당한 피해를 입을 수 있습니다. 이러한 이유로 해당 취약점의 해결에 관여하는 사람에게만 정보 접근을 제한하는 것이 매우 중요합니다.

과거 패치 개발 협업 방식은 GitHub 사용자를 수동으로 비공개 python/psrt 저장소에 추가하는 것이었으며, 이 저장소는 python/cpython 저장소의 미러입니다. 이 방식에서는 특정 취약점에 대해 특정 협업자를 선별할 수 없었으므로 모든 협업자가 모든 보고서와 패치에 접근할 수 있었습니다.

이러한 수동 절차는 PSRT 외부의 핵심 개발자를 협업에 참여시키는 것을 어렵게 했으며, 이로 인해 패치 개발이 더 어려워질 수 있었습니다. 이러한 제한으로 인해 취약점 제보자 역시 패치에 협업할 수 없었습니다.

PSRT에 새로운 기여자 온보딩

대부분의 오픈 소스 기여와 달리 PSRT의 작업은 공개적으로 이루어지지 않습니다. 대신 공개되지 않은 취약점 보고서에 대한 접근을 제한하기 위해 대부분의 작업은 신뢰할 수 있는 그룹에 의해 비공개로 수행됩니다. 이 작업의 민감한 특성으로 인해 외부에서는 불투명하게 보이며, 신규 참여자가 작업을 시작하고 그룹의 기대 사항을 이해하기가 어렵습니다.

실제로 이는 PSRT에 합류하는 신규 구성원이 비교적 적다는 것을 의미했으며, 시간이 지나면서 보고서를 분류하고 핵심 팀과 함께 해결책을 개발하는 그룹의 역량에 부정적인 영향을 줄 수 있습니다.

취약점 보고서에 대한 정의된 소유권의 부재

현재 PSRT 보고서에는 인시던트나 보고서가 해결된 상태를 향해 계속 진행되도록 보장하는 명확한 “소유자”가 없습니다. 이는 메일링 리스트의 맥락에서 특히 문제가 되는데, 어떤 이슈에 이미 다른 사람이 대응하고 있는지 또는 해당 보고서에 대한 자신의 판단이 PSRT 내 다른 사람들의 판단과 같은지 알기 어렵기 때문입니다.

이상적으로는 이슈, 풀 리퀘스트 및 PEP와 마찬가지로, 한 명의 지정된 사람이 완화 작업을 완료까지 진행할 책임을 져야 합니다. 이를 통해 해당 담당자는 다른 사람의 영역을 침범한다는 두려움 없이 작업에 기여하고 결정을 내릴 수 있습니다.

취약점 공개 일정에 맞추기

취약점 보고 모범 사례에서는 사용자, 프로젝트 및 보고자의 요구 사항 간 균형을 맞추기 위해 최초 공개와 보고서가 공개되는 시점 사이에 recommend a 90 day timeline을 권장합니다. 많은 취약점 보고 기관은 이미 이 일정을 사용하며, 프로젝트가 자체적인 완화 조치를 만들지 않더라도 취약점을 공개적으로 공개합니다.

보고서가 중단되거나 잊히거나 해결책 없이 공개적으로 게시되는 것을 방지하기 위해, 이 PEP는 최초 공개부터 권고문 게시까지 90일을 기준으로 맞출 것을 권장합니다.

근거

운영 위원회와 활동에 따른 구성원 자격 결정

PSRT에는 누구를 PSRT에 가입시키거나 PSRT에서 제외할지 결정하는 메커니즘이 없습니다. 업무의 보안 민감성과 결합되어 누구를 가입시켜야 할지 결정하기 어려울 수 있지만, PSRT 회원 자격을 평가하는 책임을 맡는 시스템이 반드시 있어야 합니다.

이 PEP는 PSRT 회원 자격을 보안 취약점의 현역 조정자, 감독에 관여하는 회원(운영 위원회), 보안 릴리스에 관한 정보가 필요한 회원(릴리스 관리자)으로만 제한할 것을 제안합니다.

보고서가 분류 및 조정되도록 하여 프로젝트에 추가적인 이익 없이 추가적인 위험을 초래하는 일을 피하기 위해, 활동을 회원 자격의 기준으로 삼을 것을 권장합니다.

GitHub Security Advisories (GHSA) 사용

이 PEP는 관련 프로젝트에서 이미 사용 중인 서비스와 긴밀하게 통합되어 있다는 이유로, 취약점 보고서를 접수하는 시스템으로 GitHub Security Advisories를 채택할 것을 제안합니다.

CPython과 pip는 이미 소스 관리, 이슈, 풀 리퀘스트, 지속적 통합(CI), 그리고 릴리스 프로세스의 일부에 GitHub를 사용하고 있습니다. GHSA는 취약점 보고 및 관리 플랫폼에 바람직한 다음 기능을 지원합니다.

GitHub 팀과 계정을 프로젝트별 또는 전역이 아니라 보고서별로 “협력자”로 관리합니다.
GitHub 계정을 사용하여 PSRT 외부 협력자를 보고서별로 관리합니다.
수정 사항을 개발하기 위한 “Pull request”와 유사한 사용자 인터페이스입니다.
UI 내에서 각 보고서의 보고자, 조정자, 크레딧, 제출 시간, CVE ID 및 심각도를 추적합니다.
다른 서비스(CVE 등) 및 봇과 통합하기 위한 프로그래밍 방식의 API입니다.

그러나 GHSA에 없는 기능은 다음과 같습니다.

CI에서 취약점 수정 브랜치를 비공개로 실행하는 기능입니다.
GHSA 보고서의 댓글을 조회하고 작성하는 기능과 같은 여러 API 엔드포인트가 GHSA에 없습니다.

이러한 누락된 기능은 GitHub에 보고되었으며, GHSA 도입을 막는 기능은 없습니다. GHSA 기능에 완전한 API가 없는 문제를 우회하려면 일부 작업이 필요합니다.

사양

PSRT 회원 자격 정책

PSRT는 기존 PSRT 회원이 신규 회원의 지명을 PSRT에 상정하고, 기존 PSRT 회원들이 해당 지명에 대해 투표하는 방식으로 similar to core team nominations와 유사한 지명 절차를 진행합니다. 신규 회원은 핵심 개발자, 트리아저 또는 PSF 직원 중에서 선발될 것으로 예상합니다. 기존 PSRT 회원의 투표가 일주일 동안 진행되고 운영 위원회가 거부권을 행사하지 않은 상태에서, 3분의 2 이상이 찬성하면 회원 자격이 부여됩니다.

PSRT 회원 목록은 공개적으로 게시하며 PSRT 관리자가 최신 상태로 유지합니다.

운영 위원회는 매년 한 차례 비활성 PSRT 회원에 관한 보고서를 받고, 비활성 사용자를 PSRT에서 제외할 것을 권고받습니다. 여기서 “비활성”은 마지막 보고서가 생성된 이후 지난 1년 동안 취약점 보고서를 조정하거나 이에 댓글을 작성하지 않은 회원을 의미합니다. 운영 위원회는 단순 과반수 투표로 PSRT 회원을 제외할 수 있습니다.

릴리스 관리자이거나 운영 위원회 회원인 PSRT 회원은 취약점 보고서 활동이 없어도 PSRT에 남을 수 있습니다.

이 PEP는 이 PEP가 발표되기 전에 지난 1년 동안 활동하지 않았으며 최소 활동량 면제 대상(운영 위원회, 릴리스 관리자)도 아닌 모든 회원을 PSRT에서 제외할 것을 제안합니다. 이 문서를 작성하는 시점에는 PSRT 회원 수가 약 30명에서 약 15명으로 줄어듭니다.

PSRT 관리자

운영 위원회가 결정한 바에 따라 최소 두 명의 PSRT 회원이 관리자로 활동해야 합니다. 이 PEP는 기존 PSRT 관리자 구성을 유지할 것을 제안합니다:

Ned Deily <nad@python.org>
Ee Durbin <ee@python.org>
Seth Larson <seth@python.org>
Barry Warsaw <barry@python.org>

관리자는 PSRT 메일링 리스트(security@python.org로 전송되는 보고 포함)의 멤버십 관리 및 보고서 분류라는 추가 책임을 집니다.

PSRT 멤버의 책임

PSRT 멤버의 책임은 Python Developer’s Guide에 공개적으로 문서화되므로, 가입을 신청하기 전에 예비 멤버가 PSRT에 가입할 경우 무엇을 기대해야 하는지 알 수 있습니다. 이러한 책임에는 다음이 포함됩니다.

CVE ID, 패치, 조정 공개, 엠바고 등과 같은 일반적인 소프트웨어 취약점 보고서 처리 절차에 대한 지식을 갖추어야 합니다.
보고된 취약점에 관한 엠바고 정보를 공유하거나 이를 바탕으로 행동해서는 안 됩니다. 허용되지 않는 행동의 예로는 동료와 정보를 공유하거나, 권고문 게시일 전에 공개되지 않은 완화책이나 패치를 공개적으로 배포하는 행위가 포함됩니다.
프로젝트에 제출된 취약점 보고서의 “Coordinator” 역할을 수행해야 합니다. 코디네이터의 책임은 업계 표준 기간인 90일 이내에 보고서를 PSRT 프로세스를 통해 “완료” 상태로 진행하는 것이며, 이는 보고서가 거부되거나 게시된 권고문 및 완화책으로 처리되는 것을 의미합니다.
코디네이터로서 보고서가 취약점인지 판단하고 패치를 개발하기 위해 필요한 경우 관련 핵심 팀 멤버 또는 트리아저를 참여시켜야 합니다. 코디네이터는 고립되어 작업하기보다 각 보고서에 대해 최선의 결정을 내릴 수 있도록 핵심 팀 멤버를 참여시키는 것이 권장됩니다.
코디네이터로서 CVSS를 사용하여 심각도를 계산하고 security-announce@python.org에 공유할 권고문을 작성해야 합니다. 이러한 권고문은 PSF CVE 번호 지정 기관이 CVE 레코드에 사용합니다.
어떤 이유로든 더 이상 보고서를 진행할 수 없는 코디네이터는 PSRT 내 다른 사람에게 자신의 코디네이터 역할을 위임해야 합니다.
관리자인 PSRT 멤버에게는 추가 책임이 있습니다.

PSRT 관리자의 책임

운영 위원회가 관리자로 지정한 PSRT 멤버에게는 다음과 같은 추가 책임이 있습니다.

GitHub 팀, 메일링 리스트, Discord 채널 및 기타 PSRT 공간을 관리하여 PSRT 멤버의 정식 목록과 동기화되도록 해야 합니다.
매년 비활성 PSRT 멤버 목록이 포함된 보고서를 운영 위원회에 제출해야 합니다.

GitHub 보안 권고문 및 GitHub 팀

이 PEP는 GitHub 팀 python/psrt를 PSRT 멤버의 정식 목록으로 표준화하고, 메일링 리스트와 Discord를 각각 별도로 관리하는 대신 이에 맞추어 정렬할 것을 제안합니다. 멤버가 추가되거나 제거될 때 이 세 채널 전체에서 멤버십 변경 사항이 일관되도록 프로세스 문서를 작성합니다.

이 PEP는 프로젝트별 취약점 보고서를 처리하는 시스템으로 GitHub 보안 권고문을 채택할 것을 제안합니다. 관련 저장소에서 GHSA를 활성화하고 python.org의 최상위 PSRT 페이지 및 프로젝트 보안 정책에서 GHSA로 직접 연결합니다.

책임과 함께, 코디네이터를 지정하는 방법 및 심각도를 계산하는 방법 등 GHSA를 사용하여 취약점 보고서를 처리하는 PSRT 프로세스를 Python Developer’s Guide에 추가합니다.

GHSA를 채택하면 python/psrt프라이빗 저장소(GitHub 팀과 동일한 슬러그를 공유함)와 동기화 도구를 비활성화하게 되며, 패치 개발에 더 이상 필요하지 않게 됩니다.

Python 개선 제안 한국어 번역