Security Is Relative: Training-Free Vulnerability Detection via Multi-Agent Behavioral Contract Synthesis
이 논문은 기존 심층 학습 기반 취약점 탐지 모델이 데이터 중복 제거 시 성능이 급격히 저하되는 근본 원인을 '코드 문법과 프로젝트별 행동 계약 간의 의미적 모호성'으로 규명하고, 이를 해결하기 위해 훈련 없이 Gherkin 행동 계약 합성을 통해 문맥을 분석하는 다중 에이전트 프레임워크 'Phoenix'를 제안하여 기존 모델보다 훨씬 작은 오픈소스 모델로 높은 정확도를 달성함을 보여줍니다.
역할: "왜 이 코드가 고쳐졌을까?"를 분석하여, **안전한 코드가 지켜야 할 규칙 (계약서)**을 **Gherkin(거킨)**이라는 쉬운 언어로 작성합니다.
Gherkin 이란? "Given(조건) - When(행동) - Then(결과)" 형식으로, 비전문가도 이해할 수 있는 행동 명세서입니다.
비유:
기존 방식: "이 칼은 위험해!"라고 외치는 것.
페닉스 방식: **"이 칼을 사용할 때는 반드시 '손잡이를 잡아야 한다'는 규칙 (계약서) 을 먼저 작성"**하는 것입니다.
예시: "사용자가 입력한 데이터가 100 자를 넘지 않아야 한다는 규칙"을 명확히 적어냅니다.
⚖️ 3 단계: Contract Judge (계약 심판관) - "규칙 준수 여부 확인"
역할: 작성된 '안전 계약서'를 들고 코드를 검사합니다. "이 코드가 계약서에서 정한 규칙을 지켰나요?"라고 묻습니다.
비유: 심판이 경기 규칙 (계약서) 을 보고 선수의 행동을 판단합니다. "이 선수가 규칙을 위반했는가?"만 보면 되므로, 복잡한 추론이 필요 없어 작은 AI 모델도 매우 정확하게 판단할 수 있습니다.
3. 왜 이 방법이 더 뛰어난가요?
작은 AI 로도 대박 (Training-Free): 거대하고 비싼 AI(DeepSeek-V3 등) 를 쓸 필요 없이, 오픈소스 작은 모델 (7~14B) 로도 최고의 성능을 냈습니다.
이유: AI 가 "무엇이 위험한지"를 스스로 추론할 필요가 없기 때문입니다. 규칙 (계약서) 이 이미 정해져 있기 때문입니다.
정확도 폭발: 기존 최고 성능 모델보다 **F1 점수 (정확도 지표)**가 0.668 에서 0.825로 크게 향상되었습니다.
실제 보안 전문가보다 날카로울 수도 있음:
논문은 흥미로운 사실을 발견했습니다. 개발자가 "고쳤다"라고 표시한 코드 중에서도, 페닉스는 **"아직도 위험한 부분이 남아있다"**고 지적한 경우가 18% 나 있었습니다.
사례: 개발자가 "버퍼가 너무 짧으면 감지해야 한다"는 TODO(미완료) 메모를 남겼는데, 실제 코드는 그걸 안 고쳤습니다. 페닉스는 이 숨겨진 위험을 계약서를 통해 찾아냈습니다.
4. 결론: 보안은 '절대'가 아니라 '관계'입니다
이 논문의 가장 중요한 메시지는 다음과 같습니다.
"코드 자체에 '안전'이나 '위험'이라는 절대적인 속성이 있는 것이 아니다. 그 코드가 어떤 '행동 규칙 (계약서)'과 맺고 있는 관계에 따라 안전이 결정된다."
페닉스는 코드를 단순히 분류하는 것이 아니라, 코드가 지켜야 할 구체적인 규칙을 먼저 정의하고, 그 규칙에 맞춰 심판을 내리는 방식을 통해, AI 기반 보안 검사의 새로운 지평을 열었습니다.
한 줄 요약:
"코드가 위험한지 아닌지 외우게 하지 말고, '무엇을 지켜야 하는지' 계약서를 먼저 쓰게 한 뒤, 그 계약서대로 지키는지 확인하게 하라."
1. 문제 정의 (Problem Statement)
기존 접근법의 한계: 딥러닝 기반 자동 취약점 탐지 모델은 초기 벤치마크 (Big-Vul 등) 에서 좋은 성능을 보였으나, 엄격한 중복 제거 (deduplication) 와 시계열 분할 (temporal splitting) 을 적용한 최신 벤치마크 (PrimeVul) 에서는 성능이 치명적으로 저하되었습니다 (F1 점수 0.68 에서 0.031 로 급락). 이는 모델이 취약점의 본질적인 의미 (semantic) 를 학습한 것이 아니라, 데이터셋의 표면적 패턴 (token sequence, 문법적 패턴) 에 과적합 (overfitting) 된 결과임을 시사합니다.
의미적 모호성 (Semantic Ambiguity) 문제: 동일한 코드 패턴이라도 프로젝트의 특정 행동 계약 (behavioral contract), 즉 미들웨어 아키텍처, 런타임 컨텍스트, 보안 정책 등에 따라 '안전한 코드'가 될 수도 있고 '취약한 코드'가 될 수도 있습니다.
예: mruby 프로젝트의 동일한 함수가 하나의 CVE 에서는 '수정됨 (Good)'으로, 다른 CVE 에서는 '취약함 (Bad)'으로 라벨링된 사례가 존재합니다.
기존 해결책의 부족:
RAG (검색 기반): 기존 취약점 데이터베이스와의 유사성만 기반으로 하여, 제로데이 (zero-day) 논리 결함이나 프로젝트 특유의 비즈니스 로직 취약점을 탐지하기 어렵습니다.
단일 에이전트 분류: "이 코드가 취약한가?"라는 열린 질문 (open-ended question) 을 던지는 방식은 맥락 의존적인 취약점의 특성을 처리하는 데 한계가 있습니다.
2. 제안 방법론: Phoenix (Methodology)
저자들은 Phoenix라는 훈련이 필요 없는 (training-free) 다중 에이전트 프레임워크를 제안합니다. 이는 취약점 탐지를 개방형 분류 문제에서 폐쇄형 계약 검증 문제로 재구성합니다.
핵심 아키텍처 (3 단계 다중 에이전트 파이프라인)
Semantic Slicer (에이전트 1):
역할: 취약한 코드 (Bad) 와 수정된 코드 (Good) 의 쌍을 입력받아, 취약점 메커니즘과 수정 사항이 포함된 최소한의 코드 슬라이스만 추출합니다.
효과: 불필요한 보일러플레이트 코드를 제거하여 입력 길이를 약 82.8% 줄이고, 하위 에이전트의 인지 부하를 감소시킵니다.
Requirement Reverse Engineer (에이전트 2):
역할: 추출된 코드 슬라이스와 CVE 설명을 분석하여, 수정된 코드가 준수하고 취약한 코드가 위반하는 **명시적인 보안 계약 (Security Contract)**을 Gherkin 형식 (Given-When-Then) 으로 역설계합니다.
Gherkin 의 역할: 자연어 설명이 아닌 구조화된 행동 명세 (Behavioral Specification) 를 생성하여, "무엇이 취약한가"에 대한 기준을 명확히 정의합니다.
Contract Judge (에이전트 3):
역할: 생성된 Gherkin 명세 (계약) 를 '황금 표준 (Golden Standard)'으로 간주하고, 대상 코드가 이 계약을 엄격하게 준수하는지 **준수 여부 (Compliance Check)**를 판단합니다.
특징: 모델이 취약점을 스스로 추론할 필요가 없으며, 주어진 계약에 대한 준수 여부만 판단하면 되므로 작은 모델에서도 높은 성능을 발휘합니다.
3. 주요 기여 (Key Contributions)
성능 기록 경신: PrimeVul Paired Test Set 에서 F1 0.825, **Pair-Correct 64.4%**를 달성했습니다. 이는 기존 SOTA 인 RASM-Vul (F1 0.668) 과 VulTrial (F1 0.563) 을 크게 상회하는 결과입니다.
소규모 오픈소스 모델 활용: DeepSeek-V3 (671B 파라미터) 와 같은 초대규모 상용 모델을 사용하지 않고, **7B~14B 크기의 오픈소스 모델 (Qwen, Gemma 등)**만으로 최상위 성능을 달성했습니다 (모델 크기는 48 배 작음).
Gherkin 명세의 결정적 역할: 25 가지 실험 구성과 5 가지 모델 패밀리에서 수행된 애벌레이션 (ablation) 연구 결과, Gherkin 명세 생성이 성능 향상의 핵심 동인임을 입증했습니다 (F1 점수 +0.09~+0.35 향상).
새로운 패러다임 제시: 취약점 탐지를 "패턴 매칭"이 아닌 "행동 계약 검증"으로 재정의함으로써, 맥락 의존적 보안 문제 해결의 새로운 방향성을 제시했습니다.
4. 실험 결과 (Results)
성능 비교:
Phoenix (7B+9B): F1 0.825, P-C 64.4%
RASM-Vul (DeepSeek-V3 671B): F1 0.668, P-C 21.4%
VulTrial (GPT-4o): F1 0.563, P-C 18.6%
Phoenix 는 48 배 작은 모델로 상용 모델 기반의 SOTA 를 압도했습니다.
애벌레이션 분석:
Gherkin 의 영향: Gherkin 명세를 추가한 'Feature' 조건이 'Blind'(코드 슬라이스만) 조건보다 모든 모델에서 F1 을 크게 향상시켰습니다. 이는 성능 향상이 모델 용량이 아닌 **문제 구조의 재구성 (Problem Restructuring)**에서 비롯되었음을 의미합니다.
모델 역할 최적화: 코드 전문 모델 (Qwen2.5-Coder-14B) 이 에이전트 2(명세 생성) 로, 일반/추론 모델 (Qwen3.5-9B) 이 에이전트 3(판단) 으로 사용될 때 최적의 성능을 보였습니다.
오류 분석 (Qualitative Analysis):
False Positive (위양성) 의 재해석: Phoenix 가 '취약하다'고 판단한 97 개 중 18%(17 개) 는 개발자가 수정한 코드에도 실제 보안 우려 (TODO 주석, 새로운 오버플로우 등) 가 존재하는 경우였습니다. 이는 보안이 코드의 절대적 속성이 아니라 특정 행동 계약에 대한 상대적 속성임을 실증했습니다.
False Negative (위음성) 원인: 주로 명세 (Specification) 가 불완전하거나, 에이전트 3 이 경계 조건 검사의 논리적 타당성 (예: 부호 없는 정수의 무한 루프) 을 깊이 있게 분석하지 못해 발생했습니다.
5. 의의 및 결론 (Significance & Conclusion)
보안의 상대성 입증: 이 논문은 "동일한 코드 문법이라도 프로젝트의 행동 계약에 따라 안전할 수도, 위험할 수도 있다"는 **보안의 상대성 (Security is Relative)**을 실증적으로 증명했습니다.
훈련 불필요 (Training-Free) 의 가능성: 방대한 취약점 데이터로 모델을 미세 조정 (Fine-tuning) 하는 대신, **구조화된 행동 계약 (Gherkin)**을 중간 표현으로 활용함으로써 소규모 모델로도 높은 정확도의 취약점 탐지가 가능함을 보여주었습니다.
소프트웨어 공학적 통찰: 도메인 주도 설계 (DDD) 의 'Bounded Context' 개념을 적용하여, 에이전트 3 의 추론 범위를 명확한 계약으로 제한함으로써 노이즈를 제거하고 판단의 일관성을 높였습니다.
미래 전망: Phoenix 는 완전 자율 탐지기를 넘어, 인간 전문가가 보안 정책을 Gherkin 명세로 작성하거나 기존 BDD 테스트 스위트와 연동하여 사용할 수 있는 명세 기반 검증 프레임워크로서의 가능성을 제시합니다.
요약하자면, Phoenix 는 대규모 모델의 능력보다는 **문제의 올바른 정의 (계약 기반 검증)**와 **구조화된 중간 표현 (Gherkin)**을 통해 취약점 탐지의 근본적인 한계를 극복한 획기적인 연구입니다.