요약
오픈AI가 AI로 찾은 PHP 치명적 취약점에 공동 대응하고, 이를 본뜬 공개 전 대응 절차를 제안했습니다.
오픈AI가 지난 두 달 동안 PHP 메인테이너(프로젝트를 관리하는 개발자), 보안 업체들과 함께 치명적 취약점 두 건에 대응한 과정을 공개했습니다. 보안 연구 업체 캘리프가 Patch the Planet 활동 중 GPT-5.6 Sol로 결함을 찾았고, 위즈도 두 취약점을 따로 찾아 보고했습니다.
왜 중요한가
- 웹사이트에 널리 쓰이는 PHP의 결함이라, 오픈AI는 최근 손꼽히는 파급력의 보안 문제로 봤습니다.
- 같은 AI 능력이 공격 도구도 빠르게 만들 수 있어, 공격자보다 먼저 찾은 시간을 방어 준비에 쓰자는 제안입니다.
- 오픈AI는 비슷한 발견이 몇 달 안에 급증할 것으로 보고, 한 번으로 끝나지 않는 반복 가능한 절차를 만들려 합니다.
핵심 내용
- 대응 절차는 수정 검증, 영향받는 조직의 사전 준비, 정부 협력, 제품별 업데이트, 공개 후 배포 지원의 다섯 단계입니다.
- 수정 단계에서는 최신 모델로 패치 우회 방법과 변종 취약점을 찾는 적대적 테스트(공격자 입장에서 뚫어 보는 시험)를 합니다.
- 누구에게 미리 알릴지는 메인테이너가 정하고, 참여자는 역할에 따라 침해 흔적 로그부터 실제 공격 코드까지 받습니다.
- 보안 인력이 부족한 필수 서비스 조직에 10억 달러 규모의 Daybreak 이용을 지원하고, 메인테이너 전원에게 Codex for OSS 구독을 줍니다.
- 공개 시점, 정부의 긴급 패치, 지원이 끝난 옛 버전 백포트(수정을 옛 버전에 옮겨 적용하는 일) 등에 대해 의견을 구했습니다.
HN 반응
- 공격에도 쓰일 모델을 팔면서 방어까지 맡는 건 이해충돌이라는 비판에, 취약점은 원래 있었고 AI는 찾아냈을 뿐이라는 반론이 맞섰습니다.
- 수정이 PHP 8.2 이상에만 나와, 아직 많이 쓰이는 7.x·5.6용 백포트야말로 AI가 할 일이라는 지적이 나왔습니다.
그러니까 이 사람들 때문에 취약한 시스템이 한 달 넘게 방치됐고, 패치는 '선택받은 자들'만 받아 봤다는 거네요.
이쯤 되면 차라리 조율이고 뭐고 없이 버그를 그냥 공개하는 쪽에 찬성합니다. 적어도 패치를 먼저 받는 특권층이 따로 생기지는 않으니까요.
세상 여러분, 이 문제는 저희가 만들었고, 쓰든 안 쓰든 여러분 모두가 피해를 보게 될 겁니다. 다행히 해결책이 있습니다. 저희에게 큰돈을 내시면 고쳐 보려고 노력하겠습니다. 문제는 서둘러야 한다는 겁니다. 저희가 위험한 물건을 최대한 빨리 풀고 있으니, 안전장치를 갖추려면 저희한테 돈을 내시는 게 좋을 겁니다. 이걸 고칠 수 있는 건 저희뿐이고, 말씀드렸듯이 저희가 워낙 빠르게 움직이고 있어서 시간이 얼마 없거든요.
그래서 토큰은 몇 개나 잡아 드릴까요.
그건 발견된 모든 버그의 책임을 두고, 취약점을 찾아내고 대가를 받으려는 화이트햇 보안 연구자들을 탓하는 것과 같습니다. 전문 보안 연구자가 없던 시절에는 발견되는 취약점이 훨씬 적었습니다.
취약점은 이미 존재하고, 상당수는 수십 년 전부터 있었습니다. 우리가 찾아내거나, 아니면 더 위험한 누군가가 찾도록 놔두거나 둘 중 하나입니다. 소식을 전한 사람을 탓하지는 마세요.
저라면 없던 일로 하려 하기보다, 짧고 굵게 개선을 겪고 더 빠른 대응 주기를 체계에 내장하는 쪽을 택하겠습니다. 그게 현실이니 적응해야 합니다.
괜찮으시면 화상 통화로 대화나 토론을 해 보고 싶습니다. 동의하지는 않지만 사려 깊은 분이시고, 제가 배울 점이 있을 수도 있을 것 같아서요. 관심 있으시면 알려 주세요.
제가 아는 한 화이트햇 보안 연구자들은 거품이 꺼지기 전에 주식을 대중에게 떠넘기려고 안달 난 1조 달러짜리 기업에 몸담고서, 초인적인 해킹 도구를 정체 모를 상대에게 팔아 먹고살지는 않았어요.
그래도 저들이 하는 짓이 괜찮다고 주장하고 싶으시면 얼마든지 그러세요. 다만 이 비유를 근거로 드는 건 좀 우스꽝스럽습니다.
요점을 놓치고 계십니다. 말씀하신 예에서 화이트햇 연구자들이 성립하려면, 애초에 익스플로잇을 실행할 도구를 파는 블랙햇 해커도 겸해야 합니다. 문제를 만들어 놓고 직접 해결하면 이해충돌이 생깁니다. 화이트햇 보안팀이 서비스를 더 팔려고 익스플로잇을 공개해 버리고, 패치하도록 해당 회사에 알리지 않는다면 아무도 그걸 용납하지 않을 겁니다.
아니요, 문제를 만든 건 보안 취약점이 있는 코드를 처음 짠 사람들이거나, 언어·프레임워크·SDK를 설계하면서 순방향 호환성을 쉽게 확보하지 못한 사람들입니다.
아니요, 그들은 그 존재를 공개하는 것이지 풀고 있는 게 아닙니다.
제가 나무로 울타리를 지었다고 해 봅시다. 불에 탄다는 걸 알지만 위험은 자연 산불뿐이었는데, 누가 십대들에게 화염방사기를 팔고, 울타리를 찾아내는 시각 기능이 달린 드론까지 팝니다. 그러고는 화염방사기와 울타리 탐지 시각 기능을 갖춘 선제 방어용 드론을 저한테 돈 내고 사라고 합니다. 그러면 지금 상황이 이해되실 겁니다.
오픈AI는 익스플로잇을 찾아내는 도구를 내놓았습니다. 공범이 되려고 굳이 그걸 공개할 필요는 없습니다.
왜 이렇게 몰아가시는 거예요? 저들이 이 취약점을 만들기라도 했나요? 그리고 수정에 돈을 내라고 누가 억지로 시키기라도 했고요?
사실로부터 합리적으로 추론할 수 있는 결론이니까요.
오픈AI가 지금의 AI 사이클을 시작했습니다.
그 사이클이 에이전트 코딩 때문에 기하급수적으로 많은 보안 취약점을 드러냈습니다.
오픈AI는 합리적인 안전을 보장할 능력이 없다고 인정하면서도 특이점에 도달하려고 최대한 빠르게 달리고 있습니다.
그러더니 자사 코딩 도구로 보안 취약점을 "해결"하겠다며 구상을 내놓습니다.
제가 놓친 게 있나요? 동기와 대응에는 폭넓은 스펙트럼이 있는 법이니까요.
이번 사례(PHP 버그)에서 "AI 사이클"이 보안 취약점을 드러냈을 수는 있어도 만든 것은 아닙니다. 취약점을 아주 잘 찾아내는 AI 기반이 아닌 정적 분석 도구를 누가 내놓았다고 해서, 드러난 취약점을 고치는 비용까지 그 사람이 대라고는 하지 않을 겁니다.
맞는 말씀이지만, 문제는 버그가 존재한다는 사실 자체가 아니라 이제는 버그를 발견하고 악용할 수 있는 규모가 엄청나다는 점입니다. 발견되지 않은 버그도 문제이긴 하죠. 하지만 수십억 개의 코딩 에이전트가 모든 소프트웨어를 24시간 내내 샅샅이 뒤져 취약점을 찾는 상황은 판을 뒤흔드는 변화입니다. 위험을 무시하고 속도전만 벌이는 경쟁이 이를 더 악화시키고 있고요.
저는 이런 방향으로 보고 싶습니다. 우리에게는 엄청난 기술 부채의 산이 있고, 지금 AI가 그걸 낱낱이 드러내고 있다는 것입니다. 여러 정보기관이 저지른 난장판의 상당 부분도 바로 이 엉망진창에서 비롯됐을 거라고 봅니다. 그러니 나아지기 전에 일단 더 나빠지도록 놔둬야 합니다.
Railway가 방금 해킹당해서 환경 변수가 전부 유출됐습니다. 사람들 계정에 실제 돈이 청구되고 있고요. 저는 애들이랑 저녁 먹을 시간에 모든 키를 교체해야 합니다. 제 말은, 빠르게 하기보다 더 안전한 방식으로 할 수 있었다는 겁니다.
프로그래머들이 버그투성이 소프트웨어를 그렇게 많이 만들지 않으면 되지 않을까요? 그건 해 보셨나요?
그러게 그 드레스를 입지 말았어야죠…
같은 사람이 "AI" 기반이 아닌 익스플로잇 생성 도구를 내놓았다면요? 그 사람이 책임을 면하리라고는 장담하기 어렵습니다. 하지만 "AI"만 붙이면 갑자기 돈도 받으면서 결과에는 손을 씻을 수 있게 됩니다.
아니요, 취약점은 "컴퓨터 마법사"라는 자기 이미지에 매달린 리드들이 세대를 이어 가며 만들어 냈습니다. 그들은 텃세를 부리며 경고하는 사람이나 겸손하게 엉망인 상태를 고치려는 사람을 배척했죠. "큰 힘에는 큰 책임이 따른다"는 말(말하는 사람이 무책임한 이들을 내려다보며 단속하고 있다는 뉘앙스까지 풍기는)을 들을 때마다 너무 오그라들어서 이가 부러질 지경입니다.
잠재적 취약점을 만들어 본 적 없는 자만이 먼저 돌을 던지라고 했습니다.
사람이 좀처럼 따지 못하는 자물쇠로 가득한 세상을 상상해 보세요.
그런데 누군가 사람이 따지 못했던 훨씬 많은 자물쇠를 따는 도구를 내놓습니다.
그러고는 말하죠. 발전은 막을 수 없다, 이제 돈을 내고 자물쇠를 업그레이드하라고요. (아니, 우리의 차세대 도구에 맞게 조작해 놓지는 않을 테니 믿으세요!)
마지막 부분은 필요 없습니다. 자물쇠 따개의 발전이 빨라지고 있다면, 자물쇠 제조사는 선의로 최선을 다해 따기 가장 어려운 자물쇠를 만들 수 있고, 조작할 필요도 없습니다. 그래도 그 자물쇠들은 결국 언젠가 따이게 될 겁니다.
마법 같은 코드 생성 기계를 파는 회사가 정말로 같은 소프트웨어의 옛 버전에 수정을 백포트하는 방법을 묻고 있는 건가요?
이거 진짜예요?
그 마법의 코드 생성 기계가 더 이상 업데이트되지 않는 패키지를 직접 업데이트할 수 있는 게 아니라면, 이건 마법 같은 코드 생성으로 풀 수 있는 문제가 아닙니다.
그 쓰레기 기계는 수정을 PHP 5로 백포트해 주거나, 코드를 PHP 8에 맞게 호환되도록 바꿔 줄 수 있죠.
수정을 백포트하는 쪽이 전체적으로 훨씬 노력이 적게 듭니다. 영향받는 PHP 마이너 릴리스는 수십 개에 불과한데, 아직 옛 PHP 버전으로 돌아가는 웹사이트는 수백만 개나 되니까요.
네, 하지만 지원이 끝난 배포판 릴리스 계열의 패키지를 실제로 업그레이드해서 릴리스하지는 못하잖아요. 그건 사람이 풀어야 할 문제입니다.
"더 이상 보안 업데이트를 받지 못하는 예전 버전"을 쓰는 사람들은 이 도구가 내놓는 새 패치 스트림으로 업데이트하지 않을 가능성이 큽니다. 어차피 자기 인프라를 관리하지 않는 사람들이니까요.
아니요. 기술적으로 어떻게 고치느냐가 아니라, 기술 외적인 조직 차원의 난제를 어떻게 헤쳐 나가느냐를 말하는 것 같습니다.
버그가 발견된 뒤에 고치는 건 꽤 간단한 일입니다. 하지만 공급망에 영향을 줄 때 어디에 어떻게 배포할 것인가는 다른 문제입니다.
예를 들어 다운스트림 의존성에 취약점을 제보했는데 업스트림에서 패치해야 한다는 답이 올 수 있습니다. 그럼 어떻게 해야 할까요? 업스트림에 이슈를 올려야 할까요? 그럴 수도 있지만 아마 아닐 겁니다. 아마도 해법은 모든 다운스트림 의존성에 연락해 의존성을 갈아타거나 패치하게 만드는 것일 텐데, 방금 취약점을 제보했는데 그들이 대수롭지 않게 넘겼기 때문입니다.
"전 세계적 대응 조율"의 첫 문장이 "수정을 실제로 쓰이게 하려면 예전 릴리스에 맞게 바꿔야 할 수도 있다"인데... 아마 "지원되는 릴리스만"이라는 뜻이겠죠. 수정이 8.2까지만 소급되는데, 8.2는 올해 말까지 보안 지원을 받지만 8.1과 8.0에는 아무것도 없고, PHP 사이트 중에는 7.x는 물론 5.6을 쓰는 곳도 여전히 많으니까요.
보안 지원이 끝난 버전까지 PHP 팀이 패치를 내줄 거라고 기대하지는 않습니다. 하지만 지원은 끝났어도 여전히 널리 쓰이는 릴리스에 맞게 패치를 다시 작업하는 일이야말로 AI가 특히 잘 맞는 작업 같습니다. 훨씬 오래된 사이트를 운영하는 사람들이 수정을 받으려고 PHP까지 업그레이드하는 대신 그냥 PHP를 패치할 수 있다면 좋았을 겁니다.
7.x 버전은 수리 씨 덕분에 패치가 나왔습니다. 공식 지원 버전 패치와 거의 같은 속도였어요.