Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 글은 PHP 보안 패치와 관련된 엠바고(Embargo) 관리의 어려움과 복잡성을 다룹니다. 특히, PoC 영상의 '실수' 공개가 초래한 혼란과, 오픈 소스 프로젝트에서 보안 업데이트를 배포하는 과정의 기술적 난이도를 분석합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 RSS: GeekNews (한국어)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기10월 21일 07:41 UTC, 공동 공개 예정 시각을 6시간 넘게 앞두고 Chainguard가 독단적으로 엠바고를 깨고 수정된 이미지를 배포했다는 건 Chainguard에 매우 불리한 대목임. 공개 직전의 혼란을 감안해도 정당화하기 어려움.
수정된 바이너리를 6시간 먼저 공개한 Chainguard에는 지나치게 비판적인 듯함. 정작 대혼란을 일으킨 건 24시간 넘게 앞서 춤추는 애니메이션 캐릭터가 등장하는 개념 증명(PoC) 영상을 ‘실수로’ 공개한 협력 보안업체였음.
그 때문에 수많은 에이전트가 PHP 코드베이스를 뒤지고 무차별적으로 PoC를 만들려 달려들었고, 어지간한 국가보다 많은 에너지를 썼을지도 모름.
Chainguard의 입장도 어느 정도 이해됨. 엠바고에 참여하고 있었지만 실제 공격이 이미 발생하는 걸 보고 수정을 더 묶어두지 않기로 한 것임.
엠바고는 아직 악용되지 않을 때 의미가 있으며, 이미 실제 공격에 쓰이고 있다면 최대한 빨리 배포하는 편이 최선임.
다른 답글에 링크된 해명이 사실이라면 크게 비난할 일은 아님. 보통 조기 유출이나 실제 악용이 발생하면 엠바고는 끝남. 실제 공격의 증거를 봤다면 수정본을 공개하는 건 전혀 이례적이지 않음.
우선 엠바고 해제 시점에 Docker 이미지를 제공할 수 있어야 함. 벌써 2시간이 지났는데도 아직 이미지가 없음.
오픈 소스 프로젝트에서는 실제로 꽤 어려운 일이어서 이해가 됨. 소스 코드가 공개되어 있으니 커밋하거나 푸시하면 정보가 새고, 빌드 파이프라인도 공개되어 있을 가능성이 커서 다른 소스를 가져와 빌드하기도 어려움.
비공개 저장소를 만들면 비공개 빌드 시스템도 마련해야 함. 비공개 저장소에는 공개 저장소만큼 넉넉한 빌드 자원이 제공되지 않아, 돈을 내거나 빌드를 필수 요소만 남겨 단순화해야 함. 자금이 넉넉하지 않으면 대개 후자를 택하게 됨.
결국 서로 조금씩 다른 두 시스템을 유지보수하고, 정해진 시각에 비공개 시스템의 산출물을 공개 시스템으로 옮겨야 함. 부족한 빌드 자원이나 드물게 실행하는 절차의 오류로 지연되면 공개 시각을 지키지 않았다고 비난받게 됨. 이미지 증명(attestation)까지 사용한다면 더 복잡해짐.
몇 주에서 몇 달씩 엠바고를 유지하면서 유출되지 않길 바라는 것은 너무 순진함. 보안 수정 사항을 미리 전달받는 건 엄청난 특권이며, 그런 정보를 받은 조직은 빠르게 대응해야 함.
업데이트에 주는 시간은 길어야 며칠이면 충분하다고 봄. 나머지 세상이 계속 기다려줄 수는 없음.
이런 상황에서는 이미지를 직접 빌드하는 능력이 기본이라는 걸 오늘 배웠음. 다행히 Claude Code의 제안 덕분에 미리 준비해뒀음.
그 이미지는 Docker가 운영하는 것 아닌가? PHP Foundation에 책임을 물을 수는 없음.
PHP Foundation이 직접 관리해야 함. Docker의 ‘공식 이미지’ 방식은 취약점 패치에 제대로 대응하지 못하는 게 분명함.
유출과 사전 공지 이후, 취약점을 신고한 보안업체 Calif가 20:00 UTC 무렵 영상을 실수로 공개했다는 부분이 가장 놀라움. Calif가 유출을 보고 엠바고가 깨졌다고 판단해 홍보 영상을 서둘러 올린 것처럼 들림. 춤추는 애니메이션 영상이라니, 훨씬 나은 대응을 기대했음.
실수로 공개했다고? 마우스 위로 넘어지는 바람에 화면 녹화를 켜고, 공격을 몇 차례 실행하고, 애니메이션 캐릭터와 음악을 구해 Premiere에 넣고, 효과를 추가한 뒤 렌더링해서 Twitter에 올리기까지 했다는 듯한 표현임. 참 대단한 실수임.
홍보·마케팅 업체들은 겉으로 뭐라고 하든 실제로는 정확히 이런 식으로 움직임.
이건 춤추는 애니메이션 소녀 영상과는 다른 것 아닌가?
Calif는 영상을 ‘실수로’ 공개했고, Chainguard는 독단적으로 엠바고를 깼다고 함. 규칙을 어겨도 불이익이 없다면 계속 같은 일이 반복될 것임.
4chan도 24시간 넘게 서비스를 내려둔 상태라는 게 흥미로움. 그쪽도 책임감 있게 대응하고 있음.
PHP가 C로 작성되어 있는 한 안전하지 않을 것임. 진부하게 들리겠지만 Rust나 다른 메모리 안전 언어로 다시 작성해야 함.
아직도 PHP를 쓰는 이유를 모르겠음. 에이전트가 Rust나 Go를 바로 사용하면 성능상 이점도 얻을 수 있음.
PHP 보안팀이 유출 이후 등장한 PoC를 면밀히 조사했지만 공식 공개 시점까지 작동하는 공격 코드는 발견하지 못했다고 함. 그렇다면 작동하기까지 얼마나 남은 상태였나? 집요한 공격자가 LLM 등을 활용하면 실제 공격 코드로 완성할 수 있을 만큼 근접했는지 궁금함.
예정된 공개 시각인 14:00 UTC보다 약 4시간 먼저 PHP가 공격당한 사례를 알고 있음. 돌아다니던 공격 코드가 세션 버그를 이용했음. 나도 사이버 보안 사정에 아주 밝은 편은 아님.
엠바고를 어기면 어떤 불이익이 있나? 이후에는 패치를 미리 전달하지 않는 건가?
다른 프로젝트들이 Chainguard에 패치를 사전 공유할지 재고하게 될 수 있음.
합의제로 운영되는 PHP 보안팀이 수정안 사이에서 결정을 내리지 못하고 잘못된 선택의 파장을 우려했다는 부분이야말로 핵심임. 호환성을 깨는 수정안을 배포하고, 다른 수정안으로 전환할 수 있도록 —fuck-my-shit-up 같은 컴파일 시점 옵션을 제공하면 됨.