[특집] 엠바고는 누구의 것인가 — 조율된 공개 30년의 논쟁, 그리고 PHP2Shell의 일곱 시간

이 글이 다루는 것

PHP2Shell의 사흘을 정리하면서 가장 오래 남은 장면은 결함 자체가 아니었습니다. "수정이 든 이미지를 먼저 내놓아도 되는가"라는 질문이었습니다. 한쪽은 엠바고를 일방적으로 깼다고 하고, 다른 쪽은 악용이 시작된 상황에서는 조율의 예외라고 답했습니다.

이 글은 그 논쟁의 뿌리를 봅니다. 엠바고(공개 보류)는 누구의 것이고, 언제까지 지켜야 하며, 누가 깰 자격이 있는가. 결함이 어떻게 작동하는지는 이번에도 다루지 않습니다. 대신 정보가 누구에게, 언제, 어떤 조건으로 흘러야 하는가라는 규칙의 역사를 봅니다.

크게 보기

1부 · 일곱 시간 반: 번호가 새고, 이미지가 열렸다

PHP 재단의 기록에 따르면 공개 일정은 공개 이틀 전까지는 잘 돌아갔습니다. 연구자들이 신고한 것은 8월 11일(Calif·OpenAI)과 24일(Wiz). 수정 설계는 오래 걸렸고, 배포판과 연장 지원 업체들은 패치를 먼저 받아 포장 중이었습니다.

그러다 10월 20일 15:00(UTC) 무렵부터 CVE 번호 두 개가 틀린 공개 시각과 틀린 점수(10.0, 실제는 9.2)와 함께 온라인에 돌기 시작했습니다. 기술 세부는 새지 않았다고 재단은 적었습니다. 재단은 19:30에 사전 예고를 내고 공개일을 하루 앞당겼습니다. 배포판 포장이 끝나지 않아 즉시 공개는 택하지 않았다는 설명입니다.

이어서 Calif가 개념 증명 영상을 실수로 올렸다가 지웠고, 삭제본이 퍼졌습니다. 재단이 일부 핵심 인프라 업체에 주던 완화 조언도 샜을 수 있다고 인정했습니다. 그리고 10월 21일 07:41, Chainguard가 수정이 든 빌드 이미지를 누구나 받을 수 있게 공개했습니다. 공식 릴리스 6시간 19분 전이었습니다.

이 마지막 장면에서 두 설명이 갈립니다.

• PHP 재단: Chainguard도 다른 배포판처럼 패치를 미리 받았다. 빌드된 이미지를 공개하면 공격자가 수정을 바이너리 형태로 분석할 수 있는데, 다른 모든 사용자는 아직 기다리는 중이었다. 이는 몇 주에 걸친 조율을 무시한 일방적 파기다.
• Chainguard CEO Dan Lorenc: 우리는 새게 한 것이 아니다. 조율된 공개는 실제 악용 증거가 있을 때까지 조율하는 것이고, 여러 업체가 악용을 봤다고 해서 내보냈다. 같은 결정을 다시 해도 같을 것이다. 그는 또 "취약점이 있다는 말만 들어도 찾을 수 있다. 금요일에 나도 그렇게 했다"고 말했습니다.
• 캐노니컬(우분투): 제3자의 조기 유출은 유감이지만 공개 절차는 잘 작동했다고 본다.

여기서 확인된 사실과 쟁점을 나눠 둡니다.

크게 보기

2부 · 엠바고는 왜 필요하고, 왜 새는가

필요한 이유: 수정은 '보내는 일'이 아니라 '들어가는 일'

수정판이 나왔다고 모든 서버가 안전해지지 않습니다. 수정은 배포판의 패키지가 되고, 호스팅의 이미지가 되고, 컨테이너 레지스트리의 태그가 되어야 사용자에게 닿습니다. 앞 글에서 본 것처럼 같은 수정이 환경마다 다른 번호와 다른 날짜로 도착합니다. PHP 재단이 공개를 하루만 당기고 즉시 공개하지 않은 이유도 "배포판이 아직 포장 중이어서 즉시 공개하면 많은 사용자가 쉬운 업데이트 경로를 갖지 못한다"였습니다.

엠바고는 이 포장 시간을 사 주는 장치입니다. 비밀 자체가 목적이 아닙니다.

새는 이유: 참여자가 늘수록 비밀은 얇아진다

사전 통지의 대표 규칙인 linux-distros 메일링 리스트 운영 규칙을 보면 이 긴장이 그대로 적혀 있습니다.

• 엠바고는 최대 14일, 7일 미만을 선호한다. 하루나 몇 시간짜리도 유용할 수 있다.
• 받은 정보는 배포판 팀 안에서 필요한 사람만 알고, 신고자의 허락 없이 퍼뜨리지 않는다.
• 수정이 이미 공개 저장소에 올라가 있으면 사실상 공개된 것으로 본다.

마지막 규칙이 중요합니다. 수정은 비밀을 지키는 장치이면서 동시에 가장 큰 단서입니다. 이번에 문제가 된 것도 수정 자체가 아니라 빌드된 수정이 모두에게 열린 순간이었습니다. 재단이 문제 삼은 지점이 바로 여기입니다. 누구나 받을 수 있는 빌드는 수정을 바이너리 형태로 분석할 단서가 됩니다.

PHP 사건에서 갈린 것은 결국 이 문장입니다. "정보를 아는 사람이 많을수록 샌다." 재단이 패치를 받는 파트너를 늘린 것은 사용자를 위해서였고, 늘어난 파트너가 새는 구멍이 되기도 했습니다.

크게 보기

3부 · 30년의 논쟁: 자물쇠에서 90+30까지

논쟁은 컴퓨터 이전부터

Wikipedia의 정리에 따르면 공개 논쟁은 19세기 자물쇠 업계에서 이미 있었습니다. 약점을 비밀에 부쳐야 하는가, 모두가 알게 해야 하는가. 컴퓨터 보안에서도 같은 구도가 반복됩니다.

• 즉시 공개(full disclosure)를 옹호하는 쪽은 공개 검증만이 보안을 높인다고 봅니다. Bruce Schneier는 2007년 글에서 "세부를 공개하는 것은 아주 좋은 생각이다. 공개 검증만이 보안을 개선하는 유일한 믿을 만한 방법이고, 비밀은 우리를 덜 안전하게 만들 뿐"이라고 썼습니다. 고객이 모르면 패치를 요구하지 못하고 개발사도 고칠 유인이 없다는 논리입니다.
• 조율된 공개를 옹호하는 쪽은 사용자가 개발사의 지침 없이는 정보를 쓸 수 없고, 정보는 낮은 기술력의 공격자에게 더 큰 힘을 준다고 봅니다. 마이크로소프트의 설명으로는 조율은 "고객이 포괄적이고 질 좋은 업데이트를 받으면서, 그동안 악의적 공격에 노출되지 않게" 하려는 것입니다.
• 비공개는 취약점을 직접 쓰거나 파는 쪽이 선호합니다.

규칙이 만들어진 순서

• 2000년 6월, RFPolicy(Rain Forest Puppy): 신고자가 개발사에 연락하면 개발사는 5영업일 안에 답해야 하고, 답이 없거나 소통을 끊으면 신고자는 공개해도 된다. '기한이 지나면 공개'의 초기 형태입니다.
• 2001년, 마이크로소프트 Scott Culp의 글: "정보 무정부 상태를 끝낼 때"가 풀 디스클로저를 비판하며 '책임 있는 공개'라는 말의 출처가 되었습니다. 마이크로소프트는 나중에 이 말 대신 '조율된 취약점 공개(CVD)'라는 표현을 쓰자고 제안했습니다.
• 2014년경, Project Zero의 90일: 구글이 퍼뜨린 방식입니다. 개발사에 90일을 주고, 그 안에 패치하지 못하면 세부를 공개합니다. 지금은 90+30 정책으로, 90일 안에 패치하면 패치 후 30일 뒤에 공개합니다(패치가 퍼질 시간). 악용 중이면 7일, 기한 직전에 패치가 가능하면 14일 유예를 줍니다. 필요하면 개발사와 합의해 앞당길 수도 있습니다.
• 2025년 7월, Reporting Transparency: Project Zero는 신고 일주일쯤 뒤에 벤더·제품·기한만 먼저 공개하는 시험을 시작했습니다. 이유는 "수정이 만들어진 뒤에도 하류가 이를 제품에 넣기까지의 상류 패치 간극"이 길기 때문입니다. 앞 글의 지점이 정책으로 옮겨 간 것입니다.

사건들이 규칙을 바꿨다

• 2018년 Meltdown·Spectre: 벤더가 2017년 7월 28일에 알았고 조율된 공개일은 2018년 1월 9일이었지만, 리눅스 커널의 공개 커밋과 메일을 언론이 보도하자 1월 3일로 6일 당겨졌습니다.
• 2021년 Log4Shell: 11월 24일 신고, 12월 6일에 수정이 공개 저장소에 올라갔고 12월 9일에 공개되었습니다. 12월 1일에 이미 악용 또는 스캔 흔적이 있었다는 증언이 있습니다. 중국 정부는 취약점을 보고하지 않았다는 이유로 알리바바 클라우드의 협력 자격을 6개월 정지했습니다. 정부 보고 의무라는 변수가 공개 규칙에 들어온 사건입니다.
• 2014년 Heartbleed: 4월 1일 구글 연구자가 OpenSSL에 신고, 4월 7일에 수정판과 공개. 그런데 공개 이전에 이미 수정한 조직이 있었고 경위가 분명하지 않아 누구에게 먼저 알리는가가 논쟁이 되었습니다.

다섯 가지 규칙을 나란히

4부 · 논문이 말하는 '적당한 보호 기간'

규칙 뒤에는 질문이 있습니다. 보호 기간은 얼마가 맞는가. 여기서 자주 인용되는 연구 두 편을 소개합니다.

• Rescorla, "Is Finding Security Holes a Good Idea?" (IEEE Security & Privacy 3권 1호, 2005, 14~19쪽): 제목 그대로 취약점을 찾는 행위의 득실을 묻습니다. 이 글에서는 그 질문이 2005년에 이미 학계의 주제였다는 점만 짚습니다.
• Arora, Telang, Xu, "Optimal Policy for Software Vulnerability Disclosure" (Management Science 54권 4호, 2008, 642~656쪽): 공개 정책을 사회적 계획자와 개발사의 게임으로 모델링합니다. 초록에 따르면 결론은 이렇습니다.
  • 개발사는 사회적으로 최적인 것보다 느리게 패치를 낸다.
  • 그래서 계획자는 보호 기간을 줄여서 개발사를 재촉하는 것이 최적이며, 때로는 패치 출시가 공개 시점과 일치하기도 한다.
  • 보호 기간이 길다고 패치 품질이 항상 좋아지지는 않는다.
  • 우회책(work-around)을 쓰는 사용자가 있으면 계획자의 영향력은 커지지만, 우회책을 못 쓰는 사용자에게 외부 비용을 지우는 경우 사회 비용이 오히려 늘 수 있다.

두 번째 결론이 요즘의 논쟁과 이어집니다. 보호 기간은 한쪽 위험을 줄이는 대신 다른 쪽 위험을 쌓는 장치입니다. 아래 도식에서 기간을 움직여 보세요.

이 도식은 논문의 수치가 아니라 모양을 직관으로 옮긴 것입니다. 기간이 짧으면 준비가 덜 된 채 공개되고, 길면 그동안 새거나 독립적으로 찾아낼 위험이 쌓입니다. 두 곡선이 만나는 지점이 있다는 점, 그리고 독립 발견이 쉬워질수록 그 지점이 왼쪽(더 짧은 쪽)으로 옮겨 간다는 점이 요점입니다.

크게 보기

5부 · 엠바고가 흔들리는 네 가지 신호

OpenAI가 이번 사건 직후 내놓은 제안은 엠바고를 지키는 규칙뿐 아니라 일정을 다시 볼 조건도 명시합니다. 악용 증거, 유출, 드러난 수정, 정체된 수정 가운데 하나라도 있으면 방어자에게 준 시간을 다시 계산하라는 것입니다. 지난 사건에 이 네 신호를 대입해 보면 PHP2Shell의 특이함이 드러납니다.

PHP2Shell은 네 신호가 한 사건에 모두 나타난 경우로 읽힙니다. 특히 가장 어려운 신호는 첫째, 실제 악용의 증거입니다. Chainguard는 여러 업체의 보고를 근거로 들었고 PHP 보안팀은 공개 시점에 작동하는 익스플로잇을 확인하지 못했습니다. 아마존은 10월 17일의 시도 한 건을 기록했지만 실제 시스템에서 성공했을지는 불분명하다고 했습니다. 증거가 있다는 말과 증거가 확인되었다는 말 사이의 거리가 곧 이번 논쟁의 크기입니다.

크게 보기

6부 · AI 시대의 재설계: OpenAI의 5단계 제안

OpenAI는 이번 사건 직후 "Patch the Planet" 활동에서 얻은 경험으로 AI 시대에 맞는 대응 틀을 제안하고 의견을 구했습니다. 요지는 다음 다섯 단계입니다.

1. 상류의 결함을 검증하고 고친다. 유지보수자와 연구자가 확인하고, 최신 모델로 우회와 변종을 찾는 적대적 시험을 한다.
2. 영향받는 조직에 대응할 시간을 준다. 배포판은 옛 릴리스용 수정을, 호스팅은 완화책을, 보안 업체는 탐지 규칙(WAF 등)을 준비한다. 누구에게 미리 알릴지는 유지보수자가 정한다.
3. 정부와 조율한다. 핵심 시설에 지침이 닿도록 한다.
4. 제품 전반에 걸친 업데이트를 준비한다.
5. 패치가 나오면 지침을 공개하고 배포를 돕는다. 노출 평가, 공식 업데이트·임시 완화 찾기, 수정이 실제로 돌고 있는지 확인하는 법을 안내한다.

누구에게 미리 알릴지의 기준도 적혀 있습니다. 조직의 보호 역할(자기 시스템과 고객을 지키는가), 행동에 필요한 시간, 민감한 정보를 다룰 능력을 봅니다. 그리고 악용 증거, 유출, 수정이 드러남, 수정 정체가 있으면 일정을 다시 봅니다.

흥미로운 것은 OpenAI가 스스로 열린 질문을 남긴 대목입니다.

• 공개 기간: 유지보수자·운영자·방어자가 믿을 만한 수정을 준비하고 배포하는 데 시간이 얼마나 필요한가? 일부 사용자만 먼저 보호할 수 있을 때 어떤 증거가 조기 공개를 정당화하는가?
• 긴급 패치: 관리자가 접근을 잃은 시스템에 대해 정부나 다른 운영자가 취약점을 이용해 대신 패치해도 되는가, 되면 어떤 안전장치가 필요한가? OpenAI는 알려진 취약점을 인터넷 전체에서 상시 스캔해 소유자에게 알리거나 직접 패치하는 최종 상태도 상상해 볼 수 있다고 적었습니다.

두 번째 질문은 아직 합의가 없는 영역입니다. 이 글은 어느 편도 들지 않고, 질문이 정책 문서에 실제로 올라왔다는 사실만 기록합니다.

7부 · 역할별로 정리하면

모두가 같은 것을 할 수는 없습니다. 이번 사건과 위 규칙에서 읽히는 역할별 숙제를 적습니다.

운영자의 숙제는 앞 글의 확인 순서와 직접 이어집니다. 엠바고의 결과는 결국 '내 서버가 고쳐졌는가'로 돌아옵니다.

크게 보기

8부 · 2026년의 의미: 엠바고는 소유가 아니라 위탁이다

처음의 질문으로 돌아갑니다. 엠바고는 누구의 것일까요?

연구자의 것은 아닙니다. 발견은 연구자의 몫이지만 정보가 열리는 시점은 방어자들의 준비에 달려 있습니다. 유지보수자의 것도 아닙니다. 유지보수자는 정보를 맡아서 일정을 짜는 사람이지, 그 정보로 누구를 보호할지 혼자 정할 수 있는 사람이 아닙니다. 배포·이미지 공급자의 것도 아닙니다. 그들은 정보를 위탁받은 쪽이라 위탁의 조건을 따라야 합니다. 그렇다면 남는 답은 하나입니다. 엠바고는 사용자가 쓸 시간을 사 주는 것이고, 그 시간은 사용자의 것입니다.

이번 사건에서 이 위탁이 흔들린 것은 누군가 악의를 가져서가 아닙니다. 참여자가 늘었고, 독립 발견의 비용은 낮아졌고, 그 사이에 악용 증거라는 말이 서로 다른 기준으로 쓰였습니다. 앞선 글에서 본 대로 AI는 발견과 입증의 비용을 낮추고 있습니다. 코어닷투데이가 정리한 흐름대로라면 '같은 날 둘 이상이 같은 결함을 찾는' 일은 예외가 아니라 일상이 됩니다. Lorenc의 말대로 "취약점이 있다는 말만 들어도 찾을 수 있는" 세상에서는 보호 기간이 길수록 위험이 쌓입니다. 4부의 도식이 그리는 방향입니다.

그렇다면 방향은 둘입니다. 하나는 더 짧고, 더 좁게, 더 빨리 확인되는 엠바고입니다. 위탁 대상을 줄이고, 재검토 조건을 미리 정하고, 약속을 깨는 것이 아니라 깨기 전에 알리는 절차를 두는 것입니다. 다른 하나는 공개 후의 속도입니다. 엠바고가 벌어 준 시간은 공개 순간에 끝나는 것이 아니라, 사용자가 실제로 고칠 때까지 이어져야 합니다. 이번 시리즈의 두 번째 글이 번호와 확인 이야기를 한 이유입니다.

PHP 재단은 이번 사건 뒤 중대한 결함이 어려운 절충에 걸려 있을 때 재단 지도부가 더 일찍 개입하도록 절차를 바꾸겠다고 썼습니다. 엠바고 논쟁의 끝은 규칙이 아니라 누가 그 규칙을 운영할 사람과 시간을 가졌는가로 돌아옵니다. 22년 방치된 결함, 2024년의 '구조적 실패'라는 표현, 소수의 후원 개발자라는 현실은 이어질 글의 주제입니다.

참고 자료

• The PHP Foundation, "Today's PHP Security Release, and How We're Strengthening PHP Security" (2026-10-21) — "Leak and disrupted disclosure" 절
• The Register, "PHP blames supply chain security biz Chainguard for putting huge chunks of the web at risk" (2026-10-22); The New Stack, "AI found a critical PHP flaw. The bigger failure began in 2024." (2026-10-22)
• Amazon Threat Intelligence, MadPot 관측 글 (2026-10-21)
• OpenAI, "Coordinated disclosure of critical vulnerabilities" — Patch the Planet 대응 틀 제안
• Google Project Zero, "Vulnerability Disclosure Policy" (90+30); "Reporting Transparency" (2025-07)
• oss-security 위키, linux-distros 메일링 리스트 규칙
• Wikipedia, "Full disclosure (computer security)", "Coordinated vulnerability disclosure", "RFPolicy", "Heartbleed", "Meltdown (security vulnerability)", "Log4Shell"
• Rain Forest Puppy, "RFPolicy for vulnerability disclosure", Bugtraq 2000-06
• Scott Culp, "It's Time to End Information Anarchy" (Microsoft, 2001)
• E. Rescorla, "Is Finding Security Holes a Good Idea?", IEEE Security & Privacy 3(1), 14–19 (2005)
• A. Arora, R. Telang, H. Xu, "Optimal Policy for Software Vulnerability Disclosure", Management Science 54(4), 642–656 (2008)
• Bruce Schneier, 풀 디스클로저에 관한 2007년 글 (Wikipedia 인용)