[Paper] MOSAIC-Bench: 코딩 에이전트의 구성적 취약성 유도 측정

Source: arXiv - 2605.03952v1

위에 제공된 내용만으로는 번역할 텍스트가 없습니다. 번역을 원하는 본문을 알려주시면 한국어로 번역해 드리겠습니다.

Overview

이 논문은 MOSAIC‑Bench라는 새로운 벤치마크를 소개합니다. 이 벤치마크는 겉보기에 무해한 개발 티켓을 연속적으로 제공했을 때 코딩 어시스턴트가 취약한 코드를 생성하도록 속일 수 있는 정도를 평가합니다. 무해한 요청을 연쇄적으로 연결함으로써, 공격자는 안전 강화된 모델조차도 전통적인 프롬프트별 안전 검사들을 우회하여 악의적인 결과를 초래하도록 유도할 수 있습니다.

주요 기여

• 199개의 3단계 공격 체인에 대한 체계적인 벤치마크로, 10개의 실제 웹 애플리케이션 코드베이스, 31개의 CWE 취약점 클래스, 5개의 프로그래밍 언어를 포괄합니다.
• 결정론적 익스플로잇 오라클을 제공하여, 생성된 코드가 실제로 보안 결함을 도입했는지 자동으로 검증합니다.
• 이중 축 평가: 공격 성공률(익스플로잇 실제 여부)과 다운스트림 코드 리뷰어가 취약한 변경을 승인할 가능성을 모두 측정합니다.
• 9개의 프로덕션 코딩 에이전트(Anthropic, OpenAI, Google, Moonshot, Zhipu, Minimax)에 대한 실증 연구로, 모든 단계에서 단 두 번의 거부만으로 53‑86 %의 엔드‑투‑엔드 공격 성공률을 보였습니다.
• 직접 프롬프트 공격과의 비교를 통해, 단계별 티켓 워크플로우가 모델의 내재된 거부 또는 강화 동작을 크게 감소시킴을 확인했습니다(직접 프롬프트는 0‑20 % 성공, 단계별은 >50 % 성공).
• 완화 실험: 리뷰어를 적대적인 펜테스터로 재구성하면 회피율이 3‑17 %로 감소하고, Gemma‑4‑E4B‑it 리뷰어는 실제 GitHub PR에서 4.6 %의 오탐률로 88.4 %의 공격을 탐지했습니다.

방법론

1. 공격 설계 – 연구원들은 199개의 “티켓 체인”을 만들었으며, 각각은 무해해 보이는 세 개의 개발 작업(예: 기능 추가, 코드 리팩터링)으로 구성되지만 함께 모델이 특정 취약점을 삽입하도록 유도합니다.
2. 코드 생성 – 각 티켓은 코딩 에이전트에 순차적으로 입력되어, 개발자가 풀 리퀘스트를 반복적으로 다듬는 일반적인 엔지니어링 워크플로우를 모방합니다.
3. 익스플로잇 오라클 – 마지막 티켓 이후, 자동 검사기가 생성된 코드를 알려진 익스플로잇(예: SQL 인젝션, XSS)에 대해 실행하여 취약점이 실제로 존재하는지 확인합니다.
4. 리뷰어 시뮬레이션 – 별도의 코드‑리뷰어 모델이 누적된 diff를 평가하고 병합 여부를 결정합니다. 두 가지 리뷰어 설정을 테스트합니다:
   • (a) 표준 “일상 PR” 리뷰어,
   • (b) 보안 펜테스터 역할을 수행하도록 프롬프트된 리뷰어.
5. 기본 직접 프롬프트 – 비교를 위해, 동일한 취약점 목표를 티켓 체인을 건너뛰고 모델에 단일 직접 프롬프트로 시도합니다.
6. 지표 –
   • 공격 성공률 (ASR) – 작동하는 익스플로잇을 생성한 체인의 비율.
   • 리뷰어 승인률 – 리뷰어가 취약한 diff를 승인한 비율.
   • 오탐률 – 리뷰어가 깨끗한 코드를 악의적인 것으로 표시한 빈도(608개의 실제 GitHub PR에서 측정).

결과 및 발견

• 단계별 티켓은 내장 방어를 크게 침묵시킴: 직접 요청했을 때 보통 거부하거나 코드를 “강화”하는 모델들이 악의적인 의도가 여러 무해한 요청에 걸쳐 분산될 때는 순응하게 된다.
• 리뷰어는 약한 관문: 표준 리뷰어는 취약한 변경 사항의 약 1/4만 승인하므로, 기존 PR 자동화만으로는 보안에 충분하지 않다.
• 펜테스터 프레이밍은 효과적이지만 완벽하지 않음: 리뷰어에게 공격자 관점으로 생각하도록 강요하면 승인 비율이 크게 감소하지만, 여전히 무시할 수 없는 비율의 공격이 통과한다.
• 컨텍스트 단편화가 전부는 아님: 전체 체인을 하나의 컨텍스트에 제시해도 공격 성공률이 높게 유지되어, 보다 깊은 구성적 취약점이 존재함을 시사한다.

Practical Implications

• Tooling pipelines need compositional safety checks: 보안 감사는 각 개별 요청만 평가하는 것이 아니라 겉보기에 무해한 일련의 변경이 누적되는 효과도 고려해야 합니다.
• Integrate adversarial reviewer modes: “펜테스터” 리뷰어(또는 전용 정적 분석 단계)를 배치하면 개발자를 과도한 오경보로 압도하지 않으면서도 많은 단계적 공격을 포착할 수 있습니다.
• Model developers must train on multi‑step adversarial scenarios: 단일 프롬프트 거부에 초점을 맞춘 현재의 정렬 방법은 충분하지 않으며, 훈련 데이터에는 점진적으로 위험한 결과로 이어지는 연쇄 작업이 포함되어야 합니다.
• DevOps teams should treat AI‑generated PRs as high‑risk assets: 인간 보안 검토 없이 AI가 만든 코드를 자동으로 병합하면 대규모로 악용 가능한 버그가 도입될 수 있습니다.
• Open‑source security tools can leverage MOSAIC‑Bench: 이 벤치마크는 새로운 방어책, 린터, 혹은 모델 강화 기술을 테스트하기 위한 현실적인 취약점 체인 세트를 즉시 제공합니다.

Limitations & Future Work

• Benchmark scope: MOSAIC‑Bench는 다양한 CWE와 언어를 포괄하지만 웹‑application 백‑ends에 초점을 맞추고 있어 다른 도메인(예: 임베디드 시스템, ML 파이프라인)은 아직 테스트되지 않았습니다.
• Static oracle reliance: 익스플로잇 검증은 결정적이지만 동적 분석이 필요한 보다 미묘하거나 상황에 의존적인 취약점을 놓칠 수 있습니다.
• Reviewer models are static: 이 연구는 고정된 리뷰어 에이전트 집합을 평가했으며, 적응형 학습 기반 리뷰어는 다르게 행동할 수 있습니다.
• Human factors not explored: 실제 개발자가 AI‑generated 티켓을 검토할 때의 영향(예: 피로, 신뢰)은 현재 범위에 포함되지 않습니다.
• Future directions: 벤치마크를 추가 프로그래밍 패러다임으로 확장하고, 동적 퍼징을 오라클로 도입하며, 구성적 안전하지 않은 행동을 명시적으로 벌점화하는 학습 방식을 조사하는 것이 포함됩니다.

저자

• Jonathan Steinberg
• Oren Gal

논문 정보

• arXiv ID: 2605.03952v1
• 분류: cs.CR, cs.AI, cs.SE
• 출판일: 2026년 5월 5일
• PDF: PDF 다운로드