Anthropic Mythos가 curl에서 찾은 취약점은 결국 1개였다

Mythos hype, curl 앞에서는 꽤 차분해짐

• Anthropic이 “Mythos가 소스 코드 보안 결함을 너무 잘 찾아서 아직 공개 못 한다”는 식으로 큰 화제를 만든 적이 있음

  • 2026년 4월, Anthropic은 Mythos가 보안 취약점 탐지에 위험할 정도로 좋다고 발표함
  • 그래서 대중 공개 대신 일부 기업과 프로젝트에 먼저 제한적으로 제공하겠다는 흐름이었음
  • curl 리드 개발자 Daniel Stenberg는 Linux Foundation의 Alpha Omega를 통해 이 모델 접근 제안을 받았음

• 다만 실제 접근은 지연됐고, 결국 Mythos 접근 권한이 있는 누군가가 curl을 대신 스캔해 보고서를 보내는 방식으로 진행됨

  • Stenberg는 직접 프롬프트를 이것저것 실험할 시간이 많지 않았기 때문에, 1차 분석 보고서만 받아도 충분하다고 봄
  • 분석 대상은 curl 깃 저장소의 최근 master 커밋, src와 lib 하위 디렉터리였음
  • 보고서는 17만8000줄을 분석했다고 적었음

curl이라는 테스트 대상이 워낙 빡셈

• curl은 그냥 작은 C 프로젝트가 아니라 전 세계 인프라에 깔린 초대형 프로젝트임

  • 빈 줄을 제외하면 현재 C 코드가 약 17만6000줄임
  • 소스 코드 단어 수는 66만 단어로, 영어판 ‘전쟁과 평화’보다 12% 많다고 함
  • 현재 남아 있는 production 코드 기준으로 573명이 작성에 참여했고, 전체로는 1,465명의 변경이 머지됐음

• 설치 규모도 말이 안 됨

  • curl은 200억 개가 넘는 인스턴스에 설치돼 있다고 설명됨
  • 110개 이상 운영체제와 28개 CPU 아키텍처에서 동작함
  • 스마트폰, 태블릿, 자동차, TV, 게임 콘솔, 서버까지 안 들어간 곳 찾기가 더 어려운 급임

• 보안 이력도 이미 굵직함

  • 지금까지 curl에서 공개된 CVE는 188개임
  • 프로젝트는 강한 컴파일러 옵션, 일반 정적 분석기, 퍼징, AI 분석 도구를 계속 돌려왔음
  • 최근 810개월 동안 AISLE, Zeropath, OpenAI Codex Security 같은 AI 도구가 200300개 버그픽스를 유발했고, 그중 10여 개 이상은 CVE로 이어졌다고 함

“확인된 취약점 5개”는 검토 후 1개가 됨

• Mythos 보고서는 처음에 “확인된 보안 취약점” 5개를 제시함

  • Stenberg는 AI가 스스로 “confirmed”라고 부르는 게 좀 웃기다고 봄
  • curl 보안팀이 몇 시간 동안 파고든 뒤 결론은 확 달라짐
  • 5개 중 3개는 문서화된 API 동작을 문제로 본 오탐, 1개는 그냥 버그, 1개만 실제 취약점으로 남음

• 남은 1개 취약점도 대형 사고급은 아님

  • 낮은 심각도의 CVE로 처리될 예정임
  • curl 8.21.0 릴리스가 예정된 6월 말에 맞춰 공개될 계획임
  • 상세 내용은 릴리스 전까지 공개하지 않겠다고 함

• 그렇다고 Mythos 보고서가 쓸모없었다는 얘기는 아님
  • 취약점은 1개였지만, 보안 취약점은 아닌 버그들도 약 20개 정도 설명돼 있었음
  • 설명 품질은 좋았고 오탐도 거의 없었다고 평가함
  • curl은 이 버그들을 하나씩 조사하고 동의하는 것부터 고치는 중임

AI 분석기는 이미 실전 도구지만, 마법은 아님

• Stenberg의 결론은 Mythos hype가 상당 부분 마케팅이었다는 쪽임

  • 적어도 curl에서는 기존 AI 분석 도구보다 압도적으로 더 고급이거나 위험한 수준이라는 증거를 못 봤다고 함
  • 물론 이건 curl이라는 한 저장소에 대한 경험이고, 다른 코드베이스에서는 다를 수 있다고 선을 그음
  • 이미 먼저 돌린 AI 도구들이 쉬운 버그를 많이 제거했기 때문에 후발 도구가 찾을 게 줄어든 것도 감안해야 함

• 그래도 AI 코드 분석기 자체에 대한 평가는 꽤 강하게 긍정적임

  • 전통적인 정적 분석기보다 소스 코드의 보안 결함과 실수를 훨씬 잘 찾는다고 봄
  • 보안 연구자들도 AI를 적극적으로 써서 고품질 리포트를 많이 보내고 있다고 함
  • 프로젝트가 AI 분석을 안 돌린다면, 공격자와 연구자에게 먼저 찾을 시간을 주는 셈이라고까지 말함

• AI 분석기가 다른 점도 구체적으로 짚음

  • 주석이 설명하는 동작과 실제 코드가 어긋나는지 볼 수 있음
  • 직접 분석 환경을 만들기 어려운 플랫폼과 설정 조합도 검토할 수 있음
  • 서드파티 라이브러리 API의 세부 동작을 알고 잘못된 가정을 잡아낼 수 있음
  • curl이 구현하는 프로토콜 규격과 코드가 충돌하는지도 의심할 수 있음
  • 발견한 문제를 설명하고 패치까지 제안할 수 있지만, 패치는 보통 100% 정답은 아니라고 봄

Mythos 보고서의 기술적 디테일도 꽤 흥미로움

• 보고서는 메모리 안전성 취약점을 0개 찾았다고 적음

  • 분석 방식은 자동 SAST가 아니라, LLM 하위 에이전트로 병렬 파일 읽기를 하고 메인 세션에서 직접 소스 확인으로 재검증하는 방식이었다고 설명됨
  • curl의 vuln.json을 바탕으로 CVE 변형 탐색 매핑도 만들었다고 함
  • 즉 “그냥 AI한테 전체 코드 던져봤다”보다는 꽤 구조화된 분석에 가까움

• curl의 방어 인프라도 보고서에 구체적으로 언급됨

  • capped dynbuf, curlx_str_number의 명시적 최대값, curlx_memdup0 오버플로 가드 같은 방어가 언급됨
  • 프로토콜별 응답 크기 제한, 64KB 라인 제한, 포맷 문자열 강제 같은 장치도 생산적인 버그 클래스를 줄였다고 봄
  • 분석 범위에는 minor 프로토콜, 파일 파서, TLS 백엔드 검증 경로, HTTP/1·2·3, FTP, mprintf, x509asn1, DoH, 인증 메커니즘, 콘텐츠 인코딩, 연결 재사용, 세션 캐시, CLI, 플랫폼별 코드, CI·빌드 공급망까지 포함됐다고 함

• 중요한 현실 인식은 “AI가 새로운 종류의 취약점을 창조적으로 발견한 건 아니다”라는 점임

  • 지금까지 AI 도구들은 이미 보안 업계가 아는 기존 오류 유형의 새로운 인스턴스를 찾아내는 쪽에 가깝다고 함
  • 분야를 재발명한다기보다, 기존 도구보다 더 넓고 끈질기게 파내는 느낌임
  • 그리고 AI 도구와 프롬프트 방식은 계속 좋아질 것이므로 curl도 Mythos와 다른 AI 스캔을 반복하고 싶다고 밝힘

---

기술 맥락

• Mythos가 한 일은 전통적인 정적 분석(SAST)을 완전히 대체했다기보다, 코드와 문서, 프로토콜 지식, 과거 CVE 패턴을 같이 읽는 분석에 가까워요. 왜 중요하냐면 curl처럼 플랫폼과 프로토콜 조합이 많은 프로젝트에서는 단순 규칙 기반 도구만으로 맥락을 다 잡기 어렵거든요.

• curl에서 결과가 1개 취약점으로 줄어든 이유는 모델이 약해서만은 아니에요. 이 프로젝트는 이미 OSS-Fuzz, Coverity, CodeQL, 유료 감사, AI 분석을 계속 돌려온 코드베이스라 쉬운 버그가 많이 제거된 상태였어요. 그래서 새 도구가 들어와도 남은 문제는 훨씬 찾기 어려워져요.

• 흥미로운 선택은 AI의 결과를 그대로 믿지 않고 보안팀이 다시 소스 기준으로 검증했다는 점이에요. 보안 취약점은 “모델이 확신함”으로 끝나지 않고, API 문서상 허용된 동작인지, 실제 공격 가능성이 있는지, 일반 버그인지 나눠야 하거든요.

• 개발팀 입장에서는 이게 현실적인 운영 모델이에요. AI 분석기를 CI나 리뷰 흐름에 넣되, 최종 판정은 사람이 하고, 패치 제안도 참고자료로 쓰는 식이에요. 특히 오래된 C/C++ 코드나 프로토콜 구현체라면 이 조합이 꽤 큰 효과를 낼 수 있어요.