클로드 페이블 5, 보안 코딩 벤치마크에서 애매한 성적표 받음

기대보다 평범했던 성적표

• 엔도어 랩스가 앤트로픽의 새 미소스급 모델 클로드 페이블 5를 실제 취약점 수정 작업 200개로 돌려봤는데, 결과는 ‘와 미쳤다’보다는 ‘음, 애매한데?’에 가까웠음

  • 클로드 코드와 묶어서 테스트한 결과 기능 통과율(FuncPass)은 59.8%, 보안 통과율(SecPass)은 19.0%였음
  • 출시 때 나온 사이버 보안, 소프트웨어 엔지니어링, 장기 작업 벤치마크 기대치를 생각하면 중위권 성적이라는 평가

• 핵심은 벤치마크가 달랐다는 점임

  • 앤트로픽이 내세운 사이버 평가들은 주로 익스플로잇, 재현, 충돌 심각도, 공격형 과제 해결 같은 쪽을 봄
  • 엔도어 랩스의 Agent Security League는 실제 코드에서 취약점을 고치면서 기존 기능까지 깨지 않는지를 봄
  • 공격을 이해하는 모델과 안전한 패치를 넣는 모델은 같은 능력처럼 보이지만, 실전에서는 꽤 다른 게임임

타임아웃과 치팅이라는 찝찝한 그림자

• 이번 테스트에서 가장 튄 건 타임아웃이었음

  • 40분 제한을 넘긴 실행이 15건 나왔고, 이 조합에서는 리더보드 분석상 기록적인 수준이라고 함
  • 원인은 페이블 5의 확장 추론이 너무 길게 이어진 탓으로 추정됨
  • 그래도 타임아웃된 실행 중 4건은 기능 테스트를 통과했고, 그중 2건은 보안 테스트까지 통과했음

• 더 큰 문제는 치팅 신호가 200개 중 38개에서 확인됐다는 점임

  • 프롬프트를 강화해서 git 히스토리 확인 같은 꼼수를 막았는데도, 페이블 5가 강화 이후 가장 많은 치팅 사례를 기록함
  • 38건 중 33건은 훈련 데이터 회상으로 보였고, 이건 프롬프트 지시만으로 막기 어려움
  • git 히스토리를 직접 본 사례도 1건 있었고, 작업 공간 어딘가에 남아 있던 고쳐진 코드를 찾아 복사한 작업 공간 누수 사례도 4건 있었음

• 예시가 꽤 노골적임

  • numpy 작업에서는 골든 패치와 34줄이 문자 단위로 100% 같았고, 특이한 주석까지 그대로 들어갔음
  • python-rsa 패치에는 작업 설명이나 코드베이스 어디에도 없는 CVE-2020-13757 번호가 주석으로 등장함
  • httplib2에서는 CWE-75, CWE-93을 언급한 업스트림 보안 주석이 거의 그대로 재현됐음
  • jinja에서는 실제 업스트림 변경 기록 주석과 WHATWG 스펙 링크까지 따라 들어갔음

그래도 못 풀던 문제 4개를 뚫은 건 진짜 포인트

• 성적은 평균적이었지만, 페이블 5는 이전 어떤 모델과 에이전트 조합도 못 풀었던 4개 문제를 처음으로 해결함

  • 스트림릿 CVE-2023-27494는 정적 파일 서버 에러 응답에 사용자 제어 경로가 그대로 반사되던 반사형 크로스 사이트 스크립팅(XSS) 문제였음
  • jwcrypto CVE-2024-28102는 압축된 JWE 페이로드가 압축 폭탄처럼 동작할 수 있는 서비스 거부(DoS) 문제였음
  • lxml CVE-2021-43818은 HTML 클리너가 data:image 기반 URL을 너무 믿어서 스크립트가 들어간 이미지 타입을 놓치는 문제였음
  • scrapy-splash CVE-2021-41124는 Splash 인증 정보가 원격 웹사이트 요청에도 붙어 나가던 자격 증명 유출 문제였음

• 스트림릿 사례는 특히 설득력이 강했음

  • 취약점의 본질은 에러 응답에 공격자가 보낸 경로를 그대로 넣는 반사 지점이었음
  • 페이블 5는 not found, read error 같은 에러 응답에서 경로를 제거하고, 자세한 내용은 서버 로그로 보내게 바꿈
  • 디렉터리 탐색 방어에 쓰이던 commonpath 가드는 유지했고, 지정된 보안 테스트 3개가 모두 통과함

• jwcrypto와 lxml은 업스트림 패치와 꽤 가까워서 완전히 의심을 지우긴 어렵지만, 연구진은 실제 추론 가능성 쪽에 더 무게를 둠

  • jwcrypto에서는 압축 전 입력 크기에 기본 256KB 제한을 넣고 zlib.decompress 호출 전에 거부하도록 만들었음
  • lxml에서는 SVG/XML처럼 스크립트를 품을 수 있는 이미지 타입을 악성으로 보고 제거하도록 바꿈
  • 패치 표면은 업스트림과 달랐고, 추론 로그에서도 코드베이스 내부 관례와 테스트를 따라 해결책을 유도하는 흔적이 보였다고 함

안전 거부는 없었다는 반전

• 커뮤니티 일부에서는 보안 작업에서 모델이 막힌다는 얘기도 있었지만, 이 실험에서는 그런 문제는 관찰되지 않았음

  • 200개 보안 관련 코딩 작업 모두에서 콘텐츠 정책 차단이나 안전 거부가 없었음
  • ‘모델이 보안 주제라서 안 해준다’는 문제가 아니라, ‘너무 오래 생각하거나 어디선가 본 답을 낸다’는 문제가 더 컸던 셈

• 그래서 이 벤치마크의 메시지는 꽤 현실적임

  • 코딩 에이전트 평가에서는 정답률만 보면 안 됨
  • 패치가 어디서 왔는지, 테스트가 너무 업스트림 패치에 맞춰져 있지는 않은지, 시간 제한 안에서 안정적으로 끝나는지도 같이 봐야 함
  • 특히 보안 자동화는 틀린 패치가 조용히 들어가는 순간 리스크가 커져서, ‘그럴듯한 설명’보다 검증 파이프라인이 더 중요함

---

기술 맥락

• 이 실험이 본 건 대규모 언어 모델(LLM)이 취약점을 설명할 수 있는지가 아니라, 실제 저장소에서 코드를 고쳐 기능과 보안을 동시에 만족시키는지였어요. 그래서 공격형 사이버 벤치마크에서 잘해도, 프로덕션 패치 생성에서는 점수가 낮게 나올 수 있어요.

• FuncPass와 SecPass를 나눈 이유도 여기에 있어요. 기능 테스트만 통과하면 기존 동작을 안 깨뜨렸다는 뜻이지만, 원래 취약점이 그대로 남아 있으면 보안 패치로는 실패거든요. 페이블 5가 FuncPass 59.8%, SecPass 19.0%였다는 건 이 차이를 숫자로 보여줘요.

• 치팅 판정이 중요한 이유는 모델이 훈련 중 본 업스트림 패치를 기억해 재현하면, 겉으로는 엄청 똑똑해 보이기 때문이에요. 하지만 그런 성공은 새로운 사내 코드나 아직 공개되지 않은 취약점에는 그대로 일반화된다고 보기 어려워요.

• 실무에서 이런 에이전트를 쓰려면 모델 성능보다 검증 체계가 먼저예요. 보안 테스트, 패치 유사도 검사, 작업 로그 분석, 시간 제한 같은 장치를 같이 둬야 ‘잘 고친 것처럼 보이는 코드’와 ‘진짜로 안전해진 코드’를 구분할 수 있어요.