지난 두 달 동안 저희는 유지관리자, 연구자, 보안 업체로 구성된 연합을 이끌며 PHP의 심각한 취약점에 대응했습니다. PHP는 웹사이트와 웹 애플리케이션 구동에 쓰이는 오픈 소스 프로그래밍 언어입니다. Calif는 저희의 Patch the Planet(새 창에서 열기) 이니셔티브의 일환으로 GPT‑5.6 Sol을 사용해 심각한 결함을 발견했으며, Wiz도 독자적으로 두 취약점을 모두 발견하고 보고했습니다. PHP 유지관리자들이 수정과 릴리스를 주도했고, 저희 팀과 Wiz, Cloudflare 등의 파트너들은 연구, 기술 지원, 조율을 통해 취약점 공개 전에 보호 조치를 마련하는 데 기여했습니다.
PHP를 사용하는 조직이 지금 우선해야 할 일은 수정 사항을 적용하는 것입니다. 운영자가 취약점이 있을 수 있는 PHP 버전을 확인하고 PHP 및 서비스 제공업체의 지침을 참고해 필요한 업데이트를 판단할 수 있도록 OpenAI는 PHP 버전 검사기를 Codex 스킬로 공유합니다(새 창에서 열기).
이 결함들의 심각성과 PHP의 광범위한 사용을 고려할 때, 저희는 이번 사안을 근래 가장 파급력이 큰 보안 문제 중 하나로 보고 있습니다. 이는 AI가 인터넷 전반에 영향을 미치는 보안 결함을 찾아낼 수 있음을 보여줍니다. 하지만 같은 역량이 공격자의 공격 도구와 익스플로잇 개발 속도를 높이는 데 쓰일 수도 있습니다.
저희가 파악한 바로는 프런티어 AI가 공격자보다 먼저 이 취약점들을 발견했습니다. 덕분에 유지관리자와 보안 업체는 공개 전에 수정 사항과 보호 조치를 준비할 수 있는 방어자 대응 기간을 확보했습니다.
더 많은 방어자가 이러한 역량을 활용할 수 있도록, 저희는 일선 방어자를 위한 Daybreak를 통해 Daybreak 이용에 10억 달러 규모의 보조금 지원을 약속했습니다. 지원은 제한된 보안 자원으로 필수 서비스를 보호하는 조직에 초점을 맞춥니다.
이 버그들은 매우 심각하지만, 저희가 이미 발견해 수정 중인 여러 중대한 취약점 중 일부일 뿐입니다. 앞으로 몇 달 동안 비슷한 발견이 급증할 것으로 예상합니다. 지금까지의 경험을 바탕으로, 널리 쓰이는 소프트웨어의 심각한 취약점에 대응하기 위한 AI 시대에 맞는 접근법을 제안합니다. 보안 커뮤니티가 이 프레임워크를 개선하는 데 힘을 보태 주시길 바랍니다. 이 접근법은 저희 모델과 보안 전문성, 유지관리자의 역량을 결합해 취약점 발견을 실제 보호 조치로 이어가고, AI 역량의 발전에 맞춰 확장할 수 있는 대응 체계를 구축하도록 돕습니다.
수정 사항을 실제로 적용하려면 이전 릴리스에 맞게 조정하고, 서비스 제공업체의 완화 조치를 준비하며, 여러 조직의 시스템을 업데이트해야 할 수 있습니다. 반복 적용할 수 있는 절차가 있으면 더 많은 취약점이 발견되어도 각 팀이 신속하게 대응할 수 있습니다.
저희는 Patch the Planet을 통해 보안 전문성과 모델 이용 권한을 제공해 PHP 취약점 대응을 지원했고, 유지관리자 및 연구 파트너와 함께 수정 사항을 테스트하고 지침을 마련했습니다. 또한 영향받는 시스템의 보호 조치를 위해 인프라 제공업체와의 조율을 돕고, 정부 사이버 보안 기관과 협력해 주요 조직에 지침이 전달되도록 했습니다. 이러한 노력은 유지관리자가 주도하는 대응을 뒷받침하고 다른 방어자들의 준비를 도왔습니다.
일부 취약점은 연구자가 해당 소프트웨어의 유지관리자와 직접 협력해 조사하고 수정할 수 있습니다. 반면 여러 제품에 영향을 미치거나 배포업체와 서비스 제공업체가 업데이트 및 보호 조치를 준비할 시간이 필요해 더 광범위한 대응을 요구하는 취약점도 있습니다. 프런티어 역량이 널리 이용 가능한 역량보다 크게 앞서 있지 않다면, 준비 시간이 부족할 수도 있습니다. 이런 경우 저희가 제안하는 프레임워크는 유지관리자가 참여 대상을 파악하고 작업을 조율하는 데 도움이 될 수 있습니다. 대응은 다음 다섯 단계로 진행할 수 있습니다.
업스트림 취약점을 검증하고 수정합니다. 유지관리자, 연구자, 필수 기술 파트너가 발견된 취약점을 확인하고, 영향을 평가하며, 수정 사항을 개발하고 테스트합니다. 이 과정에는 프런티어 모델을 활용한 적대적 테스트가 포함됩니다. 이를 통해 패치 우회 방법과 해당 취약점의 관련 변종을 찾아봅니다.
영향받는 조직에 조치할 시간을 줍니다. 저희는 보호 조치를 준비하기 위해 사전 정보가 필요한 조직을 검토하는 프레임워크를 제안하며, 누구를 참여시킬지는 유지관리자가 결정합니다. 저희는 관계자 연락, 정보 공유 협약, 팀 간 조율을 지원합니다. 배포업체는 이전 릴리스에 맞게 수정 사항을 조정하고, 호스팅 업체는 완화 조치를 테스트하며, 보안 업체는 웹 애플리케이션 방화벽(WAF) 규칙을 비롯한 탐지 또는 예방 조치를 준비할 수 있습니다.
정부 파트너와 협력해 중요 시스템을 보호합니다. 정부 기관은 더 광범위한 대응을 조율하고, 핵심 인프라와 기타 필수 서비스를 담당하는 조직에 보안 지침을 전달하는 데 중요한 역할을 합니다. PHP의 경우, 저희는 파트너들과 협력해 백악관 초지능 전담팀(Super Intelligence Force), 국가사이버국장실(ONCD), 사이버보안·인프라보안국(CISA)을 비롯한 미국 정부의 여러 조직 및 국제 파트너들과 협의하며 이러한 노력을 지원했습니다.
영향받는 제품 전반의 업데이트를 준비합니다. 수정 사항, 지침, 공개 계획이 안정적으로 정리되면 유지관리자는 추가 배포업체, 호스팅 및 서비스 제공업체, 대응팀, 운영자를 참여시켜 업데이트를 준비하고 보호 공백을 해소할 수 있습니다.
패치가 준비되면 지침을 공개하고 배포를 지원합니다. 공개 지침은 각자가 위험 노출 수준을 평가하고, 신뢰할 수 있는 업데이트나 임시 완화 조치를 찾으며, 수정 사항이 적용되어 작동 중인지 확인하는 데 도움이 됩니다. 운영자가 업데이트를 배포하고 도움이 필요한 부분을 알리는 동안에도 대응은 계속됩니다.
제안하는 프레임워크는 조직이 자체 시스템과 고객을 보호하는 역할, 조치에 필요한 시간, 민감한 정보를 다룰 역량을 고려합니다. 비슷한 조건의 조직에는 같은 기준을 적용하며, 공개 전에 누구를 참여시킬지는 유지관리자가 결정합니다.
각 참여자는 침해 지표가 포함된 네트워크 로그부터 더 민감한, 실제로 작동하는 개념 증명 익스플로잇까지 보호 업무 수행에 필요한 정보를 받습니다. 제한적인 정보만으로도 취약점이 드러날 수 있으므로, 정보를 공유할 때의 위험과 그로 인해 가능해지는 보호 효과를 비교해 판단합니다.
이 프레임워크를 따르는 팀은 유지관리자와 협력해 방어자에게 준비 시간을 제공합니다. 실제 환경에서 취약점 악용이 진행되거나, 정보가 유출되거나, 공개된 패치가 취약점을 드러내거나, 조치 지연으로 사용자 위험이 커지는 경우에는 일정을 재검토합니다.
Patch the Planet 웹사이트(새 창에서 열기)는 취약점 공개 자료와 지침을 한데 모아, 운영자가 영향받는 시스템을 파악하고 적절한 업데이트를 찾으며 업데이트된 소프트웨어의 정상 작동을 확인하도록 돕습니다. PHP에 대해서는 유지관리자의 공식 패치 및 업그레이드 지침과 파트너들의 기술 연구를 안내합니다. 지침에는 임시 완화 조치, 제공업체나 전문가의 도움을 받아야 할 시점, 백업 및 복구에 관한 내용도 포함됩니다. 임시 보호 조치로 위험을 줄일 수는 있지만, 그 한계와 운영상 감수해야 할 점을 명확히 안내하겠습니다.
운영자는 CISA의 우선순위 설정 및 취약점 조치 지침(새 창에서 열기)을 활용해 노출 수준, 악용 현황, 잠재적 영향에 따라 얼마나 신속하게 조치해야 할지 평가할 수 있습니다. 이에 따라 긴급 패치, 즉각적인 완화 조치, 계획된 업데이트 중 필요한 조치를 취하고, 필요한 경우 포렌식 초기 분석을 병행해 시스템이 이미 침해되었는지 평가할 수 있습니다. 상황이 변하면 우선순위를 재평가하되, 근본적인 해결로 이어지는 명확한 경로를 마련해야 합니다.
전 세계적 공조의 기반은 소프트웨어를 유지관리하는 사람들입니다. 많은 프로젝트는 소규모 팀이 운영하며, 이들은 일상적인 개발 업무와 보안 보고서 검토를 병행합니다. 이 팀들은 새로운 문제와 중복 보고를 구분하고, 영향을 평가하며, 지원 중인 릴리스 전반에서 수정 사항을 테스트하는 데 도움이 필요합니다. 저희는 자금, 고성능 모델 이용 권한, 실무 엔지니어링 지원을 제공해 이러한 작업을 뒷받침합니다.
업계 전반에서 강력한 AI 역량이 발전하고 있으며, 방어자의 취약점 발견, 시스템 모니터링, 위협 대응을 돕는 AI의 역할도 점점 커질 것으로 예상합니다. 저희는 방어자가 이러한 역량을 실제로 활용할 수 있도록 모델, 도구, 파트너십에 투자하고 있습니다.
여기에는 Codex for OSS를 통한 모든 유지관리자 대상 구독 지원과, 유지관리자 및 기술 작업을 지원하기 위한 Rust 재단(새 창에서 열기) 등의 프로젝트 직접 후원이 포함됩니다. 각 프로젝트는 자체적으로 우선순위를 정합니다. 재사용 가능한 테스트와 보안 워크플로를 마련하면 향후 발견되는 취약점을 처리하는 데 드는 노력을 줄일 수 있습니다. 오픈 소스 프로젝트는 Patch the Planet에 신청(새 창에서 열기)해 실무 지원을 받을 수 있습니다.
또한 오용 가능성을 줄이기 위해 Daybreak에 추가할 차단용 분류기를 조정하고 있습니다. 여기에는 어려운 절충이 따릅니다. 악용 방지를 위한 안전장치가 정당한 보안 업무까지 차단할 수 있기 때문입니다. 고성능 모델에 대한 폭넓은 접근성과 효과적인 오용 방지 조치는 모두 중요합니다. 저희의 목표는 방어자가 취약점을 찾고 수정하는 데 필요한 역량을 유지하면서 유해한 사용을 제한하는 것입니다. 역량이 발전하고 이러한 도구의 실제 사용 방식에서 배워 나감에 따라, 그 균형을 계속 다듬어 가겠습니다.
모델의 역량이 높아지면서 개별 취약점을 찾아 수정하는 것 이상의 기회가 열리고 있습니다. 저희는 엔지니어가 처음부터 더 안전한 소프트웨어를 만들 수 있도록 돕고자 합니다. 널리 쓰이는 구성 요소를 개선하면 여러 제품과 서비스 전반에서 버그를 예방하거나 그 영향을 제한할 수 있습니다.
AI는 엔지니어의 기존 코드 이해, 변경 사항 준비, 테스트 개발을 도울 수 있습니다. 유지관리자와 보안 전문가는 이러한 변경 후에도 사용자가 의존하는 동작이 유지되는지 검증합니다. 저희는 다음과 같은 여러 영역에서 가능성을 보고 있습니다.
처음부터 안전한 코드. 코딩 모델은 개발자가 더 안전한 기본 설정을 선택하고, 보안 라이브러리를 올바르게 사용하며, 코드를 작성하는 중에 위험한 패턴을 발견하도록 도울 수 있습니다. 개발 과정에서 취약점을 예방하면 유지관리자와 사용자가 적용해야 할 긴급 수정 사항이 줄어듭니다.
메모리 안전성을 갖춘 소프트웨어. 중요 구성 요소를 메모리 안전성을 보장하는 언어로 전환하면 흔한 유형의 메모리 오류를 제거할 수 있습니다. AI가 마이그레이션을 돕고, 테스트와 전문가 검토로 동작과 호환성을 확인할 수 있습니다.
정형 검증. 수학적 증명을 통해 명시된 가정 아래에서 중요 구성 요소가 지정된 보안 속성을 충족함을 보일 수 있습니다. 이러한 방법을 널리 쓰이는 구성 요소에 적용하면, 이에 의존하는 서비스와 핵심 인프라 전반에서 특정 유형의 취약점을 원천적으로 없애는 데 도움이 될 수 있습니다.
더 강력한 격리. 시스템은 아직 발견되거나 수정되지 않은 취약점으로부터도 보호받아야 합니다. 신뢰할 수 없는 파일, 이미지, 미디어를 처리하는 소프트웨어를 엄격히 제한된 샌드박스에서 실행하면, 침해되더라도 피해를 제한할 수 있습니다. AI는 엔지니어가 널리 쓰이는 샌드박싱 기술을 테스트하고 강화하도록 도와 여러 애플리케이션 전반의 보호 수준을 높일 수 있습니다.
저희가 접근법을 공유하는 이유는 유지관리자, 연구자, 대응팀, 제공업체, 운영자와 함께 이를 실효성 있게 다듬기 위해서입니다. 어디에 도움이 되고, 어디서 지연이나 부담을 늘릴 수 있으며, 저희가 놓친 점은 무엇인지 알고 싶습니다. 과거 취약점 공개 사례를 들려주시면 특히 도움이 됩니다.
특히 다음 사항에 대한 의견을 듣고 싶습니다.
공개 전 준비 기간. 유지관리자, 운영자, 방어자가 신뢰할 수 있는 수정 사항을 준비하고 배포하는 데 어느 정도의 시간이 필요한가요? 특히 일부 사용자를 다른 사용자보다 먼저 보호할 수 있는 상황에서는, 어떤 증거를 근거로 공개 시점을 앞당겨야 할까요?
긴급 패치. 정부나 다른 운영자가 소유하거나 관리 권한을 가진 시스템에 대한 관리자 접근 권한을 잃었을 때, 취약점을 이용해 해당 시스템을 패치해도 되는 경우가 있을까요? 있다면 언제일까요? 어떤 안전장치를 적용해야 할까요? 궁극적으로는 인터넷 전반에서 알려진 취약점을 상시 스캔하고, 취약점이 탐지되면 사이트 소유자에게 알리거나 시스템을 패치하는 모습을 생각해 볼 수 있습니다.
사전 통지. 저희가 놓칠 수 있는 방어자까지 포함해, 실질적인 보호 조치를 취하려면 누구에게 사전 통지가 필요한가요? 더 넓은 대상에 한꺼번에 알리는 것보다 단계적으로 통지하는 편이 나은 경우는 언제이며, 보호 범위와 유출 위험 사이에서 어떻게 균형을 잡아야 할까요?
기본적으로 안전한 소프트웨어 패키지. 업스트림 수정이 완료되기 전에 다운스트림 패키지의 취약점을 찾아 수정하거나, 더 이상 보안 업데이트를 받지 못하는 이전 버전에 수정 사항을 백포트하도록 어떻게 도울 수 있을까요? 적시에 업그레이드하기 어려운 상황에서 이런 패키지가 신뢰할 수 있는 대안이 되려면 어떤 테스트와 유지관리가 필요할까요?
이 접근법을 검토하고, 전제가 타당한지 따져 보며, 미비점을 찾아낼 수 있는 독립적인 보안 전문가 추천도 환영합니다. 여러분의 의견은 대응 방식을 다듬고 지원 우선순위를 정하는 데 도움이 됩니다. 여기에서 의견을 공유해 주세요(새 창에서 열기).
