더 빨리 허점을 찾아내는 AI

11월 4일 OpenAI는 Android 휴대폰, 클라우드 인프라, 슈퍼컴퓨터의 기반이 되는 소프트웨어인 Linux 커널을 대상으로 AI 에이전트를 돌린 작업을 소개했습니다. 10월 중순부터 약 열흘 동안 에이전트들은 서로 다른 948개 결함에 대해 실제로 작동하는 익스플로잇을 만들어 냈습니다. 각각은 일반 사용자 계정을 머신 전체에 대한 완전한 통제권으로 바꿀 수 있는 결함이었고, 에이전트는 그 모두에 대해 패치 후보를 작성했습니다. 그보다 일주일 앞서 Google은 Gemini 4 Carbon을 발표하고 이를 검증된 사이버 방어자에게 먼저 제공했습니다. 결함이 존재하는 시점과 누군가 그것을 찾아내는 시점 사이의 시간이 줄어들고 있으며, AI 연구소들은 방어자가 먼저 도달하기를 원합니다.

OpenAI가 돌린 것

파이프라인은 다섯 단계로 이루어졌고, OpenAI가 11월 5일 GPT-6 Cyber라는 이름으로 공개한 사이버 모델에서 실행되었습니다. 정찰 에이전트는 감사할 가치가 있는 커널 부분 5'034곳을 골랐으며, 이는 전체 코드의 약 7퍼센트입니다. 분석 에이전트는 12시간 만에 이를 2'308개의 후보 발견으로 바꾸었습니다. 선별 에이전트는 격리된 머신에서 각 발견을 재현하려 했고 약 4분의 3인 1'724개에서 성공했으며, OpenAI에 따르면 잘못된 분석에 근거한 발견은 3.1퍼센트에 불과했습니다. 이후 단계에서는 어떤 결함이 실제로 악용될 수 있는지 테스트하고 패치를 작성했으며, 무엇이든 보고하기 전에 사람이 결과를 검토했습니다.

이 작업에는 API 크레딧으로 1'213'430달러, 익스플로잇당 약 1'279달러가 들었습니다. 대상은 일반적인 보호 기능을 켠 표준 데스크톱 Linux였습니다. 7월에 이전 모델 GPT-5.6 Sol로 진행한 작업에서는 이런 결함이 166개 발견되었습니다. 그 사이 석 달 동안 커널이 강화되었는데도, 새 모델은 다섯 배가 넘는 결함을 찾아냈습니다.

연구소들이 말하는 한계

OpenAI는 어디서 잘못했는지 솔직하게 밝힙니다. 초기 실행에서 파이프라인은 200건의 익스플로잇 성공을 보고했는데, 사람이 검토해 보니 그중 20건은 배정된 결함이 아닌 또 다른 미지의 결함을 통해 완전한 통제권에 도달한 것이었습니다. OpenAI는 “이는 에이전트의 익스플로잇이 성공한 경우에도 적절한 검증이 필요하다는 것을 시사한다”고 썼고, 각 익스플로잇이 배정된 결함을 사용했는지 확인하는 독립적인 검사를 추가했습니다. 그 교훈은 모든 자동화된 작업에 해당합니다. “결과 자체를 검증하는 것에 더해 결과에 이른 경로도 검증하라.”

패치에도 손이 필요했습니다. 초기 패치는 작동은 했지만 때로 불필요한 코드를 덧붙이거나, 해당 코드의 관례를 무시하거나, 같은 결함의 변형을 놓쳤고, 더 많은 지시와 반복을 거친 뒤에야 나아졌습니다. OpenAI는 비용 수치를 “상한에 가깝다”고 표현합니다. 이 수치는 모두 OpenAI 자체의 것입니다. 11월 5일까지 저희는 이에 대한 독립적인 감사도, 이번 건에 대한 커널 메인테이너들의 공개 입장도 찾지 못했습니다.

방어자가 먼저

10월 28일 Google의 발표도 같은 패턴을 따릅니다. Google은 Gemini 4 Carbon을 “최첨단 사이버보안 능력과 장기 과제 수행 능력을 갖춘 가장 강력한 모델”이라고 부르며, 결함을 찾는 SEC-bench Pro에서 88.2퍼센트, ExploitGym에서 54.8퍼센트, 패치를 다루는 CWE-bench에서 71.0퍼센트를 보고합니다. 모두 가드레일 없이 측정한 Google 자체 수치입니다. 접근은 일부 사이버 방어자부터 시작해 Fairwind Program을 통해 단계적으로 넓어지며, SecurityWeek에 따르면 이 프로그램에는 정부와 핵심 인프라 운영사를 포함해 650곳이 넘는 참여자가 있습니다. 개발자, 기업, 소비자를 위한 출시는 날짜 없이 “가능한 한 빨리”라고만 약속되어 있습니다.

Anthropic은 4월 Mythos로 이 패턴을 만들었고, OpenAI도 이를 따릅니다. GPT-6 Cyber는 승인된 보안 테스트를 위한 프로그램 Daybreak Red의 엄선된 승인 고객에게 먼저 제공되며, OpenAI는 자체 Preparedness Framework에 따라 이 모델을 사이버보안 Critical 등급으로 평가합니다. 발표문은 그 이유를 이렇게 밝힙니다. “프런티어 모델을 활용해 소프트웨어를 안전하게 만들 수 있는 시간이 한정되어 있다는 것은 분명합니다.”

메인테이너의 입장

모든 발견은 그것을 고쳐야 하는 누군가에게 도착합니다. 3월 커널의 선임 메인테이너 Greg Kroah-Hartman은 The Register에 AI로 작성된 보고서가 약 한 달 전부터 쓰레기에서 진짜로 바뀌었다고 말했습니다. “이제는 진짜 보고서가 옵니다.” 5월 Linus Torvalds는 많은 사람이 같은 도구로 같은 버그를 찾기 때문에 “끊임없이 밀려드는 AI 보고서로 보안 메일링 리스트는 사실상 거의 관리할 수 없는 상태가 되었다”고 썼습니다. 보고자들에게 건넨 그의 조언은 이렇습니다. “AI 도구로 버그를 찾았다면, 다른 누군가도 그것을 찾았을 가능성이 높습니다.” 7월 커널 팀은 일요일과 월요일 단 이틀에 걸쳐 432개의 CVE를 발표했습니다.

OpenAI의 스캔이 진행되는 동안 메인테이너와 다른 기여자들은 이미 같은 결함 상당수를 고치고 있었습니다. 열흘 뒤 61개는 업스트림에서 패치되었고, 43개는 패치가 대기 중이었으며, 299개는 공개적으로 논의되고 있었습니다. OpenAI는 커널 커뮤니티의 지침을 따랐으며 지금까지 패치 후보와 함께 304건의 치명적 발견을 공개했다고 말합니다. 저희가 보기에 이제 부족한 자원은 수정 사항을 검토하고, 테스트하고, 릴리스하는 사람들의 주의력입니다.

기업이 할 수 있는 일

대부분의 기업은 이런 수정 사항을, 흔히 대규모 묶음으로 받는 소프트웨어를 그저 운영할 뿐입니다. OpenAI는 스스로 결론을 내립니다. 당분간 “최신 패치가 적용되지 않은” 시스템의 낮은 권한 계정은 “자원이 풍부한 위협 행위자에게는 기능적으로 루트 권한과 같다고 보아야 합니다.” 저희가 보기에 여기서 네 가지가 따라 나옵니다.

더 빨리 패치하고, 무엇을 운영하는지 파악하십시오. Akamai의 최고 정보보안 아키텍트 Jan Schaumann은 7월에 개별 커널 변경의 우선순위를 정하는 것은 더 이상 가능하지 않다고 썼고, The Register에 대규모 조직에는 어렵더라도 “자동화되고, 정기적이며, 잦은 업데이트”가 유일하게 합리적인 접근으로 보인다고 말했습니다. 이를 위해서는 모든 서버, 기기, 서비스, 그리고 각각을 누가 업데이트하는지에 대한 최신 목록이 필요합니다.

패치가 빠른 공급업체를 선택하고, 치명적인 수정 사항이 귀사에 도달하기까지 얼마나 걸리는지 물으십시오. 소프트웨어 공급업체에 이런 모델을 어떻게 사용하는지 물으십시오. 자체 코드를 스캔하는지, 모델이 보고하는 내용을 어떻게 검증하는지, Daybreak나 Fairwind 같은 프로그램에 참여하는지입니다.

민감한 데이터는 직접 통제하는 시스템에 두고 역할에 따라 접근을 제한하여, 다른 누군가의 서비스에 결함이 있을 때 노출되는 것을 줄이십시오. 통제한다고 해서 패치 의무가 사라지지는 않습니다. 그 의무가 귀사의 것이 될 뿐입니다. OpenAI는 무언가가 악용되었을 때 피해를 제한하기 위해 샌드박스와 격리도 권장합니다.

저희의 입장

저희는 보안 스캐너를 만들지 않습니다. 저희의 몫은 그 목록의 마지막 항목입니다. 이미 제공 중인 Twin은 회사의 어시스턴트에게 역할별 접근 권한을 갖춘 하나의 두뇌를 주며, 모든 쓰기 작업은 사용자별 로그인으로 이루어지고 모든 단계가 기록됩니다. 호스팅은 스위스, EU, 미국 또는 회사 자체 하드웨어에서 이루어집니다. 얼리 액세스 단계이며 저희 파트너 Eigna Labs가 만든 Eigna는 회사의 자체 클라우드나 자체 서버에서 실행되는 프라이빗 모델로, 폐쇄망에서 오프라인으로 실행되도록 설계되었습니다. 회사가 운영하는 다른 모든 것과 마찬가지로, 두 제품 모두 최신 상태로 유지해야 합니다.