LLM이 발견하는 제로데이, 커지는 위험을 평가하고 대응하다

Nicholas Carlini^*, Keane Lucas^*, Evyatar Ben Asher^*, Newton Cheng, Hasnain Lakhani, David Forsythe, Kyla Guru
^*동등 기여

오늘 출시된 Claude Opus 4.6은 AI 모델의 사이버보안 역량이 꾸준히 발전해온 흐름을 이어간다. 지난 가을, 우리는 AI가 사이버보안에 미치는 영향이 변곡점에 와 있다고 밝힌 바 있다. 발전 속도가 급격히 빨라질 수 있고, 지금이야말로 AI의 방어적 활용을 가속화할 때라는 판단이었다. 그 이후 쌓인 증거들은 이 견해를 더욱 뒷받침하고 있다. AI 모델이 이제 고위험 취약점을 대규모로 탐지할 수 있는 시대가 됐다. 지금이야말로 빠르게 움직여야 할 때다. 기회가 있는 동안 보안 방어자를 강화하고 최대한 많은 코드를 안전하게 만들어야 한다.

Opus 4.6은 이전 모델들에 비해 고위험 취약점 탐지 능력이 눈에 띄게 향상됐으며, 이는 상황이 얼마나 빠르게 변화하고 있는지를 잘 보여준다. 보안팀들은 수년간 취약점 발견 자동화에 공을 들여왔다. 대규모 버그 탐지를 위해 퍼징(fuzzing) 인프라와 커스텀 하네스에 막대한 투자를 해온 것이다. 그런데 초기 테스트에서 눈에 띈 점은, Opus 4.6이 작업별 전용 툴링이나 커스텀 스캐폴딩, 특수 프롬프팅 없이도 즉시 취약점을 찾아냈다는 것이다. 더 흥미로운 건 취약점을 찾아낸 방식이다. 퍼저는 코드에 무작위 입력값을 대량으로 던져서 어디서 문제가 발생하는지 확인하는 방식으로 작동한다. 반면 Opus 4.6은 사람 연구자처럼 코드를 읽고 추론한다. 과거 수정 내역을 살펴 미처 해결되지 않은 유사 버그를 찾거나, 문제가 될 만한 패턴을 포착하거나, 특정 로직을 충분히 이해해서 어떤 입력이 문제를 일으킬지 정확히 파악하는 식이다. 가장 철저하게 검증된 코드베이스(수년간 퍼저를 돌려 수백만 CPU 시간을 축적한 프로젝트들)를 대상으로 Opus 4.6을 투입했을 때, 수십 년간 발견되지 않았던 것들을 포함해 고위험 취약점들이 드러났다.

균형을 방어자 쪽으로 기울이려면 직접 발 벗고 나서야 한다. 현재 Claude를 활용해 오픈소스 소프트웨어의 취약점을 발견하고 수정을 지원하는 작업을 진행 중이다. 오픈소스부터 시작한 이유는, 기업 시스템에서 핵심 인프라에 이르기까지 어디서나 사용되고 있어 취약점 하나가 인터넷 전반으로 파급되기 때문이다. 이 프로젝트들 중 상당수는 전담 보안 인력이 없는 소규모 팀이나 자원봉사자들이 관리한다. 사람이 직접 검증한 버그를 찾아내고 사람이 검토한 패치를 기여하는 것만으로도 큰 도움이 된다.

지금까지 500개 이상의 고위험 취약점을 발견하고 검증했다. 취약점 보고를 시작했고 초기 패치들이 반영되는 것을 확인하고 있으며, 나머지 취약점 수정을 위해 메인테이너들과 계속 협력 중이다. 이 글에서는 우리의 방법론을 설명하고, Claude가 발견한 취약점의 초기 사례를 공유하며, 역량이 계속 향상되는 가운데 남용을 관리하기 위해 마련한 안전장치를 다룬다. 이는 우리 노력의 시작일 뿐이다. 작업 규모가 커지면 더 많은 내용을 공유할 것이다.

설정

이 작업에서 우리는 Claude를 '가상 머신(virtual machine)'(실제로 시뮬레이션된 컴퓨터)에 올려 최신 버전의 오픈소스 프로젝트에 접근할 수 있도록 했다. 표준 유틸리티(예: coreutils, Python)와 취약점 분석 도구(예: 디버거, 퍼저)를 제공했지만, 이 도구들을 어떻게 사용할지에 대한 특별한 지침은 주지 않았다. 취약점을 더 잘 찾는 방법에 대한 전문 지식을 담은 커스텀 하네스도 제공하지 않았다. 즉, 현대 대형 언어 모델이 사용 가능한 도구를 어떻게 가장 잘 활용할지 스스로 추론할 수 있는 범용 에이전트라는 사실에만 의존해, Claude의 '즉시 사용 가능한' 역량을 직접 테스트한 것이다.

Claude가 버그를 환각(hallucinate)하지 않았음을 확인하기 위해—즉, 존재하지 않는 문제를 지어내는 것으로, 오픈소스 개발자들에게 점점 더 큰 부담을 안기는 문제—보고 전에 모든 버그를 철저히 검증했다. 검증이 상대적으로 용이한 메모리 손상(memory corruption) 취약점 탐색에 집중했다. 프로그램이 정상 작동하는 로직 오류와 달리, 메모리 손상 취약점은 프로그램 충돌을 모니터링하거나 주소 새니타이저(address sanitizer) 같은 도구를 실행해 비충돌 메모리 오류를 잡아내는 방식으로 비교적 쉽게 식별할 수 있다. 그러나 프로그램 충돌을 유발하는 모든 입력이 고위험 취약점인 것은 아니므로, Claude에게 남은 충돌들을 분석하고 중복을 제거하며 우선순위를 재설정하도록 했다. 초기 발견 결과에 대해서는 자체 보안 연구원들이 각 취약점을 직접 검증하고 패치를 수작업으로 작성했다. 발견 건수가 늘어나면서 외부 (사람) 보안 연구원들을 투입해 검증과 패치 개발을 지원받았다. 우리의 목표는 메인테이너들이 보고서를 처리하는 데 실질적으로 도움을 주는 것이었기 때문에, 거짓 양성(false positive)을 줄이는 방향으로 프로세스를 최적화했다. 병행하여, 발견한 버그를 안정적으로 수정할 수 있도록 패치 개발 자동화 작업도 속도를 높이고 있다.

취약점

다음은 Claude가 발견한 취약점 세 가지(현재 메인테이너들이 패치 완료)로, LLM이 다른 도구에 비해 갖는 고유한 강점을 잘 보여준다.

GhostScript는 PostScript 및 PDF 파일을 처리하는 유틸리티다. Claude는 취약점을 찾는 과정에서 처음에는 여러 막다른 길에 부딪혔다. 코드 퍼징을 시도했다가 실패하자 수동 분석을 시도했지만 이 역시 별다른 성과가 없었다. 그러나 결국 Claude는 다른 방법을 택했다. Git 커밋 히스토리를 읽어본 것이다. Claude는 보안과 관련된 커밋을 빠르게 찾아내고 다음과 같이 설명했다:

There's a commit about "stack bounds checking for MM blend values" in Type 1 charstrings. This is related to font handling. Let me get more details about this commit.

이후 Claude는 코드를 살펴보며 무엇이 변경됐는지 파악했다:

The commit shows it's adding stack bounds checking - this suggests there was a vulnerability before this check was added. … If this commit *adds* bounds checking, then the code before this commit was vulnerable … So to trigger the vulnerability, I would need to test against a version of the code *before* this fix was applied.

이를 토대로 Claude는 해당 함수가 호출되는 다른 위치를 찾아 아직 패치되지 않은 유사한 취약점이 있는지 확인했다.

Let me check if maybe the checks are incomplete or there's another code path. Let me look at the other caller in gdevpsfx.c … Aha! This is very interesting! In gdevpsfx.c, the call to gs_type1_blend at line 292 does NOT have the bounds checking that was added in gstype1.c.

이 분석을 바탕으로 Claude는 곧바로 개념 증명(PoC) 충돌을 만들어냈다. GhostScript에 전달하면 충돌을 유발하는 파일을 제작해 예측을 입증한 것이다.

OpenSC는 스마트 카드 데이터를 처리하는 커맨드라인 유틸리티다. 이번에도 Claude는 처음에 코드 퍼징으로 취약점을 찾으려 했고, 실패 후 수동 분석을 시도했다. 앞선 경우와 마찬가지로 이 방법도 효과가 없자, Claude는 다른 접근법을 택했다. 취약점이 자주 발생하는 함수 호출을 저장소에서 검색하기 시작한 것이다.

Let me look at where the URL is used - specifically the strrchr and strcat operations which could potentially have path traversal or buffer overflow issues.

Claude는 strcat 연산이 연속으로 사용된 위치를 빠르게 찾아냈다. 이 함수들은 결합된 문자열의 길이를 확인하지 않고 문자열을 이어붙일 수 있어 C에서 일반적으로 안전하지 않은 것으로 여겨진다. 따라서 출력 버퍼가 이어붙인 입력값을 담기에 충분한 길이인지 프로그래머가 반드시 확인해야 한다. OpenSC에서 핵심 문제는 다음 코드에 있었다:

char filename[PATH_MAX];  // this buffer is 4096 bytes
r = sc_get_cache_dir(card->ctx, filename,
        sizeof(filename) - strlen(fp) - 2);
if (r != SC_SUCCESS)
        goto err;
strcat(filename,"/");
strcat(filename,fp);

Claude는 이 코드가 버퍼 오버플로우(buffer overflow)에 취약하다는 것을 파악했다. 기존 퍼저가 이 코드 라인을 얼마나 자주 퍼징했는지 통계를 살펴보면, 충족해야 할 전제 조건이 많아 전통적인 퍼저로는 거의 분석되지 않았음을 알 수 있다. 반면 Claude는 어떤 코드 조각이 중요한지 추론해 거기에 집중할 수 있었다. 모든 라인을 균등하게 분석하는 대신, 핵심 부분에 역량을 집중한 것이다.

CGIF는 GIF 파일을 처리하는 라이브러리다. 이번 사례에서 우리가 놀란 건 Claude가 버그를 찾아낸 방식이 아니라, 버그를 검증하고 취약점이 실제임을 증명하는 개념 증명을 만들어낸 방식이었다.

간단히 말해, Claude는 이 라이브러리가 압축 데이터가 항상 원본보다 작을 것이라고 가정한다는 점(대부분의 경우 안전한 가정)을 발견했고, 이 가정이 악용될 수 있음을 파악했다. 이를 해내는 과정은 쉽지 않았다. GIF 파일 형식은 LZW 압축 알고리즘으로 데이터를 압축한다. 일치 항목을 (거리, 길이) 쌍으로 인코딩하는 전통적인 LZ77 기반 압축기와 달리, LZW는 자주 사용되는 토큰 쌍(개별 문자 또는 토큰 쌍)의 사전을 구축한다. 이후 압축기가 이 토큰을 다시 만나면, '이 토큰을 다시 출력하라'는 의미의 짧은 비트스트링을 출력할 수 있다. (언어 모델에 익숙한 독자라면, LZW는 개념적으로 BPE 토크나이제이션 과정과 매우 유사하다.)

CGIF는 압축된 문자열의 크기가 항상 비압축 크기보다 작을 것이라고 암묵적으로 가정했는데, 이는 거의 대부분의 경우 사실이다. 그러나 Claude는 여기서 취약점을 즉시 파악했다:

To trigger overflow, we need:

• Small numPixel (small image)
• Many LZW codes written

The pattern that generates most LZW codes is one where:

• No compression happens (each pixel becomes a code)
• Many resets occur

With a palette of 4 colors (indices 0-3):

• initDictLen = 4
• Dictionary fills up after MAX_DICT_LEN (4096) entries
• Reset happens when dict reaches 4096

To trigger overflow with small image:

• numPixel = N
• Buffer size = (N + 2) codes
• We need to generate > N + 1 codes

Each pixel can generate 1 code + resets.

But the pattern that might cause more codes is when we have sequences of length 1.

즉, Claude는 LZW가 고정 크기의 심볼 테이블을 유지한다는 점을 인식했다. 심볼 테이블의 크기를 최대로 채울 수 있다면, LZW는 데이터 스트림에 새로운 특수 '클리어(clear)' 토큰을 삽입한다. 그 결과 출력된 '압축' 크기가 비압축 크기를 초과하게 되어 버퍼 오버플로우 취약점이 발생한다.

이 취약점이 특히 흥미로운 이유는, 이를 발동시키려면 LZW 알고리즘과 GIF 파일 형식의 관계에 대한 개념적 이해가 필요하기 때문이다. 전통적인 퍼저(커버리지 기반 퍼저조차)는 특정 분기를 선택해야 하기 때문에 이런 유형의 취약점을 발동시키는 데 어려움을 겪는다. 실제로 CGIF가 라인 및 분기 커버리지 100%를 달성하더라도 이 취약점은 여전히 발견되지 않을 수 있다. 매우 특정한 순서의 작업이 필요하기 때문이다.

안전장치

Claude Opus 4.6 출시와 함께, Claude의 사이버 악용을 식별하고 대응하는 안전장치팀을 지원하기 위한 새로운 탐지 레이어를 도입한다. 이 작업의 핵심은 프로브(probe)다. 프로브는 모델이 응답을 생성하는 동안 내부 활성화(activation)를 측정해 특정 위해를 대규모로 탐지할 수 있게 한다. 이번 출시와 함께 사이버보안 영역에서 Claude의 잠재적 악용을 더 잘 추적하고 이해하기 위한 사이버 특화 프로브를 새로 개발했다.

집행 측면에서는, 이 새로운 탐지 아키텍처에 맞춰 파이프라인을 발전시키고 있다. 프로브 기반 탐지를 활용하도록 사이버 집행 워크플로우를 업데이트하고, 사이버 악용에 대응하기 위한 조치 범위도 확대하는 작업이 포함된다. 특히 악의적으로 탐지된 트래픽 차단을 포함한 실시간 개입 조치를 시행할 수 있다. 이로 인해 합법적인 연구와 일부 방어 작업에 마찰이 생길 수 있는데, 이런 문제가 발생하면 보안 연구 커뮤니티와 협력해 해결 방안을 찾고 싶다. Claude를 안전하면서도 효과적으로 만들기 위해 끊임없이 노력함으로써, 사이버보안 분야의 최전선에 유지하겠다.

이러한 변화들은 탐지 가능한 내용뿐 아니라 발견한 것에 얼마나 빠르고 효과적으로 대응할 수 있는가 측면에서도 악용 방지 역량이 의미 있게 한 단계 도약했음을 보여준다.

결론

Claude Opus 4.6은 특수 스캐폴딩 없이도 철저히 검증된 코드베이스에서 유의미한 제로데이 취약점을 찾아낼 수 있다. 우리의 결과는 언어 모델이 기존 탐지 도구에 더해 실질적인 가치를 더할 수 있음을 보여준다. 앞서 설명한 안전장치 작업은 이로 인해 발생하는 이중 사용(dual-use) 위험을 관리하는 데 필수적이다.

앞으로 우리와 더 넓은 보안 커뮤니티 모두 불편한 현실과 마주해야 한다. 언어 모델은 이미 새로운 취약점을 식별할 수 있으며, 머지않아 전문 보안 연구원의 속도와 규모를 뛰어넘을 수도 있다.

동시에, 기존의 취약점 공개 규범도 변화해야 한다. 업계 표준인 90일 공개 유예 기간은 LLM이 발견하는 버그의 속도와 규모 앞에서 유효하지 않을 수 있으며, 이에 발맞출 수 있는 워크플로우가 필요해질 것이다.

이 작업은 현재 진행 중이며, 이러한 역량이 어떻게 발전하는지, 보안 커뮤니티가 이를 어떻게 최대한 활용할 수 있는지에 대해 배우고 있는 내용을 포함해 곧 더 많은 것을 공유할 것이다.

2026년 2월 6일 수정:

• 저자 목록 업데이트