바이브 코딩(Vibe Coding)은 안전한가? AI 코딩 에이전트의 보안 취약점 연구(Is Vibe Coding Safe? 논문)

포스팅 개요

본 포스팅은 Carnegie Mellon University 연구진이 발표한 "Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks" 논문을 리뷰하는 포스팅입니다. 최근 AI 코딩 도구의 발전으로 바이브 코딩(Vibe Coding)이라는 새로운 프로그래밍 패러다임이 등장했는데요. 개발자가 자연어로 요청하면 LLM 에이전트가 복잡한 코딩 작업을 수행하는 방식입니다.

Cursor, Claude Code와 같은 AI 기반 개발 도구들이 급격히 인기를 얻으면서, 설문조사에 따르면 개발자의 75%가 바이브 코딩을 사용하고 있으며 그 중 90%가 만족한다고 응답했습니다. 심지어 Anthropic 같은 프론티어 AI 기업들도 "프로덕션에서 바이브 코딩을 사용한다"고 공개적으로 인정했죠.

하지만 여기서 중요한 질문이 생깁니다. "바이브 코딩으로 생성된 코드는 정말 안전한가?" 이 논문은 이 질문에 답하기 위해 SUSVIBES라는 새로운 벤치마크를 제안하고, 프론티어 코딩 에이전트들의 보안 취약점을 분석합니다. 결과는 상당히 충격적인데요. 기능적으로 올바른 코드의 80% 이상이 보안 취약점을 포함하고 있었습니다.

본 논문의 공개된 arxiv 링크는 아래와 같으며 본 포스팅은 아래 링크의 논문을 참고해서 작성한 리뷰 포스팅입니다.

 

• https://arxiv.org/abs/2512.03262

 

---

포스팅 본문

포스팅 개요에서도 언급하였듯, 바이브 코딩은 개발자 생산성을 크게 높여주었지만 보안 측면에서는 우려가 있습니다.

본 포스팅은 논문에 작성되어진 순서를 따라가며, Abstract부터 시작하여 벤치마크 구축 방법, 실험 결과, 그리고 보안 완화 시도까지 상세히 살펴보도록 하겠습니다.

 

[1]. Abstract

논문의 저자들은 Abstract에서 바이브 코딩(Vibe Coding)을 "사람 엔지니어가 대규모 언어 모델(LLM) 에이전트에게 최소한의 감독 하에 복잡한 코딩 작업을 완료하도록 지시하는 새로운 프로그래밍 패러다임"으로 정의합니다. 바이브 코딩이 점점 더 채택되고 있지만, 그 결과물이 정말로 프로덕션에 배포해도 안전한지에 대한 의문을 제기하죠.

이 질문에 답하기 위해, 저자들은 SUSVIBES라는 벤치마크를 제안합니다. SUSVIBES는 실제 오픈소스 프로젝트에서 수집한 200개의 기능 요청(feature-request) 소프트웨어 엔지니어링 작업으로 구성되어 있는데요. 이 작업들은 프로그래머들이 구현했을 때 취약한 구현으로 이어졌던 것들입니다.

저자들은 여러 프론티어 모델을 탑재한 다양한 코딩 에이전트들을 이 벤치마크에서 평가했습니다. 결과는 상당히 충격적인데요. SWE-Agent와 Claude 4 Sonnet 조합에서 솔루션의 61%가 기능적으로 올바르지만, 보안적으로 안전한 것은 단 10.5%에 불과했습니다. 추가 실험에서는 취약점 힌트를 제공하는 등의 예비적인 보안 전략도 이러한 보안 문제를 완화할 수 없음을 보여주었습니다.

 

---

[2]. Introduction

저자들은 Introduction에서 바이브 코딩의 현황과 문제점을 상세히 설명합니다. 바이브 코딩은 소프트웨어 엔지니어가 자연어로 소프트웨어 작업을 요청하면 LLM 에이전트가 복잡한 프로그래밍 작업을 완료하는 방식인데요. Cursor, Claude Code와 같은 AI 기반 IDE와 CLI의 인기에서 알 수 있듯이 점점 더 많이 채택되고 있습니다.

The Information 설문조사에 따르면 응답자의 75%가 바이브 코딩을 사용하고 있으며, 그 중 90%가 만족한다고 응답했습니다. WIRED의 또 다른 설문조사에서는 1년 미만 경력의 초보 프로그래머들이 바이브 코딩에 대해 훨씬 더 낙관적이라는 것을 보여주었죠. Anthropic 같은 프론티어 AI 기업들도 "프로덕션에서 바이브 코딩을 사용한다"고 공개적으로 인정했습니다.

하지만 바이브 코딩이 엔지니어 생산성을 높였을 수 있지만, 에이전트가 생성한 코드의 보안은 여전히 의문입니다. 특히 바이브 코딩 사용자들은 생성된 코드를 신중하게 검토할 "능력이나 의도가 없을 수 있다"고 저자들은 지적합니다. 실제로 다양한 출처에서 API 키가 평문으로 저장되거나 인증 취약점이 있는 등의 보안 사고가 보고되었고, 일부는 이미 악의적인 당사자들에 의해 악용되었습니다.

 

[2-1]. 기존 벤치마크의 한계

AI 생성 코드의 보안을 평가하기 위한 여러 벤치마크가 존재합니다. Baxbench, CWEval, SALLM, SecCodePLT, Asleep 등이 대표적인데요. 하지만 저자들은 이러한 벤치마크들이 바이브 코딩의 보안을 평가하기에 부적절하다고 지적합니다. 그 이유는 다음과 같습니다:

 

1) 컨텍스트 제한: 기존 벤치마크들의 컨텍스트는 단일 파일이나 함수에 제한되어 있습니다. 하지만 실제 바이브 코딩은 복잡한 파일 구조를 가진 대규모 프로젝트에서 일반적으로 수행되죠.

2) 단일 턴 벤치마킹: 기존 벤치마크들은 한 번의 생성에서 코드를 생성하는 모델을 벤치마킹하지만, 바이브 코딩은 에이전트가 여러 턴에 걸쳐 수행합니다.

3) 환경 상호작용 부재: 기존 벤치마크의 입력은 텍스트만 포함하지만, 코딩 에이전트는 실행 환경과 상호작용하고 피드백을 받을 수 있습니다.

 

 

이러한 한계를 해결하기 위해, 저자들은 SUSVIBES를 제안합니다. Figure 1은 SUSVIBES의 예제 작업을 보여주는데요. 에이전트는 Docker 환경 내에서 시작되어 기존 레포지토리에 기능을 추가하는 작업을 수행합니다. 에이전트가 액션을 취하고, 환경과 상호작용하며, 피드백을 수집하고, 최종적으로 레포지토리에 패치를 생성합니다. 생성된 솔루션 패치는 정확성과 보안을 대상으로 하는 유닛 테스트로 테스트됩니다.

 

---

[3]. SUSVIBES 벤치마크

본 논문에서 3장부터 본격적인 SUSVIBES 벤치마크 내용을 소개합니다. 

 

잠깐! 본 논문에서 나오는 핵심 용어를 먼저 정리하고 진행해봅시다.

 

용어	설명
Vibe Coding (바이브 코딩)	엔지니어가 자연어로 요청하면 LLM 에이전트가 최소한의 감독 하에 복잡한 코딩 작업을 완료하는 새로운 프로그래밍 패러다임입니다.
CWE (Common Weakness Enumeration)	소프트웨어 및 하드웨어의 보안 취약점 유형을 분류한 표준 목록입니다. 예: SQL 인젝션, XSS, 경로 탐색 등이 각각 고유한 CWE 번호를 가집니다.
FUNCPASS (기능 정확도)	에이전트가 생성한 솔루션이 기능 테스트를 통과하는 비율입니다. 코드가 요구된 기능을 올바르게 구현했는지를 측정합니다.
SECPASS (보안 정확도)	에이전트가 생성한 솔루션이 기능 테스트와 보안 테스트 모두를 통과하는 비율입니다. 기능적으로 올바르면서 보안 취약점이 없는 코드의 비율을 측정합니다.
SECPASS ⊥ FUNCPASS	기능적으로 올바른 솔루션 중에서 보안적으로도 올바른 솔루션의 비율입니다. 기능 정확도와 보안 능력을 분리하여 순수한 보안 성능을 측정합니다.
\(T_{func}\) (기능 테스트)	구현된 기능이 정상적으로 작동하는지 확인하는 테스트입니다. 취약점 수정 전 커밋에서 수집됩니다.
\(T_{secure}\) (보안 테스트)	보안 취약점이 없는지 확인하는 테스트입니다. 취약점 수정 커밋에서 개발자가 추가한 테스트를 수집합니다.
\(C_0\) (취약점 수정 커밋)	보안 취약점이 수정된 커밋입니다. 안전한 코드 상태를 나타냅니다.
\(C_{-1}\) (수정 전 커밋)	취약점 수정 전의 커밋입니다. 취약한 구현을 포함하고 있습니다.
\(C_{-1}^M\) (마스킹된 커밋)	취약했던 기능 구현부가 마스킹(삭제)된 상태의 레포지토리입니다. 에이전트에게 주어지는 초기 작업 입력입니다.

 

[3-1]. 벤치마크 구축 원리

SUSVIBES 작업 생성의 핵심 원리는 다음과 같습니다. 기존 기능 F의 알려진 취약점을 수정하는 커밋 \(C_0\)를 선택하고, 수정 전 커밋 \(C_{-1}\)로 되돌린 후, \(C_{-1}\)에서 취약한 구현으로부터 F를 마스킹하여 \(C_{-1}^M\)을 획득합니다. F가 없는 이 레포지토리에서, 기능을 요청하는 작업을 생성하고 기능 및 보안 테스트를 모두 수집합니다.

 

Figure 2는 이 큐레이션 파이프라인을 보여주는데요. 오픈소스 취약점 커밋을 마이닝하고, 적응적으로 기능 마스크와 작업 설명을 생성하며, 기능 및 보안 테스트를 수집하는 과정을 보여줍니다.

 

[3-2]. 보안 테스트 \(T_{secure}\) 수집

저자들은 ReposVul과 MoreFixes 같은 기존 취약점 수정 데이터셋에서 지난 10년간 20,000개 이상의 오픈소스, 다양한 취약점 수정 커밋을 수집했습니다.

그 중 Python으로 작성된 약 3,000개를 추출했죠. Python 3.7 이상을 사용하는 프로젝트에 집중하여 구버전 및 도구 종속성 문제를 회피했습니다.

또한, 테스트 스위트를 수정하지 않는 커밋은 필터링했는데요. 이는 취약점을 탐지할 수 있는 보안 테스트가 없을 수 있기 때문입니다.

 

단일 취약점 수정 커밋 \(C_0\)에서, 변경사항 P를 두 부분으로 분리합니다:

 

- \(P^F\): F의 구현을 수정하는 부분

- \(P^T\): 테스트 스위트를 수정하는 부분

 

즉, \(P = P^F + P^T\)입니다. \(P^F\)를 사용하여 수정된 기능 F를 식별하고, \(P^T\)에서 추가된 테스트를 잠재적 보안 테스트 \(T_{secure}\)로 수집합니다.

 

[3-3]. 기능 테스트 \(T_{func}\) 수집 및 솔루션 코드 마스킹

취약점 수정 커밋 \(C_0\)에서 \(T_{secure}\)를 수집한 후, 이전 커밋 \(C_{-1}\)로 체크아웃합니다. 이 커밋에는 취약한 F 구현과 해당 기능 테스트 \(T_{func}\)가 포함되어 있죠.

적절한 작업을 합성하기 위해, 저자들은 SWE-Agent를 활용하여 기존 F 구현을 포함하는 최소한의 마스크를 생성합니다.

SWE-Agent는 커밋 \(C_{-1}\)의 코드베이스 내부에서 시작되고, 적용되지 않은 수정 \(P^F\)가 제공됩니다. 그리고 \(P^F\)가 수정하는 기능을 마스킹하도록 지시받습니다. 마스크는 패치 M으로 생성되며 라인 삭제만 포함하고 추가는 없습니다.

M은 그런 다음 \(C_{-1}\)에 적용되어 솔루션 코드 F가 마스킹된 코드베이스 \(C_{-1}^M\)을 획득하며, 이것이 SUSVIBES 작업의 초기 컨텍스트가 됩니다.

 

[3-4]. 작업 설명 생성

구현의 마스크를 얻은 후, 저자들은 두 번째 SWE-Agent 인스턴스를 사용하여 마스킹된 구현 M과 레포지토리를 기반으로 기능 요청을 생성합니다. 이때 중요한 설계 결정이 있는데요. 마스크 M은 \(C_0\)가 아닌 \(C_{-1}\)에서 생성됩니다. 왜냐하면 이렇게 해야 보안 수정 \(C_0\)의 정보가 작업 입력에 누출되어 작업이 더 쉬워지는 것을 방지할 수 있기 때문이죠.

반응형

 

Figure 3은 SWE-Agent를 사용한 세 가지 작업을 수행하는 프롬프트를 보여줍니다:

- Prompt I (Feature Masking): diff 패치 \(P^F\)를 받아 해당 패치를 포함하는 일관된 구현 영역을 삭제하는 마스크 생성

- Prompt II (Task Description Generation): 삭제 마스크 M을 받아 마스킹된 코드의 재구현 요구사항을 지정하는 이슈 스타일 설명 작성

- Prompt III (Mask Verification): 작업 설명과 코드 패치를 받아 패치가 작업 요구사항을 초과하는 구현을 포함하는지 확인

 

[3-5]. 적응적 마스크 검증

생성된 기능 요청이 보안 수정이 포함된 정규 기능 구현을 모두 커버하는지 확인하기 위해, 저자들은 설명을 라인별로 검증하고 적응적으로 마스크를 수정합니다.

 

Figure 4는 이 검증 파이프라인을 보여주는데요. 보안 수정을 포함하는 기능의 정규 구현(Canonical Secure Implementation)의 각 라인이 생성된 작업 설명의 요구사항과 정당화되는지 확인합니다.

생성된 기능 요청이 \(C_0 - C_{-1}^M\)의 모든 라인을 설명하는지 확인하기 위해, 세 번째 SWE-Agent 인스턴스를 사용하여 \(C_0 - C_{-1}^M\)의 각 라인을 기능 요청의 요구사항에 연결합니다.

어떤 구현이 설명이 요구하는 것을 초과하는 경우, 더 큰 마스크를 생성하기 위해 마스크 생성 단계로 돌아갑니다.

이 루프는 생성된 요청이 정규 구현과 일치할 때까지 적응적으로 반복됩니다.

 

[3-6]. 실행 환경 구축

저자들은 각 취약점 수정 커밋 \(C_0\)에서 SWE-Agent를 실행하여 레포지토리의 실행 환경을 구축하고 테스트 스위트를 검증합니다. 특히, 에이전트에게 \(P^T\)의 테스트 위치가 제공되는데, 이는 복잡한 테스트 설정에서 실행해야 하는 핵심 필수 테스트에 대한 힌트입니다.

 

에이전트는 다음 순서로 참조하도록 지시받습니다.

1) 기존 컨테이너 구성, 2) .github/workflows의 CI/CD 파이프라인, 3) 테스트 워크플로를 재현하기 위한 기타 문서.

그리고 성공적인 설치 및 테스트 단계로 새 Docker 이미지를 생성하기 위해 docker 명령을 호출합니다.

저자들은 여러 테스트 스위트 실행 결과 샘플을 기반으로 테스트 출력 파서를 합성하기 위해 LLM을 사용했습니다.

 

[3-7]. 실행 기반 테스트 케이스 검증

실행 결과를 기반으로 보안 및 기능 테스트를 엄격하게 검증하기 위해, 저자들은 다양한 구현과 테스트 스위트 조합을 실행합니다:

\(\{C_0, C_{-1}, C_{-1}^M\} \times \{T_{func}, T_{func} + T_{secure}\}\)

 

유효한 작업은 다음 요구사항을 충족해야 합니다:

(i) 마스킹된 취약 커밋 \(C_{-1}^M\)은 기능 및 보안 테스트 모두 실패해야 함

(ii) 취약한 구현이 있는 코드베이스 \(C_{-1}\)은 기능 테스트 통과, 보안 테스트 실패해야 함

(iii) 취약점 수정 커밋 \(C_0\)는 두 테스트 모두 통과해야 함

 

---

[4]. SUSVIBES 벤치마크 개요

이제 SUSVIBES 벤치마크의 전체적인 특성을 살펴보겠습니다.

Figure 5는 SUSVIBES의 108개 실세계 GitHub 프로젝트가 다양한 도메인에 분포된 것을 파이 차트로 보여줍니다:

 

[4-1]. SUSVIBES의 고유한 특성

1) 실세계 소프트웨어 엔지니어링 작업: 기존 벤치마크의 함수/파일 수준 컨텍스트와 비교하여 평균 162K 라인의 코드를 포함합니다. 에이전트가 방대한 컨텍스트 속에서 여러 파일에 걸쳐 더 많은 라인을 식별하고 편집해야 합니다. 이러한 특성이 SUSVIBES 작업을 더 도전적으로 만들죠.

2) 다양한 애플리케이션 도메인과 취약점: SUSVIBES는 77개 CWE 유형을 포함하는데, 이는 현재 레포지토리 벤치마크보다 7배 이상입니다. 2%의 작업은 분류할 수 없는 취약점을 검토합니다. 또한 10개 실세계 애플리케이션 도메인을 포괄하여 다양한 사용 사례에서 바이브 코딩의 보안 관행을 평가할 수 있습니다.

3) 확장성과 확장 가능성: 완전 자동화된 큐레이션 파이프라인으로 더 많은 레포지토리 및 추가 프로그래밍 언어로 자연스럽게 확장할 수 있습니다. 새로운 공개 기록된 취약점은 취약 커밋으로 추적하여 SUSVIBES에 쉽게 적응할 수 있죠.

 

---

[5]. 실험 설정 및 결과

이제 논문의 핵심 실험 부분입니다. 실험은 핵심적인 것만 정리하고 진행하도록 하겠습니다.

 

[5-1]. 실험 설정

저자들은 3개의 대표적인 에이전트 프레임워크와 3개의 프론티어 에이전틱 LLM을 조합하여 실험을 수행했습니다:

 

에이전트 프레임워크:

- SWE-Agent: Princeton에서 개발한 대표적인 소프트웨어 엔지니어링 에이전트

- OpenHands: 오픈 플랫폼 기반 AI 소프트웨어 개발자 에이전트

- Claude Code: Anthropic의 커맨드라인 에이전틱 코딩 도구

 

LLM 백본:

- Claude 4 Sonnet: Anthropic의 최신 모델

- Kimi K2: Moonshot AI의 모델

- Gemini 2.5 Pro: Google DeepMind의 모델

 

에이전트 프레임워크는 LLM과 함께 작업 레포지토리를 검사하고 기능 요구사항에 따라 새로운 기능을 구현합니다. 또한 구현을 실행하고 런타임 환경 피드백을 사용하여 솔루션을 수정할 수 있습니다. 각 에이전트 프레임워크의 기본 권장 시스템 프롬프트를 사용하고 최대 스텝을 200으로 설정했습니다.

에이전트의 기능 및 보안 성능을 평가하기 위해 FUNCPASS와 SECPASS를 사용합니다. 실세계 바이브 코딩 사용을 반영하기 위해 pass@1을 사용하는데요. 사용자가 일반적으로 모델이 즉시 올바른 코드를 생성하기를 원하기 때문입니다. 하나의 솔루션이 의미 있는 기능을 구현하지 않으면 항상 안전할 수 있으므로, 기능적으로 올바른 솔루션의 보안만 고려합니다. 기본적으로 각 문제 설명 끝에 일반적인 보안 알림을 추가합니다.

 

[5-2]. 주요 실험 결과

Table 3은 세 가지 코딩 에이전트와 세 가지 모델의 기능 및 보안 측면 평가 성능을 보여줍니다.

 

인사이트 1: 실세계 레포지토리에서 새로운 기능 구현은 현재 에이전틱 시스템에게 여전히 도전적입니다.

최고의 에이전틱 시스템인 SWE-Agent + Claude 4조차 약 절반의 작업만 기능적으로 올바른 솔루션으로 해결할 수 있습니다.

LLM 백본을 비교하면, Claude 4가 일관되게 다른 두 모델을 능가하고, Gemini 2.5 Pro가 가장 낮은 성능을 보입니다.

에이전트 시스템 측면에서는 SWE-Agent와 OpenHands가 서로 다른 백본에서 우위를 보입니다.

 

인사이트 2: 모든 프론티어 에이전트 시스템이 보안 측면에서 매우 저조한 성능을 보입니다.

FUNCPASS와 비교하여 평균 SECPASS는 약 10%에 불과합니다. 최고의 기능 성능을 보인 접근법인 SWE-Agent + Claude 4 Sonnet은 61%의 작업을 해결했지만, 이 기능적으로 올바른 솔루션의 82.8%가 보안에 취약합니다.

OpenHands + Claude가 최고 SECPASS 점수 12.5%를 기록했지만, FUNCPASS 점수를 고려하면 여전히 74.7%의 올바른 솔루션이 보안에 취약합니다.

 

인사이트 3: Gemini 2.5 Pro가 가장 보안적인 LLM이고, OpenHands가 SWE-Agent보다 더 보안적입니다.

기능 정확도와 보안 능력을 분리하기 위해 기능적으로 올바른 부분집합에서 SECPASS ⊥ FUNCPASS를 계산했습니다:

 

LLM 비교 (OpenHands 사용, 세 LLM이 공통으로 올바르게 해결한 작업에서):

- Claude 4 Sonnet: 17.2%

- Kimi K2: 20.7%

- Gemini 2.5 Pro: 27.6% (가장 보안적)

 

에이전트 프레임워크 비교 (Gemini 2.5 Pro 사용):

- SWE-Agent: 8.9%

- OpenHands: 19.4% (가장 보안적)

- Claude Code: 10.4%

 

인사이트 4: 에이전트 프레임워크와 LLM이 서로 다른 CWE 유형에 주의를 기울입니다.

저자들은 CWE별 보안 성능을 더 세분화하여 분석했습니다. SUSVIBES의 작업을 CWE 태그로 분류하고 각 카테고리에서 SECPASS ⊥ FUNCPASS를 계산했죠.

에이전트의 특정 카테고리에서 SECPASS ⊥ FUNCPASS가 25%를 초과하면, 해당 에이전트가 이 CWE에 주의를 기울이고 기능을 구현할 때 이 CWE를 피할 가능성이 상대적으로 높다고 간주합니다.

 

Figure 6은 이러한 주의하는 CWE의 에이전트 간 분포와 겹침을 보여줍니다. 세 백본 LLM 간 58%의 CWE가 겹치지 않는다는 것을 발견할 수 있는데요. 이는 이러한 LLM들이 서로 다른 취약점 처리에 능숙함을 의미합니다.

같은 LLM에서도 에이전트 프레임워크가 처리할 수 있는 CWE에 영향을 미치지만, LLM만큼 차별화되지는 않습니다.

 

인사이트 5: 같은 CWE 태그를 가진 작업에서도 에이전트 보안 성능이 다릅니다.

저자들은 또한 같은 CWE 태그를 가진 작업에서 에이전트의 성능을 비교했습니다. Table 4는 유사한 취약점 유형을 가진 4개 프로젝트에서 Claude 4 Sonnet과 Gemini 2.5 Pro의 FUNCPASS와 SECPASS ⊥ FUNCPASS를 분석합니다.

Claude가 일관되게 더 나은 FUNCPASS를 보이지만, Gemini보다 더 안전한 구현을 보장하지는 못합니다. 예를 들어 django 프로젝트에서 Claude 4 Sonnet은 FUNCPASS 58.8%를 달성했지만 SECPASS ⊥ FUNCPASS는 0%인 반면, Gemini 2.5 Pro는 FUNCPASS 17.7%이지만 SECPASS ⊥ FUNCPASS는 100%입니다.

---

[6]. 구체적인 취약점 사례

저자들은 에이전트가 생성한 취약한 코드의 부분집합을 검토하여 구체적인 보안 위험을 더 잘 이해하려고 했습니다.

논문에서 소개한 주요 사례들을 살펴보겠습니다.

 

[6-1]. Django verify_password() 타이밍 공격 사례

Figure 7은 SWE-Agent + Claude 4 Sonnet이 Django의 기능을 구현하기 위해 제안한 솔루션을 보여줍니다. 이 솔루션은 기능적으로 올바르지만 보안에 취약합니다.

 

작업: verify_password() 함수 구현 - 저장된 해시에 대해 후보 평문 비밀번호를 검증하는 내부 헬퍼

보안 문제: 타이밍 사이드 채널 공격

 

에이전트 생성 취약 코드:

def verify_password(password, encoded, preferred="default"):
    if password is None:
        return False, False
    if not is_password_usable(encoded):
        return False, False
    ...

 

문제점: 비밀번호가 None이거나 사용 불가능한 경우 즉시 반환합니다. 이로 인해 존재하지 않는 사용자명과 비교하여 측정 가능하게 더 빠른 응답이 생성됩니다. 공격자가 이 타이밍 차이를 기반으로 유효한 사용자명을 열거할 수 있습니다.

 

올바른 구현:

def verify_password(password, encoded, preferred="default"):
    fake_runtime = password is None or not is_password_usable(encoded)
    ...
    except ValueError:
        fake_runtime = True
    if fake_runtime:
        make_password(get_random_string(UNUSABLE_PASSWORD_SUFFIX_LENGTH))
        return False, False
    is_correct = hasher.verify(password, encoded)
    ...

 

보안 수정: fake_runtime 플래그를 사용하여 항상 hasher.verify나 make_password를 호출하여 거의 일정한 시간 내에 실행되도록 보장합니다.

실제 영향: 이러한 취약점은 타겟팅된 피싱 캠페인, 크리덴셜 스터핑 공격, 계정 탈취 시도로 이어질 수 있으며, 스팸 이메일 및 기타 최종 사용자에게 영향을 미치는 보안 사고를 초래할 수 있습니다.

---

[7]. 보안 위험 완화 시도

이전 실험에서 저자들은 에이전트에게 코드 보안에 대해 상기시키기 위해 일반적인 보안 지침을 추가했습니다. 하지만 실험 결과는 코드 에이전트가 여전히 보안 솔루션을 제공하는 데 어려움을 겪는다는 것을 보여주었죠. 이 섹션에서 저자들은 보안 문제를 쉽게 완화할 수 있는지 확인하기 위해 두 가지 예비 보안 강화 전략을 추가로 조사했습니다.

 

[7-1]. 세 가지 완화 전략

1) Generic: 일반적인 보안 지침을 프롬프트에 추가합니다.

2) Self-selection: 에이전트가 구현 전 잠재적 보안 위험을 식별하도록 합니다. 전문가가 구현 전 기능 요구사항을 기반으로 잠재적 보안 위험을 식별하는 것에서 영감을 받았죠. 여기서는 2단계 코딩 프로세스를 조사하도록 합니다. 먼저 에이전트가 문제와 컨텍스트에서 관련 취약점 유형을 식별하고, 그런 다음 식별된 위험을 염두에 두고 코드를 구현하도록 요청합니다. 에이전트에게 SUSVIBES가 다루는 전체 CWE 목록과 정의를 제공하고, 각 작업에서 가장 관련 있는 CWE를 선택하도록 합니다.

3) Oracle: 이 작업이 목표로 하는 실제 취약점 유형을 제공하고 기능을 구현할 때 이 취약점을 피하도록 에이전트에게 명시적으로 요청합니다.

 

[7-2]. 완화 결과

Table 5는 Self-selection과 Oracle 보안 전략이 Generic 기준선에 미치는 영향을 보여줍니다.

 

보안 위험을 해결하기 위해 에이전트에게 더 많은 보안 지침을 제공하면, 두 향상된 설정 모두에서 에이전트 솔루션의 기능 정확도가 크게 하락합니다. 게다가 보안 성능도 놀랍게도 하락합니다. 이 결과는 에이전트에게 추가 보안 프롬프트를 제공할 때 두 가지 상반된 경향의 결합 효과로 인해 발생합니다.

 

(1) 프롬프트가 에이전트의 보안 위험 인식 및 방어 능력을 향상시켜 이전에 올바르지만 보안 취약했던 작업을 이제 안전하게 해결

(2) 이전에 올바르게 해결된 작업이 에이전트가 보안에 과도하게 집중하면서 기능적 엣지 케이스를 누락하여 오류 발생 (보안적이든 취약하든)

Figure 8은 이 두 가지 경향을 정량화하여 보여줍니다. 전략이 기능에 관계없이 에이전트의 보안을 완화하지만, 더 많은 안전→오답 변경을 야기하여 성능이 하락합니다. Oracle이 Self-selection보다 더 심각한 이유는 위험 식별이 어느 정도 문제 이해에 도움이 되기 때문일 수 있습니다.

 

[7-3]. 에이전트의 보안 위험 식별 능력

Self-selection이 왜 더 나쁜 성능을 보이는지 조사하기 위해, 저자들은 코드 에이전트가 올바른 CWE를 선택하는 성능을 평가했습니다.

Table 7은 생성된 솔루션이 보안적일 때 에이전트가 위험에 대한 인식이 더 명확함을 보여줍니다.

 

평균적으로 에이전트는 각 작업에 대해 7.5개의 관련 CWE를 선택합니다. 올바르지만 보안 취약한 솔루션(INSEC.)과 비교하여, 올바르고 안전한 솔루션은 유의미하게 더 높은 CWE 선택 재현율을 보입니다. 이는 올바르게 식별된 CWE가 더 안전한 솔루션 제공에 도움이 됨을 시사합니다.

 

반면, 작업당 평균 1.06개의 실제 CWE가 있지만, 선택된 7.5개 CWE가 목표 CWE를 커버하지 못합니다 (최대 재현율 0.737). 이는 현재 코드 에이전트가 작업 설명을 기반으로 잠재적 보안 위험을 식별하는 데 여전히 어려움을 겪고 있음을 나타냅니다.

 

---

[8]. 논문의 한계점

저자들은 논문의 한계점을 다음과 같이 인정합니다.

1) Python 생태계 중심: 현재 Python 프로젝트에만 집중하고 있습니다.

2) 테스트 결과를 보안의 프록시로 사용: 실제 보안보다는 테스트 통과를 기준으로 사용합니다.

3) CWE 주석과 테스트의 불충분 가능성: 모든 취약점을 완전히 커버하지 못할 수 있습니다.

4) 모든 익스플로잇 모달리티 미커버: 일부 공격 유형이 누락될 수 있습니다.

 

후속 연구 방향으로는 언어 및 도메인 커버리지 확대, 속성 기반 및 적대적 테스트 합성을 통한 동적 평가 강화, 정적/의미론적 프로그램 분석 통합, 보안 인식 보상 등의 학습 시간 신호 연구, 퍼저, 오염 분석, 비밀 스캐너 등의 도구 사용 연구를 제안합니다.

---

마무리

이번 포스팅은 Carnegie Mellon University 연구진이 발표한 "Is Vibe Coding Safe?" 논문을 리뷰하였습니다. 바이브 코딩이라는 새로운 프로그래밍 패러다임의 보안 위험을 평가하기 위한 SUSVIBES 벤치마크와 프론티어 코딩 에이전트들의 보안 취약점 분석 결과를 살펴보았습니다.

 

비록 부족한 글이지만, AI 코딩 도구의 보안에 관심 있으신 분들에게 도움이 되시길 바랍니다.

긴 글 읽어주셔서 감사합니다.