기술 요약: 개발자가 보안한 IaC 개발을 위해 LLM에 의존할 수 있는가?

문제 정의

인프라 자동화 관리에 필수적인 인프라 코드(IaC)는 하드코딩된 비밀값, 취약한 암호화, 유효하지 않은 IP 바인딩과 같이 보안 관행의 부재를 나타내는 반복적인 패턴인 "보안 스멜(security smells)"로 인해 빈번하게 문제가 발생합니다. 이러한 문제를 탐지하기 위해 전문화된 도구(예: SLIC, SLAC)가 존재하지만, 그 채택률은 여전히 낮습니다. 동시에 개발자들은 코딩 보조를 위해 대규모 언어 모델(LLM)을 점점 더 많이 도입하고 있습니다. 본 연구는 기존 IaC 스크립트에서 보안 스멜을 효과적으로 탐지하고, 처음부터 보안한 IaC를 생성할 수 있는 독점적 LLM(특히 GPT-4o 및 Gemini 2.0 Flash)의 능력에 관한 실증적 근거가 부족하다는 핵심적인 공백을 다룹니다. 저자들은 LLM이 경고를 발행하지 않은 채 기능적으로는 작동하지만 잠재적으로 심각한 취약점(예: 하드코딩된 비밀번호, TLS 없는 HTTP)을 포함하는 코드를 생성하여, 개발자에게 잘못된 보안 신뢰감을 줄 수 있다는 구체적인 위험성을 강조합니다.

방법론

본 연구는 두 가지 서로 다른 데이터셋(Stack Overflow 코드 스니펫 및 실제 GitHub 저장소)을 활용하여 두 단계의 실증적 접근 방식을 채택합니다.

1. 데이터셋 및 범위

• 도구: 본 연구는 가장 널리 사용되는 IaC 도구인 Ansible(명령형)과 Puppet(선언형)에 초점을 맞춥니다.
• 보안 스멜: 평가는 하드코딩된 비밀값, 빈 비밀번호, 취약한 암호화(SHA1/MD5), 기본 설정의 관리자 권한, TLS 없는 HTTP, 무결성 검사 누락, 잘못된 IP 바인딩(0.0.0.0), 의심스러운 주석, 기본 케이스 문 누락을 포함한 9가지 특정 보안 스멜(S1–S9)을 대상으로 합니다.
• Stack Overflow 연구:
  • 데이터: 키워드 검색(예: "password", "HTTP", "TODO")을 통해 필터링된 Ansible 또는 Puppet 태그가 달린 2,569개의 SO 포스트를 사용했습니다.
  • Ground Truth: 두 명의 연구자가 스니펫을 수동으로 검토하여 169개의 보안 취약 사례를 식별했습니다. 연구자 간 신뢰도(Cohen's kappa = 0.93)는 높았습니다.
• GitHub 연구:
  • 데이터: 최신 문헌의 복제 패키지와 직접적인 GitHub 검색을 통해 총 21,757개의 파일을 수집했습니다.
  • 샘플링: 430개의 파일(문헌 기반 302개, 검색 기반 128개)로 구성된 대표적인 하위 집합을 수동으로 분류하였으며, 그 결과 341개의 보안 스멜 사례가 발견되었습니다.
  • 합성 시나리오: 이 341개의 보안 취약 패턴을 바탕으로, 코드 생성 능력을 테스트하기 위한 89개의 고유한 합성 시나리오를 설계했습니다.

2. 실험 설계

본 연구는 두 가지 프롬프트 조건 하에서 LLM을 평가합니다:

1. 일반 프롬프트(General Prompt): 코드를 보안 관점에서 분석해 달라는 표준 요청(예: "보안 전문가로서 다음 코드를 분석해 주세요...")입니다.
2. 가이드 프롬프트(Guided Prompt): 도구를 식별하고, 스멜 목록을 작성하며, 코드와 주석을 정밀하게 검토하고, 결과를 특정 CSV 형식으로 출력하도록 요구하는 구조화된 단계별 지침입니다. 이는 장황함을 줄이고 환각 현상을 줄이기 위해 설계되었습니다.

평가 과업:

• 탐지(Detection): 제공된 코드 스니펫에서 기존 보안 스멜을 식별하는 모델의 능력을 평가합니다.
• 수정 제안(Fix Suggestion): 모델이 실행 가능한 코드 수정안을 제공하는지, 아니면 일반적인 권장 사항만을 제공하는지 분석합니다.
• 생성(Generation): 89개의 합성 시나리오를 사용하여 IaC 스크립트를 생성하도록 프롬프트를 입력하고, 보안한 출력의 비율과 보안 취약 패턴에 대해 경고를 발행하는 빈도를 측정합니다.

주요 결과

보안 스멜 탐지

• Stack Overflow (작은 스니펫):
  • 일반 프롬프트: GPT-4o는 80%, Gemini는 71%의 스멜을 탐지했습니다.
  • 가이드 프롬프트: 성능이 향상되어 GPT-4o는 88%, Gemini는 78%를 기록했습니다.
• GitHub (실제 프로젝트):
  • 일반 프롬프트: 성능이 크게 하락했습니다. GPT-4o는 42%, Gemini는 51%의 스멜만을 탐지했습니다.
  • 가이드 프롬프트: GPT-4o의 F1 점수는 58%에서 89%로 상승했으며, Gemini의 F1 점수는 66%에서 74%로 증가했습니다.
  • 관찰 사항: 탐지율은 Ansible(명령형/YAML 기반)보다 Puppet(선언형)에서 일관되게 높았는데, 이는 Puppet의 엄격한 구조가 패턴 인식을 돕기 때문인 것으로 보입니다.
• 특정 스멜: "의심스러운 주석(S8)"의 탐지는 가이드 프롬프트를 사용하더라도 특히 어려웠던 반면, "TLS 없는 HTTP(S5)"는 더 안정적으로 탐지되었습니다.

보안 코드 생성

• 기본 성능: 보안 제약 조건 없이 취약점이 발생하기 쉬운 시나리오에 대해 코드를 생성하도록 요청했을 때, **단 7%**의 생성된 스크립트만이 완전히 보안한 상태였습니다.
  • GPT-4o 출력의 75%, Gemini 출력의 56%가 경고 없이 보안 스멜을 포함하고 있었습니다.
• 명시적 보안 지침: "보안한 코드를 생성하라"고 명시적으로 요청했음에도 불구하고:
  • GPT-4o 출력의 17%, Gemini 출력의 **8%**만이 완전히 보안했습니다.
  • 상당 부분(GPT-4o 44%, Gemini 34%)이 여전히 보안 스멜을 포함하면서도 아무런 경고를 동반하지 않았습니다.
• 수정 제안: 모델들은 일반적인 권장 사항(93–96%)은 자주 제공했지만, 명시적인 코드 수정안을 제공하는 경우는 드물었습니다 (GPT-4o: 15%, Gemini: 5%).

의의 및 주장

본 논문은 LLM이 구조화된 프롬프트에 의해 가이드될 경우 IaC의 보안 스멜을 탐지하는 보조 도구로서 유망한 가능성을 보여주지만, 현재로서는 보안한 IaC 개발을 위한 독립적인 도구로 신뢰할 수 없다고 주장합니다.

• 프롬프트 민감도: LLM의 효과는 프롬프트 엔지니어링에 크게 의존합니다. 일반적인 프롬프트는 복잡한 실제 저장소에서 보안 문제의 절반 이상을 탐지하는 데 실패하는 경우가 많습니다.
• 생성 위험: 가장 중요한 발견은 보안한 코드 생성에서의 높은 실패율입니다. 모델들은 명시적으로 보안을 요청받았음에도 불구하고, 취약점을 알리지 않은 채 보안하지 않은 코드를 빈번하게 생성합니다. 이는 개발자들이 "잘못된 보안 신뢰감"을 갖게 될 위험이 있음을 시사합니다.
• 맥락적 한 한계: LLM은 Puppet의 선언적 엄격함에 비해 Ansible의 유연함에 더 어려움을 겪으며, 전체 규모의 프로젝트 스크립트(GitHub)보다 단순화된 스니펫(SO)에서 더 나은 성능을 보입니다.

저자들은 이 분야의 LLM 역량을 개선하기 위해 추가적인 연구가 필요하다고 결론짓습니다. 저자들은 개발자가 보안 보장을 위해 LLM에만 의존해서는 안 된다는 점을 강조하며, 이러한 위험을 완화하기 위해 프롬프트 전략과 도구를 발전시켜야 한다고 강조합니다. 저자들은 향후 연구를 촉진하기 위해 89개의 합성 시나리오를 포함한 복제 패키지를 공개했습니다.