Tool-Guided Retrieval-Augmented Repair for Securing LLM-Generated C Code

기술 요약: LLM 생성 C 코드를 보호하기 위한 도구 유도형 검색 증강 수리(Tool-Guided Retrieval-Augmented Repair)

문제 정의

대규모 언어 모델(LLM)은 펌웨어 및 임베디드 시스템을 위한 C 코드 생성과 같은 저수준 프로그래밍 작업에 점점 더 많이 활용되고 있습니다. 그러나 이러한 모델의 출력물에는 빈번하게 보안 취약점과 컴파일 에러가 포함됩니다. 기존 연구에 따르면, AI 보조 개발자가 이러한 도구를 사용하지 않는 개발자보다 덜 안전한 코드를 생성할 수 있으며, 현대적인 코드 생성 모델들도 보안 코딩 벤치마크에서 무시할 수 없는 수준의 취약성 발생률을 보입니다.

이러한 위험은 자원 제약, 제한된 메모리, 아키텍처 특정 요구 사항으로 인해 메모리 안전 위반, 미검증 입력 또는 저수준 API 오용이 치명적일 수 있는 임베디드 시스템에서 특히 심각합니다. 기존의 완화 방식은 일반적으로 다음 두 가지 범주로 나뉩니다:

1. 검색 증강 생성 (RAG): 외부 보안 지식이나 예시를 사용하여 생성을 유도합니다. 그러나 보안 문서로부터의 단순한 검색은 노이즈를 유입시키고 가이드의 효력을 약화시킬 수 있습니다.
2. 반복적 수리 (Iterative Repair): 도구 피드백(예: 정적 분석)을 사용하여 코드를 개선합니다. 이 방법은 Python과 같은 고수준 언어에는 효과적이지만, 보안, 컴파일 정확성, 저수준 동작을 동시에 고려해야 하는 임베디드 C의 복합적인 요구 사항을 해결하는 데는 실패하는 경우가 많습니다.

현재의 워크플로우는 대개 단일 패스 생성 후 수동 검사를 수행하는 방식에 의존하며, 이는 안전이 중요한 환경에서는 불충분합니다. 여러 검증 신호(컴파일, 정적 분석, 심볼릭 실행)를 검색과 결합하여 이전 결과에 기반한 점진적 수리 프로세스를 지원하는 접근 방식에는 공백이 존재합니다.

방법론

저자들은 LLM이 생성한 C 코드의 신뢰성을 향상시키기 위해 설계된 도구 유도형 검색 증강 수리(Tool-Guided Retrieval-Augmented Repair) 워크플로우를 제안합니다. 이 접근 방식은 네 가지 단계로 작동합니다.

1. 작업 명세 및 초기 생성

시스템은 C 함수 또는 소규모 프로그램(수학적 계산, 문자열 처리, 정렬 작업 포함)에 대한 자연어 설명을 입력받습니다. 모델 프롬프트에는 작업 설명과 짧은 보안 체크리스트가 포함됩니다. 모델은 인간의 개입 없이 초기 후보 구현을 생성합니다.

2. 컴파일 및 정적 분석

후보 코드는 두 단계의 분석을 거칩니다:

• 컴파일: 코드는 GCC를 사용하여 컴파일됩니다. 컴파일에 실패할 경우, 진단 정보(예: 누락된 헤더, 선언되지 않은 식별자)가 수집됩니다.
• 정적 보안 분석: 컴파일에 성공하면, 코드는 CodeQL을 사용하여 분석됩니다. 쿼리는 버퍼 오버플로, 범위 외 메모리 접근, 안전하지 않은 라이브러리 함수(예: gets, strcpy, 경계가 없는 sprintf), 미검증 반환 값, 정수 오버플로/부호 오류를 포함한 일반적인 C 취약성 클래스를 대상으로 합니다.

3. 검색 증강 수리 패턴

핵-요소는 작업 전반에 걸쳐 점진적으로 성장하는 **실행 시점 레포지토리(execution-time repository)**의 수리 패턴입니다.

• 레포지토리 구조: 각 항목은 작업 설명, 생성된 코드, 그리고 컴파일 상태, CodeQL 결과, KLEE 분석 가능성, 종합 품질 점수를 포함한 메타데이터를 저장합니다.
• 품질 점수 산정: 점수는 0.0(컴파일 실패)에서 1.0(컴파일 성공, CodeQL 클린, KLEE 클린)까지 부여됩니다. 이는 부분적인 성공과 구별하면서 보안 청결도를 우선시합니다.
• 검색 전략: 새로운 작업에 대해, 시스템은 의미론적으로 유사한 이전 항목들을 검색합니다. 시스템은 다음과 같은 대비 설계를 사용합니다:
  • 긍정적 증거: 최대 3개의 고품질 항목(점수 > 0.60)을 사용하여 보안 관행(예: scanf 반환 값 확인)을 추출합니다.
  • 부정적 증거: 최대 2개의 보안상 취약하지만 컴파일 가능한 항목을 사용하여 회피 힌트를 제공하되, 충분한 긍정적 예시가 있는 경우에만 사용합니다.
• 가이드 추출 (Guidance Distillation): 검색된 항목을 퓨샷(few-shot) 예시로서 원시 코드로 삽붙는 대신, 시스템은 이를 간결한 텍텍스트 가이드(관행 및 경고)로 추출합니다. 이는 모델이 코드를 적절히 변형하지 않고 그대로 복사할 위험을 줄입니다.
• 반복적 수리: 시스템은 작업당 최대 3회의 수리 반복을 수행합니다. 각 반복의 프롬프트에는 작업, 현재 코드, 진단 결과, 그리고 검색에서 유도된 가이드가 포함됩니다. 최적의 버전은 종합 품질 점수에 따라 선택됩니다. 레포지토리는 500개 항목으로 제한되며, 품질 유지를 위해 중복 제거가 적용됩니다.

4. 최종 심볼릭 검증

수리 루프가 끝난 후, 최종 후보는 KLEE를 이용한 심볼릭 실행을 거칩니다. 이 단계는 수리 루프 외부에서 수행되는 일회성 시맨틱 체크로서, 정적 분석이 놓칠 수 있는 오류(예: 어설션 실패, 널 포인터 역참조, 특정 입력 경로를 통해 도달 가능한 메모리 안전 위반)를 탐지합니다. KLEE 결과는 레포지토리 메타데이터를 업데이트하여 보안적으로 깨끗하고 심볼릭하게 견고한 패턴을 선호하도록 만듭니다.

주요 기여

• 통합 워크플로우: 본 논문은 단일 피드백 소스나 검색에만 의존하는 대신, 컴파일 피드백, 정적 보안 분석(CodeQL), 심볼릭 검증(KLEE)을 검색과 결합하여 조정하는 파이프라인을 제안합니다.
• 우선순위 기반 수리 로직: 이 접근 방식은 저수위 코드를 다루는 개발자의 사고 방식을 반영하여, 컴파일 실패보다 보안 문제를 먼저 해결함으로써 수리의 우선순위를 결정합니다.
• 동적 레포지토리: 정적인 지식 베이스와 달리, 본 시스템은 실행 시점에 검증된 수리 결과가 담긴 레포지토리를 활용하며, 이는 과정 중에 진화하여 작업 간에 검증된 가이드를 재사용할 수 있게 합니다.
• 추출된 가이드: 이 방법은 검색된 예시를 원시 코드가 아닌 간결한 텍스트 지침으로 변환하여, 작은 모델이 과적합되거나 부적절하게 복사하는 위험을 완화합니다.

실험 결과

본 접근 방식은 5,000개의 C 프로그래밍 작업 데이터셋을 사용하여 세 가지 오픈 소스 모델(DeepSeek Coder 1.3B, CodeLlama 7B, Qwen2.5)로 평가되었습니다. 평가는 컴파일 실패율, 정적 결함률(CodeQL), KLEE 분석 가능성을 측정했습니다.

베이스라인 성능:

• 베이스라인 모델들은 상당한 신뢰성 격차를 보였습니다. 컴파일 실패율은 27.18%(Qwen2.5)에서 45.56%(CodeLlama 7B) 사이였습니다.
• 보안 결함률도 높았으며, CodeLlama 7B는 48.50%, DeepSeek Coder 1.3B는 34.62%의 결함률을 보였습니다.

도구 유도형 수리 적용 성능:

• CodeLlama 7B: 보안 결함률이 49%에서 19%로 감소했습니다. 총 CodeQL 에러는 15,088개에서 2,463개로 감소( 83.7% 감소)했습니다. 컴파일 실패는 45.56%에서 27.50%로 줄었습니다.
• DeepSeek Coder 1.3B: 컴파일 실패는 42%에서 22%로 감소했으며, 보안 결함은 35%에서 15%로 감소했습니다. KLEE 분석 가능성은 56.80%에서 77.44%로 향상되었습니다.
• 보안 클린 비율: 컴파일 성공을 조건으로 했을 때, 보안 클린 코드 비율은 CodeLlama의 경우 10.9%에서 73.4%로, DeepSeek Coder의 경우 65.4%에서 80.6%로 상승했습니다.

오류 분석:
수리된 코드에서 남은 보안 이슈들은 NIST 소프트웨어 결함 카테고리와 밀접하게 일치했습니다. 가장 지속적인 이슈는 예외 상황 처리(예: scanf 반환 값 체크 누락) 및 버퍼 오버플로(경계가 없는 쓰기)와 관련된 것이었습니다.

의의 및 주장

저자들은 본 연구가 더 큰 모델이나 재학습 없이도 임베디드 개발을 위한 LLM 생성 C 코드의 안전성을 향상시킬 수 있는 구조화된 도구 유도형 워크플로우의 실현 가능성을 입증한다고 주장합니다.

• 제한된 범위: 저자들은 현재 평가가 임베디드 전용 벤치마크가 아닌 일반 목적의 C 작업을 대리 지표로 사용했음을 인정하며, 직접적인 임베디드 벤치마크는 향후 과제로 남겨두었습니다.
• 구성 요소 기여: 본 논문은 워크플로우가 일관된 이득을 보여주지만, 검색과 멀티 도구 피드백 각각의 구체적인 기여도를 완전히 분리하기 위해서는 추가적인 절제 연구(ablation studies)가 필요함을 언급합니다.
• 향ere 방향: 저자들은 임베디드 중심 벤치마크로 평가를 확장하고, 집계된 에러 보고를 분류 체계 기반의 취약성 분석으로 대체하며, 구성 요소의 기여도를 더 잘 이해하기 위한 절제 연구를 수행할 계획입니다.

결론적으로, 본 논문은 가벼운 분석 도구를 생성 루프에 통합하는 것이 컴파일 실패와 보안 결함 모두를 크게 줄일 수 있음을 보여주며, 더 신뢰할 수 있는 AI 보조 저수준 프로그래밍을 위한 실질적인 경로를 제시합니다.