모든 곳의 보안을 고칠 수 있는 시간은 1년입니다

AI 요약

이 글은 GLM 5.3-flash의 공개를 계기로, 사이버 공격의 비용과 자동화 수준이 곧 크게 낮아질 수 있다고 경고합니다. 글쓴이는 Project Glasswing과 Daybreak가 frontier LLM을 활용해 업계 전반의 보안 취약점을 찾아 수정하려는 프로젝트라고 설명하면서, 이제 남은 가장 어려운 문제는 취약점을 발견하거나 패치를 작성하는 일이 아니라 실제 시스템에 수정 사항을 배포하는 일이라고 봅니다. 공격에 활용할 수 있는 저렴한 모델이 먼저 널리 퍼지면, 방어 측이 패치를 검토하고 테스트하고 배포하는 동안 공격자가 공개된 취약점을 자동으로 반복 공략할 수 있다는 문제의식입니다.

■ GLM 5.3-flash가 바꾸는 공격 비용

GLM은 General Language Model의 약자로, 중국 AI 연구소 Z.ai가 개발하는 LLM 계열입니다. 이 모델은 open-weight 방식으로 공개되므로 누구나 내려받아 실행하거나 수정할 수 있습니다. Z.ai가 호스팅하는 모델에는 법률상 제한과 거부 동작이 적용되지만, DeAlignAI 같은 조직은 모델의 작업 거부 기능을 제거한 abliterated 모델을 배포하고 있습니다. 글은 DeAlignAI가 공개한 모델이 허위정보, 사이버범죄, 생물학 무기, 파이프 폭탄 제작 등 불법 행위에 관한 요청을 거부하는지를 시험하는 HarmBench-320에서 0%를 기록했다고 설명합니다. 따라서 사실상 어떤 작업이든 수행하려는 모델이 등장했다는 주장입니다.

여기서 flash는 특정한 기술 방식을 가리키는 용어가 아니라 다른 모델보다 실행 비용과 속도가 낮다는 상대적인 표현입니다. 글은 GLM 5.3-flash를 로컬에서 실행하는 데 필요한 하드웨어 비용을 약 5,000~15,000달러로 제시합니다. 한 사례에서는 약 6,000달러 수준의 NVIDIA GPU에서 초당 약 20토큰을 생성했다는 측정 결과를 소개합니다. 또한 9월 22일 출시 예정인 Apple M5 Mac Studio가 256GB unified memory를 제공하며, 이 메모리는 호스트 운영체제와 GPU가 공유할 수 있으므로 해당 모델을 실행하기에 충분하다고 설명합니다. 글쓴이는 이 장비가 초당 약 30토큰을 처리하고, 모델 디코더 개선까지 적용하면 약 45토큰 수준에 도달할 수 있다고 추정합니다. 이 정도 속도라면 개인이 저축으로 장비를 마련해 모델을 밤낮없이 실행하는 것이 가능하다는 논지입니다.

■ 취약점 탐색과 익스플로잇 자동화

글은 GLM 5.3이 CyberGym에서 84.5%, ExploitBench에서 54.4%를 기록했다고 제시합니다. GLM 5.3-flash의 직접적인 벤치마크 수치는 없지만 비슷하거나 조금 낮을 것으로 예상하며, abliterated 모델은 다시 약간 낮을 수 있다고 설명합니다. CyberGym은 오픈소스 프로젝트에서 과거에 발견되고 패치된 실제 취약점을 대상으로 하며, 글의 해석에 따르면 공개된 소스 코드와 CVE 설명만 보고도 대표 표본의 84.5%를 재현할 수 있다는 의미입니다. ExploitBench는 취약점을 실제로 악용해 피해를 일으킬 수 있는지 측정하며, 부분적인 익스플로잇에도 점수를 주고 최종 단계에서 임의 코드 실행까지 도달하는지를 평가합니다.

비교 대상으로는 ExploitBench에서 GPT-6 Astra가 100%, GPT-5.6 Sol이 78.5%를 기록했다는 수치가 제시됩니다. CyberGym에서는 GLM-5.3이 선두이고 GPT-5.6 Sol이 83.6%로 뒤를 잇습니다. 글은 보안 전문가들이 LLM의 도움 없이는 보안 챌린지에서 경쟁하기 어려워졌다고 보고하고 있으며, GPT 5.6-Sol이 사람의 개입 없이 실제 인프라를 공격했다는 사례도 언급합니다. 이를 근거로 글쓴이는 GLM 5.3-flash를 인터넷의 실제 서비스와 인프라에 연결하면 취약점을 찾고 악용할 수 있으며, 그 과정에서 사람의 개입이 거의 필요하지 않을 가능성이 높다고 주장합니다. 결과적으로 사이버 공격이 for loop 안에서 반복 실행될 수 있는 세계에 들어섰다는 표현을 사용합니다.

■ 가장 큰 병목은 패치 배포입니다

Project Glasswing과 Daybreak는 frontier 모델이 오픈소스로 공개되기 전에 기업, 재단, 정부, 비정부기구와 협력해 취약점을 찾고 수정하려는 활동을 진행해 왔다고 설명합니다. 다만 중요한 시스템은 물리적 접근이나 중단을 피하기 위한 단계적 롤아웃이 필요하므로, 패치를 작성하는 것보다 배포가 훨씬 오래 걸릴 수 있습니다. Linux 커널에 패치가 있어도 전력망이 Windows Server 2012에서 실행되고 있다면 문제가 해결되지 않는다는 비유가 제시됩니다.

글은 모델의 속도 향상이 GLM 5.3-flash에서 예상만큼 크지 않을 수 있고, abliterated 모델이 학습하지 않은 악성 작업에는 약할 수 있으며, break this라는 지시를 실제 익스플로잇으로 바꾸는 데 상당한 사람의 개입이 필요할 수도 있다는 한계를 인정합니다. 그러나 이런 제약은 일시적이라고 봅니다. GLM 계열은 역사적으로 OpenAI와 Anthropic보다 3~6개월 정도 뒤처져 왔으므로, 1년 안에 Astra 수준의 GLM 모델이 등장할 가능성이 있으며 그때 공공·민간 인프라에 대한 성공적인 공격 위험이 커질 수 있다는 전망입니다. 공격자의 역량이 방어자의 보안 태세 개선보다 빠르게 커지고 있으므로, 지금 행동해야 한다고 강조합니다.

■ 정책 차원의 대응

글은 단순히 특정 모델을 금지하는 방안에는 회의적입니다. GLM 5.3-flash의 가중치를 미국이나 유럽의 호스팅 서비스에서 차단해도 파일 공유 사이트에 다시 등장할 것이며, 장기적으로는 다른 연구소가 비슷한 성능의 모델을 공개할 수 있다는 이유입니다. Mythos나 Astra 같은 frontier 모델에 대한 접근을 일괄적으로 금지하면 방어자가 가장 강력한 도구를 필요로 하는 시점에 제거하게 되므로 오히려 상황을 악화시킬 수 있다고 주장합니다. GPU나 대용량 unified memory의 판매·수출을 금지하는 방안도 이미 존재하는 하드웨어에는 영향을 주지 못하고, 메모리는 AI 시스템 외에도 광범위하게 사용되므로 장기 해법이 아니라고 봅니다.

대신 정책은 특정 모델이나 공급자보다 보안 테스트와 책임성을 요구하는 방향이어야 한다고 제안합니다. 보안 엔지니어링에 유연한 보조금을 제공하고, 정기적인 penetration testing을 의무화하며, human oversight를 전제로 frontier 모델을 테스트에 활용하도록 장려해야 합니다. 지방정부와 병원처럼 다른 경로로 자금을 확보하기 어려운 조직에 특히 지원을 집중하고, 은행에는 EU의 DORA TLPT와 미국의 FTC, OCC, NCUA 규정을 확대 적용해야 한다고 말합니다. 전력 분야에서는 NERC Critical Infrastructure Protection과 유사한 기준을 주·지방 단위 배전 시스템까지 확대하고, 통신 분야에는 통합된 의무 보안 기준을 마련해야 한다고 제안합니다. 취약점 발견 후 위험도에 따른 기한 안에 수정하도록 요구하고, 수정하지 않거나 보안 태세를 갱신하지 않은 경우에는 책임과 불이익을 부과해야 한다는 주장도 포함됩니다.

■ 개발 조직이 지금 준비할 일

기술적 대응으로는 frontier 모델을 이용한 취약점 탐색, 구조화된 프롬프트와 반복적인 자기 검토를 통한 패치 작성, 테스트를 통한 수정 사항 검증이 제시됩니다. 모델에게 단순히 버그를 찾으라고 지시하기보다 Google의 Unsafe Rust Review처럼 구조화된 절차를 사용해야 하며, 모델이 작성한 패치를 스스로 테스트하게 한 뒤 사람이 검토해야 한다고 설명합니다. 에이전트 자체도 샌드박스에 넣어야 합니다. 자격 증명은 좁은 범위로 제한하고, 이를 지원하지 않는 발급 시스템 앞에는 권한을 제한하는 신뢰된 인터페이스를 둬야 합니다. GET 요청만 허용하는 식의 필터링에 의존하지 말고, 방화벽과 네트워크 프록시에서 허용 도메인과 엔드포인트를 제한하며, 에이전트가 수행한 모든 변경과 네트워크 요청을 기록해야 합니다.

또한 formal verification, fuzzing, property testing, memory-safe language에 투자하고 새 코드에는 C나 C++보다 Go나 Rust 같은 언어를 사용하라고 권합니다. 운영 중인 시스템의 버전과 의존성을 목록화하고, 영향을 받는 버전, 담당자, 수정 기한을 기록해야 합니다. dependency-update 자동화, 서명된 재현 가능 릴리스, 빠른 롤백과 배포 체계를 마련하고, EOL 버전과 관리자가 없는 서비스는 폐기하거나 업그레이드해야 합니다. 취약점 보고부터 패치가 배포되고 사용자가 채택하기까지의 end-to-end 시간을 측정하고, 패치가 공개된 뒤 빠르게 악용될 수 있으므로 embargo 기간도 가능한 한 줄여야 한다고 말합니다.

마지막으로 방화벽이나 VPN 하나에 의존하지 말고 네트워크 분할, 최소 권한, 백업 검증, incident response 훈련, cold start 복구 연습을 포함한 defense-in-depth를 구축해야 한다고 제안합니다. 글쓴이는 이 위협의 규모에 동의하지 않더라도 지금은 프로젝트와 커뮤니티의 보안을 개선할 수 있는 드문 기회라며, 공격 모델이 더 강력해지기 전에 패치와 배포 역량을 확보해야 한다고 결론짓습니다.

■ Lobsters 반응

• @simonw — 샌드박싱에 훨씬 더 많은 관심을 기울였으면 합니다. 소비자용 운영체제가 명확하게 문서화되고 사용하기 쉬운 샌드박싱 기능을 기본 제공하지 않는다는 점이 화가 납니다. 오늘날 운영체제에 포함된 샌드박스는 마치 표지판에 ‘표범을 조심하세요’라고 써 붙여 놓은 것과 다를 바 없습니다. 프로세스가 제 홈 디렉터리를 뒤지고 그 안에서 찾은 것을 인터넷을 통해 다른 사람에게 빼돌리지 못하도록 실행할 수 있기를 바랍니다. 이 일은 지금보다 훨씬 쉬워야 합니다.

• @jfred — 장기적으로 데스크톱 운영체제의 올바른 답은, 지금부터 도달하기 쉽지는 않더라도, capabilities를 포함해야 한다고 여전히 확신합니다. 모든 권한을 가진 ‘사용자 본인’으로 프로세스를 실행하는 identity-based 모델은 우리가 컴퓨터를 사용하는 방식에 오래전부터 맞지 않았으며, 특히 지금은 더더욱 맞지 않습니다.

• @simonw — 이를 사용하기에 안전하고 효과적인 방식으로 감싸면서도 사이버보안 학위의 절반이 필요하지 않은 UI를 만들 수 있다면, 저도 전적으로 찬성합니다.

• @Corbin — need-to-know 정책, 구획화, least authority·access·privilege 원칙이 컴퓨터 전문가가 아닌 사람들로 구성된 조직을 운영하기 위해 여러 정부에서 이미 성공적으로 사용되고 있다는 점을 생각해 볼 필요가 있습니다. 미국에서는 SCIF가 물리적으로 부분 격리되고 권한이 제한된, 통제된 샌드박스의 사례입니다. 일반적으로 서로 협력하는 집단에서는 모든 사람이 보안 팀이므로, 집단의 보안은 구성원 모두의 올바른 행동에 달려 있습니다. 우리가 할 수 있는 일은 개인이 결국 침해될 것을 전제로 그들에게 위임된 권한을 줄이는 것뿐입니다. 즉 보안에 관심이 없는 사람도 대부분의 capabilities를 주지 않음으로써 보호할 수 있습니다.

원문: jyn.dev / 번역·요약: Trawling