Claude Mythos Preview로 Firefox를 강화한 비하인드 스토리

 (hacks.mozilla.org)
5P by GN⁺ | ★ favorite | 댓글 2개
  • Mozilla는 모델 성능 향상과 하네스(harness) 개선으로 AI 생성 보안 보고서의 신호를 높이고 잡음을 줄여, Firefox에서 실제 보안 버그를 대규모로 찾는 파이프라인을 구축함
  • Firefox 150 release에서는 Claude Mythos Preview가 식별한 271개 버그가 수정됐고, 149.0.2, 150.0.1, 150.0.2에도 관련 수정이 포함됨
  • 공개된 대표 버그에는 JIT의 WebAssembly GC 구조체 초기화 제거로 인한 가짜 객체 원시 기능, IPC 경합 조건을 통한 부모 프로세스 UAF, NaN 역직렬화 문제, XSLT의 20년 된 rehash 버그, rowspan=0을 이용한 16비트 레이아웃 bitfield overflow 등이 들어감
  • 공개된 버그 상당수는 샌드박스 탈출이며, 손상된 콘텐츠 프로세스가 권한 있는 부모 프로세스로 권한을 올리는 상황을 전제로 해 퍼징만으로 찾기 어려운 공격 표면을 AI 분석이 더 포괄적으로 다룸
  • Mozilla는 기존 퍼징 인프라 위에 agentic 하네스를 얹어 재현되지 않는 추측을 버리고 테스트케이스로 가설을 검증했으며, 앞으로 패치가 tree에 들어올 때 스캔하도록 지속적 통합에 통합할 계획임

AI 모델로 드러난 Firefox 보안 버그의 변화

  • 몇 달 전까지만 해도 오픈소스 프로젝트에 들어오는 AI 생성 보안 버그 보고서는 그럴듯하지만 틀린 경우가 많아 유지보수자에게 비대칭 비용을 만들었음
  • Firefox에서는 짧은 기간 동안 상황이 크게 바뀌었고, 모델 성능 향상과 모델을 하네스(harness) 로 조종·확장·결합해 신호를 늘리고 잡음을 걸러내는 기법 개선이 핵심 이유였음
  • Mozilla는 보통 보안 권고와 수정 배포 후에도 상세 버그 보고서를 몇 달간 비공개로 유지하지만, 이번에는 생태계 전반의 긴급성과 관심을 고려해 일부 보고서를 공개하기로 결정함
  • 공개된 보고서는 브라우저 여러 하위 시스템에서 고른 것이며 선정은 어느 정도 임의적이지만, 보고서의 깊이와 다양성은 방어자들이 이 기법을 적용해야 할 필요성을 보여줌

공개된 대표 버그

  • 2024918
    • 잘못된 동등성 검사 때문에 JIT가 살아 있는 WebAssembly GC 구조체 초기화를 최적화로 제거했고, 내부·외부 연구자의 광범위한 퍼징을 거친 코드에서 잠재적 임의 읽기·쓰기와 연결되는 가짜 객체 원시 기능을 만들 수 있었음
  • 2024437
    • <legend> 요소의 15년 된 버그로, 재귀 스택 깊이 제한, expando 속성, cycle collection 등 브라우저의 서로 떨어진 영역에 있는 엣지 케이스를 정교하게 조합해 유발됨
  • 2021894
    • IPC 경합 조건을 안정적으로 악용해 손상된 콘텐츠 프로세스가 부모 프로세스의 IndexedDB 참조 카운트를 조작하고, UAF와 잠재적 샌드박스 탈출을 일으킬 수 있었음
  • 2022034
    • 원시 NaN이 IPC 경계를 넘으며 태그된 JS 객체 포인터처럼 보일 수 있어, double 역직렬화가 부모 프로세스 가짜 객체 원시 기능과 샌드박스 탈출로 이어질 수 있었음
  • 2024653
    • 중첩 이벤트 루프, pagehide 리스너, 가비지 컬렉션을 엮은 복잡한 테스트케이스로 <object> 요소의 속성 setter에서 UAF를 유발함
  • 2022733
    • WebTransport에 수천 개의 인증서 해시를 밀어 넣어 참조 카운트가 많은 복사 루프의 경합 조건을 늘리고, 손상된 콘텐츠 프로세스에서 IPC를 통해 부모 UAF를 유발함
  • 2023958
    • glibc DNS 함수 호출을 가로채 악성 DNS 서버를 시뮬레이션하고, UDP에서 TCP로 넘어가는 fallback 엣지 케이스를 재현해 HTTPS RR 및 ECH 파싱 중 버퍼 초과 읽기와 부모 프로세스 스택 메모리 누수를 유발함
  • 2025977
    • 재진입 key() 호출이 해시 테이블 rehash를 일으켜 backing store를 해제하지만 원시 엔트리 포인터가 계속 사용되는 20년 된 XSLT 버그였으며, 수정된 여러 sec-high XSLT 문제 중 하나였음
  • 2027298
    • 컬러 피커를 패치해 자동화하기 어려운 사용자 선택을 시뮬레이션한 뒤, 동기 입력 이벤트로 중첩 이벤트 루프를 돌려 actor teardown에 재진입하고 callback이 풀리는 중 해제되게 해 콘텐츠 프로세스 UAF를 유발함
  • 2023817
    • 손상된 콘텐츠 프로세스가 임의의 배경화면 이미지를 부모 프로세스에서 디코딩하도록 보낼 수 있었고, 가상의 이미지 디코더 취약점과 결합하면 샌드박스 탈출로 이어질 수 있었음
    • 부모 프로세스에서 입력의 신뢰 수준을 판단하는 자동화하기 어려운 추론이 필요했음
  • 2029813
    • Firefox 95의 세밀한 샌드박싱 기술인 RLBox에서, 신뢰할 수 없는 쪽에서 신뢰하는 쪽으로 값을 복사하는 검증 로직의 틈을 이용해 샌드박스를 우회함
  • 2026305
    • HTML 테이블의 특수한 rowspan=0 의미를 이용하는 매우 작은 테스트케이스로, >65535개 행을 추가해 clamping을 우회하고 16비트 레이아웃 bitfield를 overflow했으며 수년간 퍼저에 잡히지 않았음

샌드박스 탈출과 방어 계층

  • 공개된 버그 중 상당수는 샌드박스 탈출이며, Firefox 전체 체인 침해로 이어지려면 다른 익스플로잇과 결합되어야 함
  • 이런 보고서는 사이트 콘텐츠를 렌더링하는 샌드박스 프로세스가 별도 버그로 이미 손상되어 있고, 공격자 제어 기계어 코드가 권한 있는 부모 프로세스로 권한을 올리려는 상황을 전제로 함
  • 샌드박스 탈출을 만들 때 모델은 수정된 코드가 샌드박스 프로세스 안에서만 실행되는 한 Firefox 소스 코드를 패치할 수 있음
  • 이 유형의 버그는 퍼징으로 찾기 어렵고, Mozilla는 스냅샷을 이용한 IPC 퍼징 같은 기법을 개발해 왔지만, AI 분석이 이 중요한 표면을 훨씬 포괄적으로 다룰 수 있었음
  • 모델이 찾지 못한 부분도 중요했음
    • 최근 몇 년간 보안 연구자들은 권한 있는 부모 프로세스에서 prototype pollution을 유발해 프로세스 샌드박스를 탈출하는 보고서를 여러 건 보냈음
    • Mozilla는 문제를 하나씩 고치는 대신, 기본적으로 prototype을 freeze하는 아키텍처 변경을 적용함
    • 하네스 로그에서는 이 탈출 경로를 시도했지만 설계로 막힌 흔적이 많이 보였고, 이전 강화 작업의 직접적인 효과가 확인됨

하네스로 보안 강화 파이프라인 구축

  • Mozilla는 지난 몇 년간 GPT 4나 Sonnet 3.5 같은 모델로 고위험 코드를 정적 분석하는 LLM 코드 감사 실험을 내부에서 진행했음
  • 초기 실험은 가능성을 보였지만, 거짓 양성 비율이 높아 규모를 키우기 어려웠음
  • 보안 문제를 안정적으로 감지하는 agentic 하네스의 등장으로 상황이 바뀜
    • 실제 버그를 찾을 수 있음
    • 재현되지 않는 추측을 버릴 수 있음
    • 적절한 인터페이스와 지시가 있으면 재현 가능한 테스트케이스를 만들고 실행해 코드 버그 가설을 동적으로 검증할 수 있음
  • Mozilla는 2월 Anthropic이 보낸 초기 이슈를 수정한 뒤, 기존 퍼징 인프라 위에 자체 하네스를 구축함
  • 초기에는 Claude Opus 4.6으로 샌드박스 탈출을 찾도록 작은 규모의 실험을 시작했음
    • 이 모델만으로도 멀티프로세스 브라우저 엔진 코드에 대한 복잡한 추론이 필요한, 이전에 알려지지 않은 취약점을 상당수 식별함
    • 처음에는 터미널에서 과정을 직접 지켜보며 실시간으로 프롬프트와 로직을 조정함
    • 작동이 안정된 뒤에는 여러 ephemeral VM으로 작업을 병렬화하고, 각 VM이 특정 대상 파일에서 버그를 찾은 뒤 결과를 bucket에 기록하도록 함
  • 발견 하위 시스템만으로는 충분하지 않았음
    • 무엇을 찾을지, 어디를 볼지, 결과물을 어떻게 처리할지를 포함해 전체 보안 버그 수명주기와 통합해야 했음
    • 기존 이슈와의 중복 제거, 버그 추적, triage, 수정 배포까지 포함됨
    • 모델은 하네스를 움직이는 핵심 원시 요소지만, 규모 있게 유용하게 만들려면 전체 파이프라인이 필요함
  • 하네스는 프로젝트 간 재사용 가능성이 있지만, 파이프라인은 코드베이스의 의미, 도구, 프로세스에 따라 프로젝트별로 달라짐
  • Firefox 엔지니어들이 들어오는 버그를 처리하는 과정과 밀접한 피드백 루프를 두고 상당한 반복 작업이 필요했음

Claude Mythos Preview와 모델 교체 효과

  • 엔드투엔드 파이프라인이 갖춰지면 새 모델이 나올 때 다른 모델로 바꾸는 일은 간단해짐
  • Mozilla는 공개 모델로도 여러 심각한 버그를 찾았고, 이 파이프라인 덕분에 Claude Mythos Preview 평가 기회를 얻었을 때 바로 활용할 수 있었음
  • 모델 업그레이드는 파이프라인 전체의 효과를 높였음
    • 잠재 버그를 더 잘 찾음
    • 버그를 입증하는 개념증명 테스트케이스를 더 잘 만듦
    • 병리와 영향을 더 잘 정리함
  • Firefox 150 release에서 Claude Mythos Preview가 식별한 271개 버그를 수정한 것 외에도, 149.0.2, 150.0.1, 150.0.2에도 관련 수정이 포함됨
  • 내부적으로는 다른 방법으로도 버그를 계속 찾고 있으며, 다른 프로젝트들과 비슷하게 최근 몇 달간 외부 보고도 크게 늘었음
  • 모든 버그는 제대로 고치려면 세심한 주의가 필요했고, 전례 없는 규모를 따라잡기 위해 지난 몇 달간 많은 작업과 긴 근무가 이어졌음
  • 100명 넘는 사람이 가장 안전한 Firefox를 배포하기 위한 코드 기여에 참여했으며, 패치 작성·리뷰 외에도 파이프라인 구축·확장, triage, 수정 테스트, 각 버그의 릴리스 프로세스 관리가 함께 이루어졌음

핵심 교훈

  • 소프트웨어를 만드는 누구나 지금 현대적 모델과 하네스를 사용해 버그를 찾고 코드를 강화할 수 있음
  • 간단한 프롬프트에서 시작해 관찰하고 반복할 수 있음
    • 초기 프롬프트는 이 영상에 나온 방식과 크게 다르지 않았음
    • 반복을 거치며 파이프라인 최적화와 확장을 위한 orchestration과 도구가 많이 추가됐지만, 내부 루프의 핵심은 “이 코드 부분에 버그가 있으니 찾아서 테스트케이스를 만들어라”였음
  • Firefox의 잠재 버그를 모두 바닥낸 상태는 아니지만, 현재 궤적에는 만족하고 있음
  • 현재 스캔은 대체로 사람의 판단과 자동 신호를 섞어 지정한 특정 코드 영역, 즉 파일과 함수에 집중됨
  • 가까운 미래에는 이 분석을 지속적 통합 시스템에 통합해 패치가 tree에 들어올 때 스캔할 계획임
  • 모델은 제공되는 문맥 형식에 유연하게 대응하며, 패치 기반 스캔이 파일 기반 스캔만큼 또는 그보다 더 잘 작동할 것으로 예상됨
  • 현재 시점은 위험하지만 기회도 크며, 인터넷을 안전하게 만들기 위해 함께 움직여야 함

자주 묻는 질문

  • “271개 버그”와 보안 권고 숫자가 다른 이유

    • 보안 권고 웹페이지에서는 내부 보고 버그를 여러 개의 버그가 아래에 묶인 “rollup” CVE로 그룹화함
    • 웹페이지는 CVE 할당의 정식 위치인 foundation-security-advisories 저장소의 yaml에서 만들어짐
    • 일부 브라우저는 내부 발견 이슈에 CVE 식별자를 만들지 않지만, Mozilla는 가능한 투명하게 정보를 제공하기 위해 이를 공개함
    • Firefox 150에는 내부 rollup이 3개 있었음
      • CVE-2026-6784: 154개 버그
      • CVE-2026-6785: 55개 버그
      • CVE-2026-6786: 107개 버그
    • 세 내부 rollup의 합은 316개로, Claude Mythos Preview로 찾았다고 발표한 271개보다 많음
    • 이유는 Mozilla 보안팀이 매일 Firefox를 공격하며 새 버그를 찾고, 그 방법이 퍼징 시스템, 수동 검사, 여러 모델을 활용한 새로운 agentic 파이프라인의 조합이기 때문임
    • 4월 릴리스에서 총 423개의 보안 버그가 수정됨
      • 2주 전 발표한 271개 버그
      • 외부 보고 버그 41개
      • 나머지 111개는 내부 발견이며 대략 세 부류로 나뉨
        • Claude Mythos Preview를 사용한 이 파이프라인으로 찾았지만 Firefox 150이 아닌 다른 릴리스에서 수정된 버그
        • 다른 모델을 사용한 이 파이프라인으로 찾은 버그
        • 퍼징 같은 다른 기법으로 찾은 버그
    • Anthropic에는 이번 최신 작업과 별개로 CVE 3개가 직접 크레딧됨
      • CVE-2026-6746
      • CVE-2026-6757
      • CVE-2026-6758
    • 이들은 몇 달 전 Anthropic Frontier Red Team이 Mozilla에 보낸 버그 수정이며, 일반 절차에 따라 각각 고유 CVE가 할당됨

  • 보안 심각도 등급의 의미

    • Mozilla는 버그의 긴급도를 나타내기 위해 security severity ratings를 critical부터 low까지 적용함
    • sec-critical과 sec-high는 웹페이지 방문 같은 일반 사용자 행동으로 유발될 수 있는 취약점에 부여됨
    • sec-critical과 sec-high 사이에 기술적 차이는 없지만, sec-critical은 공개적으로 공개됐거나 실제 공격에 악용된 것으로 알려진 이슈에만 사용됨
    • sec-moderate는 원래 sec-high로 평가될 취약점이지만 피해자에게 비정상적이고 복잡한 단계가 필요한 경우에 부여됨
    • sec-low는 안전한 crash처럼 사용자 피해와 거리가 먼 성가신 버그에 부여됨
    • Firefox 150에서 발표한 271개 버그의 등급은 다음과 같음
      • sec-high 180개
      • sec-moderate 80개
      • sec-low 11개
    • Mozilla는 critical/high 버그를 가장 중요하게 보지만, 정확성 문제 수정과 심층 방어를 위해 moderate와 low 보안 버그도 우선순위에 올리는 것이 일반적임

  • sec-high 또는 sec-critical과 실제 익스플로잇의 차이

    • sec-high 또는 sec-critical 버그가 곧 실용적 익스플로잇이라는 뜻은 아님
    • 대부분의 경우 하나의 critical/high 버그만으로 Firefox를 침해하기에는 충분하지 않음
    • Firefox는 심층 방어 아키텍처를 갖고 있어, 예를 들어 JIT 버그를 악용해도 샌드박스되고 사이트별로 분리된 프로세스에서 원격 코드 실행을 얻는 수준임
    • 실제 공격자는 일반적으로 여러 익스플로잇을 체인으로 묶어 하나 이상의 샌드박싱 계층과 ASLR 같은 OS 수준 완화를 거쳐 권한을 올려야 함
    • Mozilla는 일반적으로 버그가 실제 공격자에게 사용될 수 있는지 확인하기 위해 익스플로잇을 만들지 않음
    • sec-high 분류는 AddressSanitizer가 보고하는 use-after-free나 out-of-bounds 메모리 문제 같은 예측 가능한 crash 증상에 기반함
    • 위협 모델은 충분한 노력이 있으면 이런 버그가 악용 가능할 수 있다고 가정함
    • 이 방식은 악용 가능성 분석에서 거짓 음성 위험을 줄이고, 더 많은 취약점을 찾고 고치는 데 자원을 집중하게 해줌
GeekNews Weekly에 포함된 글입니다. 에디터 코멘트 보기

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 다시 강조하지만 버그는 버그임. “잠재적 취약점”도 버그이고, 취약점은 개념 증명이나 그에 준하는 증거로 보안상 영향이 검증돼야 함
    단어는 중요하고, 버그도 중요함. 많은 버그를 고치는 일은 예전부터 중요했고 실제로 해왔던 일이며, 그 자체로도 충분히 인상적임
    Mythos가 취약점 271개에 대해 개념 증명을 작성하고 보안상 영향이 있는 코드 경로 도달 가능성을 입증한 것은 아님. Mythos는 유효한 버그 271개를 찾았고, 그걸로 충분하다고 봄

    • 정의가 조금 헷갈렸는데, Mozilla는 그 271개의 “무언가”를 이렇게 나눴음 [1]
      추가 맥락으로, Mozilla는 버그의 긴급도를 나타내기 위해 보안 심각도를 critical부터 low까지 적용함. sec-critical과 sec-high는 웹 페이지 방문 같은 일반 사용자 행동으로 트리거될 수 있는 취약점에 붙으며, 기술적으로는 둘을 구분하지 않지만 sec-critical은 공개됐거나 실제 악용이 알려진 문제에 예약됨
      sec-moderate는 원래 sec-high에 해당하지만 피해자에게 비정상적이고 복잡한 단계가 필요한 취약점에 붙고, sec-low는 사용자 피해와는 거리가 먼 성가신 버그, 예컨대 안전한 크래시에 붙음
      Firefox 150에서 발표한 271개 버그 중 180개는 sec-high, 80개는 sec-moderate, 11개는 sec-low였음
      Mozilla는 실용적인 익스플로잇과 같은 뜻은 아니라고 바로 아래에서 말하면서도 sec-high에도 “vulnerability”라는 말을 씀. 정의 페이지에서는 sec-low조차 “vulnerabilities”로 분류함 [2]
      단어는 도구이고, 그 유용성은 집단적 의미에서 나옴. 그 의미 체계를 어디서 받아들였는지, Mozilla와 일치하는지 아니면 다른지 궁금함
      [1] https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...
      [2] https://wiki.mozilla.org/Security_Severity_Ratings/Client
    • Mythos는 실제로 use-after-free, 경계 밖 읽기/쓰기 같은 메모리 안전성 위반으로 크래시가 나는 모든 버그에 대해 개념 증명을 작성했음
      우리 기준으로는 반대 증거가 없는 한 이 정도면 보안 취약점으로 보기 충분한 실질적 증거이고, 퍼징 버그에서도 항상 그렇게 다뤄 왔음
    • Claude는 자신이 사용자가 그 코드를 소유한다고 믿는 경우, 찾은 악용 가능한 버그에 대해 개념 증명 익스플로잇을 만들 수 있고 실제로 만들기도 함
      출처는 개인 경험뿐이고, 증거는 공유할 수 없음
    • 무엇을 먼저 처리할지 결정해야 하는 현장에서는 이런 구분이 통하지 않음
    • “취약점용 PoC 271개”가 아니라면, 찾고 있는 단어는 익스플로잇에 가까워 보임

  • 앞선 비기술 블로그 글은 Anthropic을 위한 노골적인 제품 홍보로 치부했음. 링크된 Mozilla Hacks 글은 이 기사보다 더 나은 출처이고 반가운 공개 자료임
    이제는 뭔가 실제 성과가 있다는 점을 부정하기 어려워 보임. Mozilla 내부의 “취약점” 정의는 많은 사람이 직관적으로 생각하는 것보다 넓게 적용되는 듯하지만, 이런 문제가 진지하게 받아들여지고 고쳐지는 건 좋음

  • 원 출처: https://news.ycombinator.com/item?id=48051079
    실제로 공개된 Bugzilla 리포트 일부를 나열하고 있어서 더 나음. 이 주제는 예전에 한 번 논의됐지만, 버그 리포트가 공개됐다는 부분은 완전히 새로움
    이전 논의는 2주 전 36개 댓글짜리였음: https://news.ycombinator.com/item?id=47885042

  • LLM이 버그를 찾고 고치는 데 너무 좋아져서, Firefox 엔지니어들이 새 기능 추가에만 집중할 수 있는 날이 오면 좋겠음
    비꼬는 말이 아님. Firefox는 더 많이 쓰일 자격이 있음. 주변 대부분은 “Chrome이 거의 모든 걸 더 잘한다”는 이유로 Firefox를 쓰지 않고, Firefox는 다른 브라우저들의 로드맵과 경쟁하기 어려움

    • Firefox가 더 많이 쓰여야 한다는 데 완전히 동의함. 사이트에서 구매할 때도 Firefox에서 동작하는지에 따라 어디서 살지 고를 정도임
      가끔 지원팀에 Firefox가 지원되지 않거나 기능이 제대로 작동하지 않는다고 쓰기도 함. 거의 항상 아무 일도 안 생기지만, 브라우저를 어떻게든 시야 안에 남겨두기 위해 내가 할 수 있는 일이라고 느낌
    • 문제의 일부는, 버그 수정을 멈추면 Mozilla가 Mr Robot식 일을 벌이기 시작한다는 것임. 우리는 그냥 웹 브라우저를 원함. Pocket이나 AI를 요청한 사람은 없었음
      AI로 모든 버그를 고치면, 여러 빌드 언어와의 문법 호환성을 유지하는 것 말고 남는 일이 뭘까? 결국 다시 브라우저를 엉망으로 만드는 쪽으로 돌아갈 것 같음
    • 그런 품질과 가용성은 Chrome이 Firefox보다 훨씬 더 빨리 앞서 나가게 만들지 않나 싶음
      Mozilla가 내부에서만 쓰는 독점 LLM이나 하네스를 만들어 Chrome보다 앞서 나간다면 다른 얘기겠지만, 그것도 현실적으로는 잘 안 보임
    • Chrome은 사용 사례의 99% 이상에서 의미 있게 더 낫지 않음. 개발자인데도 지난 10년쯤 Firefox와 uBlock Origin만 써 왔음
      아내도 설명을 듣고 인터넷 경험이 얼마나 달라질 수 있는지 이해한 뒤로 Firefox를 주 브라우저로 씀
      그러니 “독점은 나쁘고 Google은 좀 악하니, 부족한 약자를 써 달라”는 식으로 말하지 않았으면 함. 내가 던진 모든 작업에서 Firefox는 일급 경험이었고, 모바일에서는 그 세 배쯤 더 그렇다. 단연 최고의 유용한 모바일 브라우저 경험임
    • 브라우저에는 아주 오래전부터 새 기능이 필요 없었음. 그런 건 확장 기능이 해결책이어야 했음

  • 링크된 티켓은 몇 개뿐이라 271개의 실제 개별 항목을 모두 보면 달라질 수도 있겠지만, 내가 살펴본 것들은 전부 C++ 코드의 심각한 버그였음
    Firefox는 여러 언어로 작성돼 있고 C++는 약 25%뿐인데, 이 문제들은 하나같이 C++를 건드리는 것처럼 보임

    • 이 접근의 일반적 한계는 검증기가 좋은 만큼만 좋다는 것임. 예컨대 AddressSanitizer가 use-after-free를 내는 테스트 케이스만큼 검증하기 쉬운 것도 없음
      더 미묘한 문제에는 더 구체적인 검증기가 필요할지, 아니면 LLM이 스스로 검증할 다른 위험 조건을 더 잘 떠올리게 될지 지켜봐야 함
    • Mythos가 다른 언어보다 C++ 취약점을 훨씬 잘 찾을 가능성은 있음. 이런 모델들도 기존 보안 분석 자료를 바탕으로 만들어졌기 때문임
      내가 보기엔 이 버그들 상당수는 C++에만 국한된 문제라기보다, 우연히 C++ 코드에서 발생한 것에 가까움. 가장 안전한 Rust라도 TOCTOU 같은 문제를 마법처럼 잡아낼 수는 없음
    • 버그를 AddressSanitizer로 검증했기 때문에, 구조상 C++ 버그만 찾게 되어 있었음

  • Zig 쪽 사람들이 LLM이 생성한 버그를 검토 대상으로조차 보지 않으려는 태도와 이 글을 함께 읽으니, 앞으로 내 도구 체인에 어떤 기술을 넣을지 보는 관점이 달라짐

    • 둘 다 맞고, 어떤 모델을 쓰는지와 누가 버그를 제출하는지에 달려 있음. 선도 모델의 역량은 몇 달 사이에 99% 잡음에서 99% 유효한 버그로 바뀌었음
      어떤 프로젝트들은 전자에 해당하는 것들로 넘쳐나고 있어서, 유지보수자에게 사실상 서비스 거부 공격이 되지 않도록 예방책이 필요함

  • PalmSource에 있을 때 CoVerity나 Fortify 같은 정적 코드 분석 도구 예산을 얻으려 했지만, 관리 라인은 “너무 비싸다”고 했음
    1년을 더 들여 비용을 낮추고 네트워크 스택 스캔으로 제한한 안을 만들었는데, 이번에는 “BSD 기반이고 BSD는 본질적으로 안전하다”고 했음. 둘 다 사실이 아님
    결국 회사를 떠나 Mozilla로 갔고, 코드 곳곳에 /* flawfinder ignore */ 주석이 흩어져 있었음
    내 추측으로는 Mythos가 flawfinder ignore 지시문을 무시하고 코드 안의 알려진 취약점을 보고했을 뿐인 것 같음

    • 코드는 공개돼 있음. 그게 사실임을 증명할 수 있다면 진짜 뉴스거리가 될 것임

  • 이게 정적 분석 도구에 어떤 영향을 줄지 궁금함. 결은 꽤 다르지만 종종 같은 목표를 달성하긴 함
    정적 분석 도구는 느릴 수 있고 오탐도 많이 낸다. 이런 모델들이 충분히 좋아지고 싸지면 사람들이 정적 분석을 거의 찾지 않게 될지 궁금함

    • LLM은 도구를 대체하는 것보다 도구를 사용하는 일에 훨씬 더 뛰어남. 같은 결과를 LLM으로 얻으려 하기보다 기존 도구를 쓰는 편이 보통 훨씬 빠름
      LLM 코딩 도구로 정적 분석 도구의 출력물을 계속 정리하는 방식은 아주 잘 동작하고, 문제가 남지 않도록 강제하는 가드레일을 추가하는 것도 좋은 생각임. 모든 것이 깨끗한지 확인하는 CI 검사와 같음
      오탐은 도구에 따라 다름. 대부분 잡음만 만드는 도구는 피하는 편이고, 이런 도구들은 보통 잡음이 많은 규칙을 끌 수 있게 해줌. 아니면 LLM에게 모든 문제를 고치라고 하면 됨. 규칙과 논쟁하는 것보다 고치는 게 싸다면 그냥 고치면 된다. 예전에는 사람이 직접 해야 해서 아주 비쌌지만 지금은 그렇지 않음
      최근 몇 년간 손대지 않았던 Ansible 코드베이스를 갱신하면서 이 방식을 썼음. ansible-lint 문제가 수백 개 있었고, 대부분은 폐기 예정 경고와 치명적이지 않은 경고였는데 10분 뒤에는 0개가 됨. 아주 심각한 문제는 아니었겠지만 일종의 기술 부채였음. 수백 개 경고를 수동으로 고쳐야 한다면 아마 안 하겠지만, 마법 지팡이를 한 번 휘둘러 다 사라진다면 안 할 이유가 없음. 이제는 가드레일을 조정해 항상 ansible-lint를 돌리고 문제를 고치게 했으며, 몇 초만 더 걸림
    • 흥미로운 가능성은 LLM이 처음 발견한 버그 형태를 정적 분석 도구가 찾도록 강화하는 것임[0]
      정적 분석 도구가 더 빠르고 싸다는 데는 의심의 여지가 없어서, 거대한 코드베이스에 더 잘 확장되고 LLM의 방법을 일반화할 수도 있음
      [0] https://lwn.net/Articles/1068968/
    • 정적 분석 도구도 훨씬 빠를 수 있고 대부분 완전히 결정적이라, CI에 넣으면 버그나 잠재 버그가 코드베이스에 들어오기 전에 잡을 수 있음
      Firefox CI에서 쓰는 정적 분석 도구를 유지보수하고 있음. 우리 트리에 패치를 넣으려면 오탐이든 진짜 양성이든 모두 고치거나 문제가 아니라고 표시해야 함. 즉 양성을 0개로 허용해야 하는데, 꽤 엄격한 기준임
      이건 의식적인 절충임. 사람들이 무시하거나 전부 주석 처리해 없애거나, 아예 실행을 멈추지 않도록 신호 대 잡음비를 충분히 높이려면 분석을 약화시키고 일부 미탐을 받아들여야 함. 거의 모든 정적 분석 도구가 이런 균형을 맞춰야 함
      반면 흔히 쓰이는 AI에는 더 많은 여지가 주어짐. 오탐을 환각하도록 허용해야 한다는 점이 거의 근본적이고, 그게 힘의 상당 부분이기도 함. 그래서 그 위에 여러 검증과 확인 계층이 필요함. 느릴 수 있고, “이 특정 형태의 오류를 100% 잡는다”고 말할 수는 없지만 그래도 엄청나게 많은 것을 잡음
      한 데이터 포인트가 있음. 내 분석은 진짜 버그가 나올 가능성이 낮다고 잘못 생각했고 구현도 번거로워 보였던 한 경우를 다루지 않았음. Opus인지 Mythos인지 확실하지 않지만 그 경우에서 비롯된 취약점을 보고하기 시작했고, 나는 급히 분석을 확장해 빈틈을 메웠음. 구현하는 데 꽤 오래 걸렸고 전체 소스 트리를 스캔했을 때는 Claude가 보고한 중요한 문제를 이미 모두 찾아낸 뒤였음. 정적 분석은 몇 개를 더 찾았지만, 그중 실제로 트리거될 수 있는 게 있는지는 아직도 솔직히 모르겠음
      그래도 정적 분석에는 가치가 있다고 봄. 문제 패턴의 일부 발생 지점은 지금도 AI가 구성하기엔 너무 까다로운 경로를 통해 도달 가능할 수 있음. 다른 코드가 바뀌면 실제 문제가 될 수도 있음. 두 가능성 모두를 위해 지금 전부 고쳐두는 게 가치 있어 보이고, AI가 그것들을 악용하려고 시간을 낭비하지 않게 한다는 덜 중요한 이유도 있음. 동시에 비용 대비 효과의 균형이 분명히 바뀐 것도 사실임
      둘이 협력할 수도 있음. 내 기준을 완화해 분석 도구가 의심 문제에 대한 추가 경고 보고서를 쓰게 하고, 오탐일 수 있다는 기대를 명확히 둔 다음 그 목록을 AI에 넣어 검증하게 할 수 있음. 본질적으로 슬롭을 슬롭 기계에 먹여 그 안의 원석을 비결정적으로 걸러내게 하는 셈임
      생각해볼 만한 거리임
    • 이런 하네스들은 정적 분석 도구를 사용하고 있을 것이며, 앞으로도 아마 그럴 것 같음

  • 최신 Mission Impossible에서는 탈출한 초인적 AGI의 원본 소프트웨어를 침몰한 러시아 잠수함에서 회수해야 세상을 구할 수 있음
    Luther는 원본 소스가 주어지면 AI를 즉시 한 방에 끝내는 “poison pill”을 작성함. 이 마법 같은 코드가 어떻게 작성됐는지 궁금했는데 이제 알겠다. Luthor는 그냥 Mythos 프롬프트에 소스 코드를 넘기고 변경 불가능한 치명적 익스플로잇을 요청한 것임

  • 사람들이 LLM이 5년 뒤 소프트웨어를 더 안전하게 만들지, 덜 안전하게 만들지 어떻게 보는지 궁금함

    • 아마 몇몇 유형의 문제를 없앨 것이고, 그건 좋은 일일 가능성이 큼. 그리고 여전히 안전하지 않은 것들은 다른 언어로 옮길 수도 있음
      LLM이 등장하기 전부터 Rust로 수동 이식하는 흐름은 있었음. 이제 LLM 덕분에 그 작업은 더 쉽고 빨라질 것임. 장기적 가치는 기존 C/C++ 코드베이스라는 산더미 같은 기술 부채를 정리하는 데서 나올 것임. 이 코드들이 메모리 익스플로잇, 버퍼 오버플로, 기타 문제의 압도적 다수를 책임지고 있고, 수십 년간 주의를 기울였음에도 주요 코드베이스에서 계속 발견되고 있음
      Mozilla가 이런 문제를 찾은 것은 매우 유능한 엔지니어들이 25년 동안 올바른 일을 하려 애쓰고, 사용 가능한 모든 도구로 이런 문제가 생기지 않게 해 온 결과 위에 얹힌 것임. 그 팀과 지난 세월 도구, 테스트, 검증 관행 개선에 기여한 바를 크게 존중함. 문제는 그들의 노력이나 역량이 아님
      테스트가 잘 갖춰지고 문서화와 명세가 잘 된 기존 시스템을 받아 드롭인 대체 구현을 만드는 작업이 이제 검토 가능한 일이 됨. 몇 년 전에는 엄청난 프로젝트 비용과 위험으로 이어졌겠지만, 이제는 금요일 오후에 시작해볼 수 있는 일이 됨. 최악의 경우 실패하고, 최선의 경우 훨씬 나은 구현을 얻음
      아직 초기 단계이고 LLM 생성 코드에는 품질 문제가 많음. 하지만 성공률과 실패율은 시간이 지나며 개선될 가능성이 큼
    • 둘 다임. 숙련자는 문제를 찾는 데 쓰고, 미숙련자는 숙련자가 고쳐야 할 불안전한 슬롭 코드를 만드는 데 쓸 것임
    • 집수리 매장, 전동 공구, 쉽게 구할 수 있는 하드웨어, YouTube 튜토리얼이 엄청나게 훌륭하고 튼튼한 가구도 만들게 했지만, 조잡하고 못생기고 심지어 위험한 가구도 만들게 한 것과 비슷함
      더 많은 사람에게 더 많은 도구가 생기면, 더 넓은 범위의 물건이 더 많이 만들어짐
    • 더 안전한 소프트웨어가 되겠지만, 역병 이후 인구가 순건강해지는 것과 비슷한 방식일 듯함
    • 적절히 적용되는 경우에는 더 안전해질 것임
      다만 이런 도구를 적용하지 않는 프로젝트에 대해서는 블랙햇이 악용할 기회도 더 쉽게 얻는다는 뜻이기도 함
답변달기
GN⁺   [-]
Lobste.rs 의견들

  • 이 작업에 쓴 프롬프트와 다른 기능들도 공개해줬으면 함
    재현할 수 있게 버그 리포트나 해결 내역에 프롬프트를 포함하면 좋겠음
    비-Mythos 모델도 언급했으니, 이 작업 일부는 다른 사람들에게도 바로 유용할 수 있어 보임

    • 대부분의 프로젝트에서는 진입 장벽이 정말 낮음
      기본적으로 “이 프로젝트를 보안 이슈 관점에서 검토하되 (파일)부터 시작하고 가능한 경로를 모두 나열해줘”라고 한 뒤, 각 항목에 대해 “이 리포트를 검증하고 개념 증명을 만들어줘”라고 이어가면 됨
      지금은 Opus를 쓰면 이런 방식으로 뭔가를 못 찾기가 더 어려움
    • 프롬프트가 “이 코드베이스에서 보안 취약점을 찾아줘” 이상일 거라고 생각함?

  • 뭐라고 하든 이건 정말 인상적임
    Mythos로 271개의 보안 이슈를 찾았고 전체로는 423개를 찾았음
    그중 180개는 심각도 높음이었고, 일부 보안 이슈는 20년 된 것들이었음

    • Opus 4.6 / Mythos 비교가 얼마나 공정했는지는 완전히 명확하지 않음
      4.6으로 이전에 동일하게 스캔한 코드에서 Mythos가 “271개 버그”를 찾았다는 결과처럼 암시되지만, 글이 정확히 그렇게 말하진 않음
      연구용 하네스에도 동시에 변화가 있었던 건지 궁금함

  • “우리가 고친 여러 sec-high 이슈 중 하나가 XSLT 관련이었다”는 부분은 XSLT 제거 논란 때문에 들어간 것 같음

  • 여기서 가장 궁금한 건 거짓 양성도 얼마나 보고됐는지임
    모델이 잠재 취약점을 두 배쯤 더 많이 보고했고, 여기 나온 건 확인된 것들인지 궁금함
    모델이 보고하기 전에 재현까지 하는지도 모르겠음
    공개된 이슈들을 보면 재현을 시도하는 듯한 댓글이 보이는데, 이미 있던 봇이 한 것일 수도 있어 보임
    Firefox가 원래 이런 일을 어떻게 처리하는지나, 지금 AI와 함께 어떻게 하는지 잘 몰라서 더 자세한 설명이 있으면 매우 흥미로울 듯함

답변달기