Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 기사는 주요 소프트웨어 취약점에 대응하기 위한 글로벌 공조 체계를 제안합니다. 패치 적용 과정에는 단순한 수정 외에도 사전 준비, 배포업체 완화책 마련, 정부 차원의 지침 전달 등 다단계의 협력이 필요함을 강조합니다. 특히 정보 공유와 공개 일정 결정 시 위험 대비 보호 효과를 신중하게 고려해야 합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기이번 결함들은 이미 발견해 수정 중인 여러 주요 취약점 중 일부이며, OpenAI는 향후 수개월 동안 유사한 발견이 급증할 것으로 예상함
유지관리자 중심의 5단계 공조 체계
취약점 대응은 패치 작성만으로 끝나지 않으며, 구버전 패치 적용, 제공업체의 완화책 준비, 여러 조직의 시스템 업데이트까지 필요함
연구자와 유지관리자가 직접 해결할 수 있는 사안도 있지만, 여러 제품에 영향을 주거나 배포업체와 서비스 제공업체에 준비 시간이 필요한 사안은 더 넓은 공조가 필요함
프런티어 모델과 널리 이용 가능한 모델의 역량 차이가 작다면 준비할 시간이 부족할 수 있음
제안한 체계는 다음 5단계로 구성됨
업스트림 취약점 검증과 수정: 유지관리자, 연구자, 필수 기술 파트너가 발견 내용을 확인하고 영향을 평가한 뒤 패치를 개발하고 시험함. 프런티어 모델을 활용한 적대적 테스트로 패치 우회와 관련 변종도 찾음
영향받는 조직의 대응 시간 확보: 유지관리자가 사전 참여 대상을 결정하고, OpenAI는 연락, 정보 공유 협약, 팀 간 조율을 지원함. 배포업체의 구버전 패치 적용, 호스팅업체의 완화책 시험, 보안업체의 탐지 및 예방 조치와 웹 애플리케이션 방화벽(WAF) 규칙 준비 등이 해당함
정부와 핵심 시스템 보호 공조: 정부 기관은 광범위한 대응을 조율하고 핵심 인프라와 필수 서비스 운영 조직에 지침을 전달함. PHP 대응에서는 미국 백악관의 Super Intelligence Force, Office of the National Cyber Director(ONCD), Cybersecurity and Infrastructure Security Agency(CISA), 국제 파트너들과 협력함
영향받는 제품 전반의 업데이트 준비: 수정 사항과 지침, 공개 계획이 안정되면 추가 배포업체, 호스팅 및 서비스 제공업체, 대응팀, 운영자를 참여시켜 업데이트와 보호 공백 해소를 준비함
패치 제공 후 지침 공개와 배포 지원: 노출 여부 평가, 공식 업데이트나 임시 완화책 확인, 수정 버전 실행 여부 점검을 돕고, 운영자의 배포 및 지원 요청에 계속 대응함
사전 정보 공유와 공개 일정의 판단 기준
사전 통지 대상은 자체 시스템과 고객을 보호하는 조직의 역할, 대응에 필요한 시간, 민감 정보를 다룰 능력을 고려해 판단함
비교 가능한 조직에는 같은 기준을 적용하며, 공개 전 참여 대상의 최종 결정은 유지관리자가 맡음
참여자는 보호 작업에 필요한 정보를 받음
침해 지표가 포함된 네트워크 로그부터 더 민감한 실제 작동하는 개념 증명 익스플로잇까지 범위가 달라질 수 있음
제한된 정보도 취약점을 드러낼 수 있으므로, 공유 위험과 가능한 보호 효과를 함께 따져야 함
방어자가 준비할 시간을 확보하되, 실제 공격에서의 악용이나 정보 유출이 발생하거나 공개 패치가 취약점을 드러내거나 조치 지연으로 사용자 위험이 증가하면 일정을 재평가함
운영자의 패치 적용과 위험 기반 우선순위
Patch the Planet 웹사이트는 공개된 취약점과 대응 지침을 모아 영향받는 시스템 식별, 적절한 업데이트 선택, 업데이트된 소프트웨어의 정상 실행 확인을 지원함
PHP에 대해서는 유지관리자의 공식 패치 및 업그레이드 지침과 파트너의 기술 연구로 연결함
결국 이들 때문에 시스템이 한 달 넘게 취약한 채로 남아 있었고, 선택받은 일부만 패치에 접근할 수 있었던 셈임. 이럴 바에는 사전 조율 없이 취약점을 바로 공개하는 편을 지지함. 적어도 패치를 먼저 받는 특권층은 만들지 않기 때문임.
우리가 만든 위험은 제품을 쓰지 않는 이들에게까지 피해를 주지만, 큰돈을 내면 해결을 시도해 주겠다는 식임. 위험한 기술은 최대한 빨리 출시하면서, 막을 수 있는 건 우리뿐이고 시간이 없으니 안전장치 비용을 내라고 재촉함. 결국 불안을 팔아 토큰을 판매하는 구조 아닌가?
그건 취약점을 찾아 보수를 받으려는 화이트햇 보안 연구자에게 발견된 모든 버그의 책임을 돌리는 것과 같음. 전문 연구자가 없던 시절에는 발견되는 취약점도 훨씬 적었음.
취약점은 이미 존재하며 수십 년 된 것도 많음. 우리가 찾거나 더 위험한 누군가가 찾도록 놔두거나 둘 중 하나이니, 전달자를 탓해서는 안 됨. 현실을 부정하기보다는 짧고 집중적인 개선을 거쳐 더 빠른 대응 주기를 정착시키는 편을 선호함.
왜 그렇게 해석하는 건가? 이들이 그 취약점을 만들었나? 수정 비용을 내도록 어떻게 강제했다는 건가?
취약한 코드를 작성한 쪽이나 향후 버전으로 쉽게 호환·이전할 수 없게 언어·프레임워크·SDK를 설계한 쪽이 문제를 만든 것임. 위험한 것을 새로 배포하는 게 아니라, 이미 존재하는 취약점을 공개하는 것임.
최근 LLM을 속일 수 있음을 입증하려고 가짜 통계를 게시한 사람의 글이 있었음. OpenAI도 어차피 이 기술은 등장할 테니 악당들 대신 자신들이 그 형태를 결정해야 한다는 발상에서 출발함. 하지만 다른 악당이 했을 것이라는 가정으로 자신이 실제로 한 행동을 정당화하기는 어려움.
지대 추구 경쟁이 이렇게까지 바닥으로 치달을 줄은 몰랐음. 자기 파괴를 향한 인류의 창의력에는 계속 놀라게 됨.
상위 프로젝트의 수정이 나오기 전 하위 패키지를 고치거나, 보안 지원이 끝난 버전에 수정 사항을 백포트하려면 어떻게 해야 하느냐고 묻고 있음. 마법 같은 코드 생성기를 파는 회사가 같은 소프트웨어의 구버전에 패치를 이식하는 방법을 정말 묻는 건가?
그 코드 생성기가 더 이상 갱신되지 않는 패키지까지 실제로 업데이트할 수 있는 게 아니라면, 코드 생성만으로 해결할 문제는 아님.
보안 지원이 끝난 구버전을 쓰는 곳은 이미 인프라를 관리하지 않는 상태라, 이 도구가 제공하는 새로운 패치 배포 경로로 갈아탈 가능성도 낮음.
기술적으로 고치는 법이 아니라 비기술적인 조직 간 조율을 묻는 것으로 봄. 발견한 버그 자체를 고치는 것과, 공급망 전체에서 어디에 어떻게 배포할지 정하는 것은 다름.
하위 프로젝트에 취약점을 신고했더니 상위 프로젝트에서 고쳐야 한다고 답할 수 있음. 상위 프로젝트에 이슈만 등록하면 될까? 신고를 받고도 대응하지 않았다면, 모든 하위 프로젝트에 연락해 의존성을 교체하거나 패치하도록 하는 편이 해법일 수 있음.
구버전에 맞게 패치를 조정해야 한다고 하지만, 실제로는 지원 중인 구버전만 뜻하는 듯함. PHP 패치는 올해 말까지 보안 지원이 있는 8.2까지만 제공되고 8.1이나 8.0은 빠져 있음. 아직 7.x나 심지어 5.6으로 운영되는 사이트도 많음.
PHP 팀에 지원 종료 버전의 패치까지 기대하지는 않음. 다만 널리 쓰이는 지원 종료 버전에 패치를 이식하는 일은 AI에 특히 잘 맞아 보임. 오래된 사이트도 PHP 자체를 업그레이드하지 않고 보안 패치를 적용할 수 있었다면 좋았을 것임.
Mr Sury 덕분에 7.x용 패치도 있음. 공식 지원 버전의 패치와 거의 같은 속도로 나왔음.
OpenAI는 AI가 모든 일을 한 것처럼 포장하려는 듯하지만, https://calif.io/php2shell/의 설명을 보면 그렇지 않음. 최초 발견에는 특별한 실행 환경이나 비공개 모델을 쓰지 않았고, 연구자가 잘 아는 대상의 취약점 이력과 코드에 대한 가설을 바탕으로 조사했음. 여전히 대상을 깊이 아는 전문성이 핵심이며, 간단한 프롬프트로 모든 버그를 찾아내는 모델은 아직 없음.
LLM의 변종 취약점 분석은 최신의 유명한 버그에서 인접한 오래된 코드로 향하는 경향이 있고, 잘 알려지지 않은 20년 전 공격 기법에서 출발하지는 못함. 연구자가 취약점 이력을 기억하고 있어야 그 방향으로 명시적으로 유도할 수 있음.
글 첫머리부터 Calif가 널리 이용 가능한 모델인 GPT 5.6 Sol을 썼다고 밝힘. 연구자가 “모든 버그를 찾아줘” 이상의 일을 한 건 맞지만, OpenAI도 그 반대를 암시하지는 않음.
순전히 마케팅임. 에이전트의 실제 기술적 성과와 과장된 홍보 문구를 구별하기가 갈수록 어려워져, 지금은 제대로 판단하기 매우 힘든 환경임.
대기업 CEO들은 대중과 투자자, 주주를 상대로 끊임없이 거짓말하고 오도함. 기만에 대한 법 집행이 더는 제대로 이루어지지 않는 게 안타까움.
방어 측에 10억 달러어치 토큰을 지원하겠다고 함. 그 돈을 오픈소스 프로젝트의 품질 보증에 직접 지원해 코드 커버리지 100%를 달성하고 ASAN과 퍼저를 돌리게 하는 편이 더 효과적일 것임. 애초에 모든 것을 가져간 원천이 그 프로젝트들이기도 함. 물론 그렇게 하면 마케팅거리는 없을 것임.
나도 오픈소스 유지관리자로서 답답하지만, 훔쳤다는 표현은 지나침. 세상이 더 나아질 거라는 믿음으로 자부심을 갖고 코드를 공개한 것임.
엄밀히 따지면 직접 지원도 마케팅 아닌가? 또 저작권 무시와 절도는 구분해야 하지 않을까? 누군가에게서 실제로 무엇을 빼앗은 건지 의문임. 누구도 가진 것을 잃지 않았다는 건 불법 복제를 둘러싼 오래된 논리이기도 함.
Patch the Planet은 영화 Hackers의 “Hack the planet” 구호에서 따온 이름이 분명해 보임.
취약점 공격 자체를 이용해 업데이트를 배포한다면 Patch the Planet이라는 이름에 더 어울릴 것임.
여기저기서 미사여구와 마케팅만 쏟아냄. 임시방편으로 대응하는 곳이 많으니, 대응책이 실제로 작동하는지 검증할 코드부터 공개해 주길 바람.