서론

보안 진단을 나가거나 소스 코드 분석 업무를 수행할 때 가장 흔하게 겪는 좌절감 중 하나는, 도구가 수백 개의 취약점을 리포팅했는데 정작 실제로 익스플로잇(Exploit) 가능한 건 손에 꼽을 정도라는 점입니다. 특히 SAST(Static Application Security Testing) 도구들이 “심각” 등급을 매겨놓은 경고가, 실제로는 해당 함수로 들어오는 입력값이 엄격하게 필터링되어 있어 아무런 위협이 되지 않는 경우가 허다합니다.

이러한 ‘허위 양성(False Positive)’ 폭탄의 근본적인 원인은 대부분의 보안 AI 모델과 탐지 도구가 함수(Function) 단위로 학습되고 평가되었기 때문입니다. 현실世界的인 해커는 단순히 한 함수만 보지 않습니다. 공격자는 리포지토리 전체를 분석하여, A 파일의 입력값이 B 함수를 거쳐 C 파일의 민감한 함수(Sink)로 흘러가는 데이터 흐름(Data Flow)을 추적합니다.

기존의 함수 중심 벤치마크 데이터셋(CWE, SARD 등)은 이러한 ‘맥락(Context)‘을 결여하고 있습니다. 본 연구는 이러한 현실적인 괴리를 해소하기 위해, 실제 오픈 소스 리포지토리에 취약점을 자동으로 주입하고, 이를 실제로 터뜨릴 수 있는 PoV(Proof-of-Vulnerability) 코드까지 자동 생성하여 대규모 데이터셋을 구축하는 기술을 다룹니다. 이는 보안 AI 모델이 “진짜 해커"처럼 전체 코드베이스를 이해하도록 훈련시키기 위한 필수적인 과정입니다.

본론

함수 중심 탐지의 한계와 Repository-Level의 필요성

기존 딥러닝 기반의 취약점 탐지 모델들은 주로 단일 함수나 소규모 코드 스니펫을 입력으로 받습니다. 하지만 현대 소프트웨어는 모듈화가 심화되어 있어, 취약점이 발생하는 지점(Sink)과 악의적인 입력이 들어오는 지점(Source)이 파일 단위로 떨어져 있는 경우가 대다수입니다.

예를 들어, user_input()이라는 함수가 main.c에 있고, 이를 호출하여 버퍼에 복사하는 copy_data() 함수가 utils.c에 있으며, 실제 오버플로우가 발생하는 process() 함수가 core.c에 있다고 가정해 봅시다. 함수 단위 모델은 process()만 보고 “버퍼 크기 검사가 없으니 취약하다"고 판단할 수도 있지만, 실제로 copy_data()에서 길이 제한을 걸어놓았다면 이는 취약점이 아닙니다.

반대로, process() 함수 내부에서 검증 로직이 존재해 보이지만, 우회 경로가 다른 파일에 존재한다면 이를 놓치게 됩니다. 즉, Repo-Level 탐지는 제어 흐름(Control Flow)과 데이터 흐름(Data Flow)을 프로젝트 전체 차원에서 분석해야 합니다.

자동화된 PoV 데이터셋 생성 메커니즘

연구에서 제안하는 핵심은 **자동화된 벤치마크 생성기(Automated Benchmark Generator)**입니다. 이 시스템은 건전한(Sound) 실제 오픈 소스 프로젝트를 대상으로 다음과 같은 프로세스를 거쳐 학습용 데이터를 만들어냅니다.

다음은 이 자동화 파이프라인의 흐름을 나타낸 다이어그램입니다.

1
2
3
4
5
6
7
8
9

graph TD
    A[Target Repository] --> B[Code Analysis Engine]
    B --> C[Identify Injection Points]
    C --> D[Vulnerability Injection]
    D --> E[Modified Repository with Bug]
    E --> F[PoV Synthesis Engine]
    F --> G[Executable Exploit Code]
    E --> H[Labeled Dataset]
    G --> H

1. 대상 선정 및 분석: 실제 컴파일 가능한 오픈 소스 리포지토리를 선정합니다. 2. 취약점 주입 (Injection): 실제 현실에서 발생하는 패턴(CWEs)을 기반으로 코드를 자동으로 변조하여 취약점을 삽입합니다. 단순히 strcpy를 넣는 것이 아니라, 해당 프로젝트의 코딩 스타일을 모방하여 자연스럽게 버그를 심습니다. 3. PoV 합성 (Synthesis): 가장 중요한 단계입니다. 주입된 취약점을 실제로 트리거할 수 있는 구체적인 입력값(Exploit)을 생성합니다. 이것이 없으면 “취약점"이 아니라 그냥 “괴상한 코드"일 뿐입니다. 4. 데이터셋 라벨링: 취약점이 있는 코드와, 그것을 증명하는 PoC 코드가 매칭되어 정답지(Ground Truth)로 확정됩니다.

이 과정은 기존에 사람이 수행하던 노동 집약적인 “약점 주입(Poisoning)” 작업을 자동화하여 수만 개의 리포지토리 규모로 확장을 가능하게 합니다.

⚠️ 윤리적 경고: 본 문서에서 설명하는 모든 기술과 코드 예시는 보안 방어 목적의 연구 및 학습을 위한 것입니다. 허가되지 않은 시스템에 악성 코드를 주입하거나 공격하는 행위는 불법이며 엄격히 금지됩니다.

적대적 공진화 (Adversarial Co-evolution) 루프

이 연구의 흥미로운 점은 단순히 데이터를 만드는 것에 그치지 않고, **취약점을 심는 에이전트(Attacker)**와 이를 찾아내는 에이전트(Defender)**가 서로 경쟁하며 발전한다는 점입니다.

• Injection Agent: 탐지 에이전트가 못 찾아내도록 더 정교하고 은폐된 취약점을 만드는 쪽으로 진화합니다.
• Detection Agent: 더 복잡하고 교묘한 취약점을 찾아내기 위해 분석 범위와 깊이를 늘려갑니다.

이러한 적대적 학습(Adversarial Training) 과정을 통해, 인위적인 토이 데이터셋에서는 성능이 좋았지만 현실 데이터에서는 망하는 Domain Shift 문제를 해결하고 모델의 견고성(Robustness)을 극대화할 수 있습니다.

실제 취약점 주입 및 PoV 예시 (PoC)

개념을 이해하기 위해 C 언어로 작성된 간단한 시나리오를 살펴보겠습니다. 자동화 도구는 안전한 코드를 분석하여 아래와 같이 취약점을 주입하고, 이를 검증하는 PoV를 생성합니다.

[주입 전: 안전한 코드]

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

#include <string.h>
#include <stdio.h>

void handle_data(char *input) {
    char buffer[16];
    // 안전한 복사: 길이 제한이 있음
    strncpy(buffer, input, sizeof(buffer) - 1);
    buffer[sizeof(buffer) - 1] = '\0';
    printf("Processed: %s
", buffer);
}

[1단계: 자동화된 취약점 주입] 자동화 도구는 strncpy를 strcpy로 변경하거나 길이 검사 로직을 제거하여 Buffer Overflow 취약점(CWE-120)을 주입합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

#include <string.h>
#include <stdio.h>

// 취약점이 주입된 함수
void handle_data(char *input) {
    char buffer[16];
    // 취약한 코드: 길이 검사 없이 복사
    strcpy(buffer, input); 
    printf("Processed: %s
", buffer);
}

[2단계: PoV (Proof-of-Vulnerability) 생성] 이제 시스템은 위 취약점을 트리거할 수 있는 테스트 케이스(PoV)를 자동으로 생성합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

int main() {
    // PoV: 버퍼 크기(16)를 넘는 입력을 전송하여 오버플로우 유발
    char exploit_payload[32];
    memset(exploit_payload, 'A', 31);
    exploit_payload[31] = '\0';

    printf("[*] Sending PoV payload...
");
    handle_data(exploit_payload);
    
    return 0;
}

이 PoC 코드가 실행되었을 때 프로그램이 크래시(Crash)되거나 비정상적인 동작을 한다면, 해당 데이터셋의 라벨은 “Positive(취약함)“으로 확정됩니다.

기존 벤치마크와의 비교

기존 접근 방식과 본 연구에서 제안하는 Repository-Level 접근 방식의 차이는 명확합니다. 아래 표는 이를 요약한 것입니다.

| 비교 항목 | 기존 Function-Centric Benchmarks | Repository-Level Automated Benchmarks | | :— | :— | :— | | 분석 단위 | 단일 함수 또는 코드 스니펫 | 전체 리포지토리 (Cross-file) | | 실행 가능성 | 불가능한 조각 코드居多 (Stub data) | 실제 컴파일 및 실행 가능 (Full Project) | | PoV 존재 여부 | 대부분 없음 (Label only) | 취약점 증명 가능한 Exploit 포함 | | 데이터 흐름 | 제한적 (Intra-procedural) | 복잡한 프로시저 간 호출 (Inter-procedural) | | 데이터 규모 | 수천 개 ~ 수만 개 (수동 생성) | 자동화를 통한 무한 확장 가능 |

현장 감각 있는 적용 가이드

이러한 기술은 현재 보안 업계에서 어떻게 활용될 수 있을까요?

1. 보안 솔루션 벤더를 위한 학습 데이터: SAST vendors는 이 기술을 사용하여 자사 AI 모델의 정확도를 획기적으로 높일 수 있습니다. 실제 프로젝트에서 발생할 법한 버그 패턴으로 학습하므로 오탐(False Positive)을 획기적으로 줄일 수 있습니다. 2. DevSecOps 파이프라인 통합: CI/CD 단계에서 개발자는 새로운 코드를 커밋하기 전, 이 자동화된 벤치마크 생성기를 통해 “내 코드가 의도치 않은 취약점 패턴을 만들고 있지는 않은지” 사전 테스트해볼 수 있습니다. 3. CTF 및 교육용 플랫폼: 사이버 보안 교육을 위해 현실적이고 난이도 조절이 가능한 문제(Challenge)를 대량으로 생성하여 운영할 수 있습니다.

결론

이 연구는 소프트웨어 보안의 ‘성배’라고 할 수 있는 **“현실적인 환경에서의 자동화된 취약점 탐지”**에 한 걸음 더 다가갔습니다. 단순히 정규식을 매칭하거나 함수를 개별적으로 보는 관점에서 벗어나, 리포지토리 전체의 맥락을 이해하고 취약점을 ‘증명(PoV)‘할 수 있는 데이터를 자동으로 생성하는 기술은 AI 보안의 판도를 바꿀 잠재력을 가지고 있습니다.

특히, 취약점을 만드는 쪽과 찾는 쪽이 서로 경쟁하며 성장하는 적대적 공진화(Adversarial Co-evolution) 아이디어는 앞으로 보안 AI 모델이 개발되어야 할 방향성을 시사합니다. 방어자(Defender)는 공격자(Attacker)보다 항상 한 수 앞서 있어야 하며, 이를 위해서는 공격자의 시각으로 코드를 분석하고 증명할 수 있는 능력이 필수적입니다.

앞으로 우리는 단순히 “취약점이 있나요?“를 묻는 도구가 아니라, “이 취약점을 어떻게 터뜨릴 수 있나요?“까지 답할 수 있는 지능형 보안 어시스턴트를 기대해 볼 수 있을 것입니다.

참고자료

• 논문 원문: Toward Scalable Automated Repository-Level Datasets for Software Vulnerability Detection (http://arxiv.org/abs/2603.17974v1)
• 관련 CWE: CWE-120 (Buffer Copy without Checking Size of Input), CWE-787 (Out-of-bounds Write)
• 추가 학습: AI-Assisted Vulnerability Detection, Adversarial Machine Learning in Security

출처: http://arxiv.org/abs/2603.17974v1