기술 요약: LLM 생성 코드의 보안: 비교 분석

문제 제기

소프트웨어 개발 분야에서 대규모 언어 모델 (LLM) 의 급속한 도입은 소프트웨어 보안과 관련하여 중대한 우려를 야기했습니다. 개발자들이 생산성 향상과 학습 가속화를 위해 AI 도구를 활용하고 있지만, 이러한 도구가 치명적인 보안 취약점을 포함하는 코드를 생성할 위험이 커지고 있습니다. 이전 연구들은 개발자들이 종종 AI 가 생성한 코드의 보안을 자신들이 작성한 코드에 비해 과도하게 신뢰하는 경향이 있음을 나타냈습니다. 주요 기술 조직을 포함한 프로덕션 환경에 AI 생성 코드가 존재함에도 불구하고, 다양한 인기 있는 LLM 이 생성한 코드의 보안 상태에 대한 포괄적이고 비교적인 실증 분석은 부족합니다. 본 논문은 현재 AI 코드 생성 도구와 관련된 보안 위험을 평가하고, 서로 다른 모델들이 취약점 생성 측면에서 어떻게 비교되는지 규명하기 위한 시급한 필요성에 대응합니다.

방법론

저자들은 7 개의 인기 있는 LLM( Claude 3, Perplexity AI, OpenAI GPT-4o, Google Gemini, Phind-70B, Amazon CodeWhisperer, IBM watsonx ) 이 생성한 코드의 보성을 평가하는 실증 연구를 수행했습니다.

실험 설계

1. 데이터셋 선정: 본 연구는 MITRE 가 식정한 상위 25 개 공통 약점 목록 (CWE) 중 12 개에 취약한 Python 코드를 생성하도록 설계된 81 개의 자연어 (NL) 프롬프트 모음인 LLMSecEval 데이터셋을 활용했습니다. 프롬프트는 보안 결함을 명시적으로 언급하지 않고 일반적인 개발자 상호작용을 시뮬레이션하도록 선정되었습니다 (예: 유효성 검사 요구사항을 명시하지 않고 파일 업로드 함수를 요청하는 경우).
2. 코드 생성: 연구자들은 7 개의 LLM 각각에 동일한 81 개의 프롬프트를 입력하여 코드 스니펫을 생성하게 했습니다. 4 개의 도구는 자동화를 위해 API 를 통해 접근했고, 나머지 3 개는 수동으로 프롬프트를 입력했습니다.
3. 취약점 탐지: 취약점을 식별하기 위해 하이브리드 정적 분석 접근 방식을 사용했습니다.
   • CodeQL: GitHub 의 오픈소스 정적 분석 쿼리를 사용하여 CWE 의 하위 집합을 스캔했습니다.
   • GPT-4o: CodeQL 쿼리로 커버할 수 없는 나머지 CWE 를 탐지하는 데 사용되었습니다. 저자들은 CWE-306, CWE-434, CWE-522 와 같은 취약점에 대한 높은 신뢰도의 탐지를 보장하기 위해 특정 프롬프트 엔지니어링 기법 ( "CWE 탐지기"로서의 역할 정의 및 지시 사항 강화) 을 활용했습니다.
4. 심각도 등급: 취약점은 GitHub 의 심각도 등급 방식을 사용하여 심각도 (Critical, High, Medium, Low) 에 따라 분류되었으며, 이 방식은 National Vulnerability Database (NVD) 와 CodeQL 데이터의 CVSS 점수를 집계합니다.

주요 결과

본 연구는 567 개의 코드 스니펫 (81 개 프롬프트 × 7 개 모델) 을 분석하여 총 995 개의 취약점을 식별했습니다.

취약점 발생률

• 보편적 취약점: 7 개의 LLM 모두 취약점이 포함된 코드를 생성했습니다.
• 심각도: 식별된 취약점의 대다수는 Critical(33%) 또는 High(65%) 심각도였습니다.
• 스니펫 위험: 생성된 모든 코드 스니펫 중 73% 이상이 적어도 하나의 취약점을 포함하고 있었습니다. 7 개 도구 중 6 개는 스니펫의 85~90% 가 취약했습니다.
• 도구 비교:
  • Claude 3는 총 173 개의 취약점을 생성하여 가장 많은 수의 취약점을 발생시켰습니다.
  • Amazon CodeWhisperer는 총 98 개의 취약점을 생성하여 가장 적었으며, 취약한 스니펫의 비율도 73% 로 가장 낮았습니다.
  • IBM watsonx는 총 수 (120 개) 가 낮음에도 불구하고 코드 라인당 취약점 발생률이 가장 높았으며, Critical 심각도 취약점의 비율 (모든 Critical 발견 사항의 18.6%) 이 가장 높았습니다.

일반적인 취약점

분석은 다음과 같은 특정 반복적 문제를 강조했습니다.

• CWE-200 (민감 정보 노출): 가장 빈번한 취약점 (381 건) 으로, Flask 애플리케이션에서 디버그 모드를 활성화하거나 스택 트레이스를 노출하는 것이 주된 원인이었습니다.
• CWE-522 (불충분하게 보호된 자격 증명): 210 건으로, 평문 비밀번호 저장, 소금 (salting) 부재, 또는 비밀번호 입력을 위한 input() 함수 사용과 관련된 경우가 많았습니다. 많은 모델이 비밀번호 저장에 SHA-256 을 사용했는데, 저자들은 그 속성 때문에 비밀번호 저장에는 권장되지 않는다고 지적했습니다.
• CWE-434 (제한 없는 파일 업로드): 130 건으로, 파일 내용이나 구조를 검증하지 않고 확장자 검사에만 의존하는 코드였습니다.
• CWE-798 (하드코딩된 자격 증명): 소스 코드에 직접 포함된 자격 증명의 82 건 사례였습니다.

코드 품질에 대한 관찰

• 기능성 대 보안: 연구는 모델들이 종종 보안보다 기능성을 우선시한다고 지적했습니다. 예를 들어, watsonx 는 명령어 주입을 초래하는 os.system 을 직접 호출하는 간결한 코드 (7 줄) 를 생성한 반면, CodeWhisperer 는 입력 정제를 포함한 더 장황한 코드 (43 줄) 를 생성했습니다.
• 보안에 대한 잘못된 확신: 일부 경우 모델들은 보안이 취약한 코드를 생성하면서도 그 취약성을 인정하는 주석을 추가했습니다 (예: "#This is HIGHLY insecure"). 그럼에도 불구하고 해당 취약한 코드를 주요 해결책으로 출력했습니다.

주요 기여

1. 비교 평가: 본 작업은 표준화된 데이터셋을 사용하여 7 개의 서로 다른 인기 있는 LLM 이 생성한 코드의 보성을 비교 분석한 최초의 연구입니다.
2. 하이브리드 탐지 방법: 저자들은 정적 분석만으로는 커버할 수 없는 더 넓은 범위의 CWE 를 포괄하기 위해 CodeQL 정적 분석과 LLM 기반 탐지 (GPT-4o) 를 결합한 방법론을 개발했습니다.
3. 위험에 대한 실증적 증거: 본 연구는 최첨단 모델이 생성한 프로덕션 준비형 코드에서 Critical 및 High 심각도 취약점이 고르게 퍼져 있음을 정량화하여, 새로운 모델이 본질적으로 더 안전한 코드를 생성한다는 가정을 도전합니다.
4. 간단한 수정 사항 식별: 저자들은 모델 행동의 구체적이고 간단한 변경이 취약점 발생률을 극적으로 낮출 수 있음을 식별했습니다. 예를 들어, 디버그 모드를 기본적으로 비활성화하고 SHA-256 대신 권장되는 비밀번호 해시 알고리즘 (Argon2id 또는 bcrypt 등) 을 사용하는 것은 식별된 취약점의 상당 부분을 제거할 수 있습니다.

중요성과 주장

본 논문은 현재 LLM 생성 코드 보안의 상태가 "놀라울 정도 (staggering)"라고 주장하며, 이러한 도구들이 생성하는 취약한 코드의 양이 많기 때문에 소프트웨어 보안에 있어 현재는 "축복"이 아니라 "저주"가 될 수 있다고 시사합니다.

저자들은 다음과 같이 주장합니다.

• 보안은 암묵적이지 않다: 대부분의 개발자가 깊은 보안 전문 지식을 갖추지 못하고 효율성을 추구하기 때문에, 개발자가 수동으로 보안을 검증하거나 명시적으로 안전한 코드를 요청하도록 의존하는 것은 비현실적입니다.
• 모델 아키텍처의 변화 필요: 본 연구는 소프트웨어 보안 원칙을 LLM 의 훈련 데이터와 모델 아키텍처에 직접 통합해야 할 시급한 필요성을 강조합니다. 보안은 사용자가 프롬프트를 입력해야만 활성화되는 선택적 기능이 아니라 기본 제약 조건이어야 합니다.
• 개발자의 책임: 도구가 개선되고 있지만, "개발자는 여전히 루프 안에 갇혀" 있으며, 기본적으로 종종 보안이 취약한 코드를 검증하도록 강요받고 있습니다. 본 논문은 보안 원칙을 모델 자체에 명시적으로 통합하지 않는 한, AI 도입이 증가함에 따라 취약한 코드의 확산이 계속될 것이라고 제안합니다.

저자들은 LLM 이 생산성 향상의 이점을 제공하지만, 현재 생성되는 출력물은 모델 개발자와 광범위한 소프트웨어 엔지니어링 커뮤니티의 즉각적인 주의를 요구하는 중대한 보안 위험을 내포한다고 결론지었습니다.