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 보안 권고(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 사용자가 상당한 피해를 입을 수 있습니다. 이러한 이유로 해당 취약점의 해결에 관여하는 사람만 정보에 접근할 수 있도록 제한하는 것이 매우 중요합니다.

기존에는 패치 개발 협업을 위해 python/cpython 저장소의 미러인 비공개 python/psrt 저장소에 GitHub 사용자를 수동으로 추가하는 방식을 사용했습니다. 이 방식으로는 특정 취약점에 대해 특정 협업자만 골라낼 수 없었으므로, 모든 협업자가 모든 보고서와 패치에 접근할 수 있었습니다.

이러한 수동 절차 때문에 PSRT 외부의 코어 개발자를 협업에 참여시키기를 꺼리게 되었고, 이는 패치 개발을 더 어렵게 만들 수 있습니다. 또한 이러한 제약 때문에 취약점 보고자도 패치 작업에 협업할 수 없었습니다.

PSRT 신규 기여자 온보딩

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

실제로 이 때문에 PSRT에 새로 합류하는 구성원이 비교적 적었으며, 이는 시간이 지남에 따라 보고서를 분류하고 코어 팀과 함께 해결책을 개발하는 그룹의 역량에 부정적인 영향을 미칠 수 있습니다.

취약점 보고서에 대한 명확한 담당자 부재

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

이상적으로는 이슈, 풀 리퀘스트, PEP와 마찬가지로 지정된 한 사람이 완화 작업을 완료까지 이끌어 갈 책임을 져야 합니다. 이렇게 하면 그 사람이 “남의 영역을 침범”할까 걱정하지 않고 작업에 기여하고 결정을 내릴 수 있습니다.

취약점 공개 일정에 맞추기

취약점 보고 모범 사례에서는 사용자, 프로젝트, 보고자의 요구 사이에서 균형을 맞추기 위해 최초 공개 시점과 보고서가 대중에게 공개되는 시점 사이에 90일의 기한을 두도록 권장합니다(recommend a 90 day timeline). 많은 취약점 보고 조직이 이미 이 기한을 사용하고 있으며, 프로젝트가 자체적인 완화 조치를 마련하지 않더라도 취약점을 공개적으로 공개합니다.

보고서가 진행되지 않고 멈추거나, 잊히거나, 해결책 없이 공개되는 일을 막기 위해 이 PEP는 최초 공개부터 권고문 게시까지 90일의 기한에 맞출 것을 권장합니다.

근거

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

PSRT에는 누구를 PSRT에 받아들이거나 PSRT에서 제외할지 결정하는 메커니즘이 없습니다. 업무가 보안에 민감하다는 점까지 더해져 누구를 받아들여야 할지 결정하기가 어려울 수 있지만, PSRT 멤버십을 평가하는 책임을 지는 체계는 반드시 있어야 합니다.

이 PEP는 PSRT 멤버십을 보안 취약점을 활발히 조율하는 사람, 감독에 관여하는 멤버(운영 위원회), 보안 릴리스에 관한 정보가 필요한 멤버(릴리스 관리자)로만 제한할 것을 제안합니다.

보고를 분류하고 조율하는 활동으로 프로젝트에 이점을 더하지 않으면서 위험만 추가하는 일을 피하기 위해, 멤버십의 기준으로 활동 여부를 권장합니다.

GitHub 보안 권고(GHSA) 사용

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

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

프로젝트 단위나 전역이 아닌 보고 단위로 GitHub 팀과 계정을 “협력자”로 관리하는 기능.
GitHub 계정을 사용하여 PSRT에 속하지 않은 협력자를 보고 단위로 관리하는 기능.
수정 사항을 개발하기 위한 “풀 리퀘스트”와 유사한 사용자 인터페이스.
UI 안에서 각 보고의 보고자, 조율자, 공로자, 제출 시각, CVE ID, 심각도를 추적하는 기능.
다른 서비스(CVE 등) 및 봇과 통합하기 위한 프로그래밍 방식의 API.

하지만 GHSA에 없는 기능은 다음과 같습니다:

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

이러한 누락된 기능은 GitHub에 보고되었으며, 어느 것도 GHSA 채택을 가로막지는 않습니다. GHSA 기능에 완전한 API가 없다는 점을 우회하기 위해 약간의 작업이 필요할 것입니다.

명세

PSRT 멤버십 정책

PSRT는 similar to core team nominations 방식으로 추천을 진행합니다. 즉, 기존 PSRT 멤버가 새 멤버 추천을 PSRT에 제기하면, 기존 PSRT 멤버들이 그 추천에 대해 투표합니다. 새 멤버는 코어 개발자, 트리아저 또는 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, 패치, 조율된 공개(coordinated disclosure), 엠바고 등 일반적인 소프트웨어 취약점 보고 처리 절차를 잘 알고 있어야 합니다.
보고된 취약점에 관한 엠바고 정보를 공유하거나 그 정보를 바탕으로 행동해서는 안 됩니다. 허용되지 않는 행동의 예로는 동료와 정보를 공유하는 것, 또는 권고문 공개일 이전에 공개되지 않은 완화 조치나 패치를 공개적으로 배포하는 것이 있습니다.
프로젝트에 제출된 취약점 보고의 “코디네이터(Coordinator)” 역할을 맡습니다. 코디네이터의 책임은 업계 표준 기한인 90일 이내에 보고를 PSRT 절차에 따라 진행하여, 거부되었거나 권고문과 완화 조치가 공개된 “완료” 상태로 만드는 것입니다.
코디네이터로서, 보고가 취약점인지 판단하고 패치를 개발하는 데 필요한 경우 관련 코어 팀 멤버나 트리아저를 참여시킵니다. 코디네이터는 혼자 작업하기보다는 각 보고에 대해 최선의 결정을 내릴 수 있도록 코어 팀 멤버를 참여시키는 것이 권장됩니다.
코디네이터로서, CVSS를 사용하여 심각도를 산정하고 security-announce@python.org에 공유할 권고문을 작성합니다. 이 권고문은 PSF CVE 번호 부여 기관(CVE Numbering Authority)이 CVE 레코드에 사용합니다.
어떤 이유로든 더 이상 보고를 진행할 수 없게 된 코디네이터는 코디네이터 역할을 PSRT의 다른 사람에게 위임해야 합니다.
관리자인 PSRT 멤버는 추가 책임을 집니다.

PSRT 관리자의 책임

운영 위원회(Steering Council)가 관리자로 지정한 PSRT 멤버는 다음과 같은 추가 책임을 집니다:

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

GitHub 보안 권고(GitHub Security Advisories)와 GitHub 팀

이 PEP는 GitHub 팀 python/psrt를 PSRT 멤버의 공식 명단으로 표준화하고, 메일링 리스트와 Discord를 각각 따로 관리하는 대신 이 명단에 맞추도록 제안합니다. 멤버가 추가되고 제거될 때 멤버십 변경 사항이 이 세 채널 전체에 일관되게 반영되도록 절차 문서를 작성할 것입니다.

이 PEP는 프로젝트별 취약점 보고를 처리하는 시스템으로 GitHub 보안 권고(GitHub Security Advisories)를 도입할 것을 제안합니다. 관련 저장소에서 GHSA를 활성화하고, python.org의 최상위 PSRT 페이지와 프로젝트 보안 정책에서 이를 직접 링크할 것입니다.

책임과 함께, 코디네이터를 지정하는 방법과 심각도를 산정하는 방법 등 GHSA를 사용하여 취약점 보고를 처리하는 PSRT 절차도 Python Developer’s Guide에 추가될 것입니다.

GHSA 도입과 동시에 python/psrt 비공개 저장소(GitHub 팀과 같은 슬러그를 사용합니다)와 동기화 장치를 비활성화합니다. 이는 더 이상 패치 개발에 필요하지 않기 때문입니다.

Python 개선 제안 한국어 번역