CPython의 보안 보고와 대응 작업이 2026년에 크게 증가함

CPython의 2026년 CVE 증가를 곧바로 취약점 폭증으로 읽는 것은 위험하다고 봅니다. 기사에서 제시한 수치는 최종적으로 보안 이슈로 인정된 결과를 보여줄 뿐, PSRT가 실제로 검토한 전체 보고서나 처리에 투입한 시간을 나타내지는 않습니다. 오히려 이제까지 보이지 않던 대응 업무를 측정하고 공개하려는 단계에 들어섰다는 점이 더 중요해 보입니다.

특히 PSRT는 보안 보고로 들어온 내용을 그대로 CVE로 전환하는 조직이 아닙니다. 일부는 일반 버그로 종결되고, 일부는 보안이나 버그 어느 쪽으로도 분류되지 않은 채 닫힙니다. 이 사실은 CVE 개수만으로 보안 대응 역량을 평가해서는 안 된다는 뜻입니다. 접수부터 재현, 영향도 판단, 수정 조율, 공개 여부 결정까지의 과정이 실제 방어력에 더 가깝다고 봅니다.

GHSA 통계를 2024년 7월 이후부터 따로 집계했다는 점도 의미가 큽니다. 그 이전에는 이메일 토론과 스레드가 주요 접수 통로였고, 채널이 바뀌면 같은 현상도 전혀 다른 숫자로 보일 수 있습니다. 따라서 2026년 GHSA 증가가 공격자나 연구자의 관심이 커졌기 때문인지, 제출 경로가 정리됐기 때문인지는 아직 단정하기 어렵습니다. 게다가 2026년은 아직 절반만 지난 시점이므로 연간 비교에는 분명한 한계가 있습니다.

제가 더 긍정적으로 보는 부분은 보안 업무의 제도화입니다. Seth Larson의 상주 역할은 보고서 처리만이 아니라 보고 품질을 높이고, 평가 기준을 만들고, 보안 정책을 정비하는 일을 포함합니다. PEP 811이 PSRT의 구성원과 책임을 정의하고, Alpha-Omega가 해당 직책을 후원했다는 사실은 오픈소스 보안이 개인의 선의만으로 유지되기 어렵다는 현실을 보여줍니다. 전담 인력과 지속적인 재원이 있어야 누락되기 쉬운 조사 업무까지 감당할 수 있습니다.

다만 공개 지표는 다음 단계에서 더 정교해져야 합니다. 유입 보고서 수, 실제 처리 건수, 평균 응답 시간, 일반 버그로 분류된 비율, 장기 미해결 건수 같은 지표가 함께 공개돼야 증가의 의미를 제대로 판단할 수 있습니다. 그렇지 않으면 CVE가 늘 때는 위기라는 오해가 생기고, 줄 때는 대응이 개선됐다는 근거 없는 낙관이 생길 수 있습니다. 특히 이메일 기반 기록과 GHSA 기반 기록을 한 줄로 이어 비교할 때는 분류 기준의 변화까지 설명해야 합니다.

앞으로 CPython의 보안 보고는 더 많이 들어오고, 더 많이 공개될 가능성이 큽니다. 그것은 관리 실패의 신호라기보다 신고 경로가 알려지고 신뢰가 쌓였다는 결과일 수 있습니다. 다만 이 흐름이 지속되려면 PSRT에 보고서 처리 권한과 인력, 안정적인 후원이 계속 제공돼야 합니다. CPython이 얻은 가장 큰 성과는 CVE 숫자를 늘린 것이 아니라, 보안을 개인의 비공개 대응에서 지속 가능한 운영 체계로 옮겨놓은 데 있다고 봅니다.