새로운 방식 (LLM 도입): 이제 요리사가 "오늘 뭐 먹지?"라는 말 (프롬프트) 에 따라 스스로 재료를 고르고, 칼을 들고, 심지어 가스불까지 조절합니다.
이 연구는 **GitHub(소프트웨어의 재료를 파는 대형 마트)**에서 발견된 **295 개의 '위험 경고장 (보안 고지)'**을 분석했습니다.
🔍 연구의 핵심 질문과 발견
1. "새로운 종류의 칼날이 생겼을까?" (RQ1)
연구진은 AI 요리사가 사용하는 도구에서 아예 새로운 종류의 위험이 생겼는지 확인했습니다.
결과: 아니요, 새로운 칼날은 없었습니다.
비유: AI 요리사가 칼을 잘못 쓰면 손가락을 베는 건, 일반 요리사가 칼을 잘못 쓰면 손가락을 베는 것과 똑같은 위험입니다.
실제 발견: 가장 흔한 문제는 여전히 **'주입 공격 (Injection)'**과 **'데이터 해체 (Deserialization)'**였습니다. 즉, AI 가 들어갔다고 해서 보안의 기본 원리가 바뀌진 않았습니다.
2. "경고장에는 AI 의 위험이 다 적혀 있을까?" (RQ2)
지금까지의 '위험 경고장'은 **"이 칼날이 녹슬었다"**는 것만 적혀 있었습니다.
문제점: 하지만 AI 요리사의 경우, **"이 녹슨 칼날로 AI 가 실수로 가스불을 켜서 집을 태울 수 있다"**는 연쇄적인 위험은 경고장에 적혀 있지 않았습니다.
결론: 기존 시스템은 코드 (칼날) 의 결함만 보고, **AI 가 그 결함을 어떻게 악용할지 (연쇄 반응)**는 놓치고 있었습니다.
3. "실제 위험은 어떤 형태로 나타날까?" (RQ3)
연구진은 100 개의 사례를 자세히 분석해서 OWASP(보안 전문가들이 만든 AI 위험 목록) 기준으로 다시 분류했습니다.
가장 큰 위험 3 가지:
공급망 위험 (44%): "내가 산 재료가 이미 오염되어 있었다." (타사 라이브러리 문제)
과도한 권한 (20%): "AI 요리사에게 집 전체의 열쇠를 줬다." (AI 가 필요 이상으로 중요한 작업을 할 수 있음)
프롬프트 주입 (18%): "누군가 AI 에게 속여서 '불을 켜라'고 명령했다." (사용자의 말을 AI 가 오해하거나 해커가 조작함)
재미있는 점: 위험은 하나만 있는 게 아니라, **"재료가 오염되어 (공급망) → AI 가 그걸로 무언가를 하려다가 (과도한 권한) → 해커의 속임수에 걸려서 (프롬프트 주입)"**처럼 연쇄적으로 발생합니다.
4. "두 가지 지도를 합쳐야 한다" (RQ4)
기존 지도 (CWE): "칼날이 녹슬었다." (기술적 결함)
새 지도 (OWASP): "AI 가 그 녹슨 칼로 가스불을 켤 수 있다." (구조적 위험)
결론:이 두 가지를 모두 봐야만 진짜 위험을 알 수 있습니다. 하나만 보면 위험의 절반만 본 셈이 됩니다.
💡 이 연구가 우리에게 주는 교훈
새로운 괴물은 없다, 하지만 새로운 '상황'이 있다: AI 를 도입한다고 해서 완전히 새로운 종류의 해킹이 생긴 건 아닙니다. 하지만 AI 가 개입되면서, 기존에 작았던 문제가 더 큰 재앙으로 번질 수 있는 경로가 생겼습니다.
경고장 (보안 고지) 을 더 똑똑하게 만들어야 한다: 지금의 보안 경고는 "이 부품이 고장 났다"만 알려줍니다. 앞으로는 **"이 부품이 고장 나면 AI 가 어떻게 오작동해서 큰일 날 수 있다"**는 내용도 함께 적혀야 합니다.
안전하려면 '코드'와 '구조'를 동시에 봐야 한다: 소프트웨어를 만들 때, 단순히 코드가 안전한지 (CWE) 확인하는 것뿐만 아니라, AI 가 그 코드를 어떻게 쓰는지, AI 가 어떤 권한을 가지는지 (OWASP) 도 함께 점검해야 안전합니다.
📝 한 줄 요약
"AI 가 들어간 소프트웨어의 보안은 '새로운 칼날'을 찾는 게 아니라, '기존 칼날이 AI 의 손에 들렸을 때 어떤 재앙을 부를지'를 예측하는 게임이다. 그리고 지금의 보안 경고장은 그 게임의 절반만 보여주고 있다."
이 연구는 앞으로 보안 전문가들과 개발자들이 코드 레벨의 결함과 AI 시스템의 구조적 위험을 모두 고려해야 함을 강력하게 주장하고 있습니다.
1. 연구 배경 및 문제 제기 (Problem)
대형 언어 모델 (LLM) 이 오픈소스 소프트웨어 (OSS) 생태계에 통합되면서, 자연어 프롬프트, 확률적 모델 출력, 실행 가능한 컴포넌트 간의 복잡한 상호작용이 발생하고 있습니다. 그러나 기존 취약점 공개 프레임워크 (GitHub Security Advisories, GHSA) 가 이러한 모델 매개 (model-mediated) 위험을 적절히 포착하는지에 대해서는 명확하지 않습니다.
핵심 문제: 기존 GHSA 메타데이터는 코드 수준의 결함 (CWE) 을 기록하지만, 모델 추론, 프롬프트 조작, 에이전트 자율성 등을 통해 취약점이 어떻게 증폭되거나 전파되는지 (아키텍처적 위험) 를 구조적으로 표현하지 못합니다.
연구 목적: LLM 관련 컴포넌트가 포함된 GitHub 보안 권고안 (GHSA) 을 실증적으로 분석하여, 기존 취약점 분류 체계 (CWE) 와 LLM 특화 위험 분류 체계 (OWASP Top 10 for LLM) 간의 관계를 규명하고, 현재 메타데이터의 한계를 파악하는 것입니다.
2. 연구 방법론 (Methodology)
이 연구는 2025 년 1 월부터 2026 년 1 월까지 발표된 295 개의 GHSA를 대상으로 한 실증 분석입니다.
데이터 수집 및 필터링:
GitHub Advisory Database 에서 'LLM', 'GPT', 'LangChain', 'Ollama' 등 관련 키워드를 포함하는 295 건의 권고안을 수집했습니다.
영향을 받는 133 개의 고유 패키지를 분석하여 세 가지 범주로 분류했습니다:
LLM 연관 (LLM-associated): LLM 기능 구현 또는 오케스트레이션이 핵심인 패키지 (예: vLLM, LangChain).
잠재적 LLM 연관 (Possible LLM-associated): LLM 파이프라인에서 지원 인프라로 사용되지만 LLM 전용은 아닌 패키지 (예: 벡터 DB, 워크플로우 도구).
비 LLM 연관: LLM 과 무관한 패키지.
샘플링 및 수동 주석 (Annotation):
첫 번째와 두 번째 범주에 속하는 260 건 중 100 건을 무작위 추출하여 수동으로 주석 달기 작업을 수행했습니다.
OWASP Top 10 for LLM Applications 2025 분류 체계를 사용하여 각 권고안의 아키텍처적 노출 패턴 (예: 프롬프트 인젝션, 과도한 권한 등) 을 매핑했습니다.
두 명의 annotator 가 독립적으로 작업하여 Cohen's Kappa(0.76) 와 Gwet's AC1(0.95) 로 높은 일관성을 확보했습니다.
3. 주요 기여 (Key Contributions)
실증적 특성화: 2025~2026 년 기간의 295 건 GHSA 를 기반으로 LLM 관련 패키지의 CWE 패턴을 체계적으로 분석했습니다.
분류 체계 간 매핑: CWE(코드 수준) 와 OWASP Top 10 for LLM(아키텍처 수준) 간의 체계적인 매핑을 100 건의 수동 주석을 통해 제시했습니다.
메타데이터 한계 규명: 현재 GHSA 메타데이터가 LLM 참여 여부나 모델 매개 노출 메커니즘을 명시적으로 나타내지 못함을 증명하여, 체계적인 분석의 필요성을 제기했습니다.
4. 연구 결과 (Results)
RQ1: LLM 관련 패키지에서 가장 흔한 CWE 카테고리는?
새로운 취약점 클래스의 부재: LLM 시스템 고유의 새로운 구현 수준 취약점은 발견되지 않았습니다.
기존 취약점의 우세:코드 인젝션 (CWE-94), 명령어 인젝션 (CWE-77, CWE-78), **불안전한 역직렬화 (CWE-502)**가 압도적으로 많았습니다. 이는 LLM 생태계가 기존 소프트웨어의 취약점을 계승하고 있음을 시사합니다.
RQ2: 기존 메타데이터가 LLM 노출을 얼마나 잘 표현하는가?
구조적 부재: GHSA 메타데이터는 영향을 받는 패키지, 심각도, CWE ID 는 포함하지만, 해당 취약점이 LLM 기능이나 모델 추론과 관련이 있는지 여부를 구분하는 필드가 없습니다.
수동 분류 필요: LLM 관련 노출 패턴을 식별하기 위해서는 수동 분류가 필수적임을 확인했습니다.
RQ3: OWASP Top 10 for LLM을 적용했을 때 어떤 노출 패턴이 나타나는가?
주요 위험:공급망 위험 (Supply Chain, 44%), 과도한 권한 (Excessive Agency, 20%), **프롬프트 인젝션 (Prompt Injection, 18%)**이 가장 빈번했습니다.
복합적 패턴: 37% 의 권고안은 단일 라벨이 아닌 복합 패턴을 보였습니다. 예를 들어, 프롬프트 인젝션 (LLM01) + 부적절한 출력 처리 (LLM05) + 과도한 권한 (LLM06)이 결합되어 프롬프트 조작이 실행 권한 남용으로 이어지는 경우가 많았습니다.
RQ4: OWASP LLM 위험 카테고리는 어떤 CWE 와 대응되는가?
구현과 아키텍처의 연결: 아키텍처적 위험 (OWASP) 은 전통적인 구현 취약점 (CWE) 을 통해 구체화됩니다.
공급망 (LLM03): 다양한 CWE(명령어 인젝션, 역직렬화 등) 와 광범위하게 연결됨.
과도한 권한 (LLM06) 및 프롬프트 인젝션 (LLM01): 주로 인젝션 관련 취약점 (CWE-77, CWE-78, CWE-94) 과 밀접하게 연관됨.
5. 의의 및 시사점 (Significance)
다층적 분석의 필요성: LLM 통합 시스템의 취약점은 **코드 수준 (CWE)**과 **아키텍처 수준 (OWASP)**을 모두 고려해야 완전히 이해할 수 있습니다. CWE 는 '어떻게 코드가 고장 나는지'를, OWASP 는 '모델 기반 시스템이 어떻게 노출되는지'를 설명합니다.
메타데이터 개선 제안: 현재 GHSA 와 같은 취약점 보고 체계는 코드 결함만 기록하고, 모델 매개 노출 경로 (프롬프트 → 모델 → 실행) 를 생략합니다. 향후 보안 메타데이터에는 LLM 참여 여부 및 상호작용 패턴을 명시하는 구조가 추가되어야 합니다.
실무적 함의: LLM 시스템의 보안을 강화하기 위해서는 기존 인젝션 및 역직렬화 방지 기술과 함께, 프롬프트 처리, 출력 검증, 에이전트 권한 제어 등 아키텍처적 방어 전략이 병행되어야 합니다.
이 연구는 LLM 이 도입된 오픈소스 시스템의 보안 위험이 완전히 새로운 것이 아니라, 기존 취약점이 새로운 아키텍처적 맥락에서 재구성된 것임을 실증적으로 증명했습니다.