기술 요약: 올바른 코드, 취약한 종속성

문제 정의

대형 언어 모델 (LLM) 은 소프트웨어 개발 워크플로우에 필수적으로 통합되어, 특정 버전 식별자가 주석으로 달린 제 3 자 라이브러리 (TPL) 가져오기를 포함하는 코드를 routinely 생성합니다. 이전 연구는 생성된 코드의 논리적 보안 (예: CWE 취약점) 과 환각된 패키지 이름의 존재를 광범위하게 연구해 왔으나, 버전 차원은 여전히 largely 미개척 상태로 남아 있습니다. 구체적으로, LLM 이 추천하는 올바르게 명명된 라이브러리의 특정 릴리스 버전이 안전한지, 호환 가능한지, 혹은 유효한지 여부는 알려지지 않았습니다.

본 논문은 중요한 위험 표면을 식별합니다: LLM 은 알려진 공통 취약점 및 노출 (CVE) 을 지닌 라이브러리 버전이나 생성된 API 사용과 호환되지 않는 버전을 고정하는 문법적으로 올바른 코드를 생성할 수 있습니다. 이러한 선택은 코드 생성 과정에서 대규모로 암묵적으로 이루어지기 때문에, 시스템적 보안 위험과 설치 실패를 하류 프로젝트로 조용히 전파할 수 있습니다.

방법론

저자들은 LLM 이 지정한 라이브러리 버전에 대한 최초의 대규모 측정 연구인 PinTrace를 제시합니다. 본 연구는 10 개의 다양한 LLM(GPT-5.4 와 같은 폐쇄형 소스 모델과 Qwen3, Llama-4 와 같은 오픈 소스 모델 포함) 을 1,000 개의 실제 Stack Overflow 프로그래밍 작업으로 구성된 큐레이션 벤치마크에서 평가합니다.

실험 설계

연구는 일반적인 개발자 상호작용을 반영하기 위해 두 가지 프롬프팅 모드를 사용합니다:

1. 인라인 모드: LLM 이 가져오기에 버전 주석을 달아줍니다 (예: import lib # version==x.y.z).
2. 명시적 모드: LLM 이 코드와 함께 requirements.txt 매니페스트 파일을 생성합니다.

분석 파이프라인은 다섯 단계로 구성됩니다:

1. 생성: 두 모드 하에서 각 작업에 대한 코드를 생성합니다.
2. 추출: 라이브러리 참조 및 버전 지정자를 파싱합니다.
3. 검증: PyPI 를 기준으로 검증하여 버전이 발행된 릴리스인지 확인합니다 (환각을 필터링).
4. 취약점 확인: 유효한 버전을 Open Source Vulnerability (OSV) 데이터베이스와 교차 참조하여 CVE 와 CVSS 심각도를 식별합니다.
5. 호환성 확인:
   • 정적: 격리된 가상 환경에서 설치를 시도하고 정적 타입 검사 (ty) 를 실행합니다.
   • 동적: BigCodeBench 벤치마크의 테스트 스위트 를 실행하여 런타임 정확성을 검증합니다.

또한 연구는 Python 버전 (3.8–3.14) 전반에 걸친 견고성 검사, 실패 원인을 격리하기 위해 인접 버전을 대체하는 진단 실험, 그리고 안전 지침과 외부 버전 고정 (anchoring) 을 테스트하는 완화 프로브를 포함합니다.

주요 기여

1. 측정 연구: 10 개의 모델과 1,000 개의 작업을 가로지르는 버전 지정 행동, 유효성, 취약점 노출 및 호환성에 대한 포괄적 평가.
2. 시스템적 편향 증거: 개별 모델 오류가 아닌 학습 신호 편향에 의해 구동되어, 서로 다른 모델 계열 전반에서 LLM 이 소수의 위험하고 구식인 버전으로 수렴한다는 실증적 증거.
3. 근본 원인 진단: 설치 실패가 생성된 코드 논리의 결함이 아니라 버전 선택(호환되지 않거나 구식 버전 선택) 에 주로 기인한다는 것을 확립한 통제 실험.
4. 완화 분석: 프롬프트 수준의 개입에 대한 특성화. 자연어 안전 지침은 효과가 없으나 외부 버전 고정이 위험을 현저히 감소시킨다는 것을 입증.
5. 오픈 리소스: 재현 가능한 연구를 위한 PinTrace 데이터셋 및 평가 파이프라인 공개.

주요 결과

1. 버전 지정 행동 (RQ1)

• 형식 affordance: 버전 주석은 공학적 의도가 아닌 출력 형식에 의해 결정됩니다. 인라인 모드에서 모델은 참조의 **26.83%–95.18%**에 대해 버전을 지정합니다. 명시적 모드(매니페스트 생성) 에서는 이 수치가 **6.45%–59.19%**로 떨어지며, 많은 모델이 버전을 완전히 생략합니다.
• 수렴: 모델들은 인기 있는 릴리스의 좁은 밴드로 수렴합니다. 예를 들어, requests==2.31.0과 django==6.0.1은 거의 모든 모델에 의해 지정됩니다.
• 시간적 지연: 지정된 버전은 모델의 지식 컷오프 시점보다 9 개월에서 31 개월 뒤쳐져 있습니다. 모델은 더 많은 학습 신호를 축적한 더 오래된 버전을 선호적으로 선택합니다.
• 유효성: 대부분의 인라인 지정 버전은 유효하지만, **7%–16%**는 환각된 것입니다 (유효하지 않은 PyPI 릴리스). 이는 종종 접미사 누락 (예: 4.8.0.74 대신 4.8.0) 으로 인해 발생합니다.

2. 취약점 노출 (RQ2)

• 높은 노출: 인라인 프롬프팅 하에서 **36.70%–55.70%**의 작업이 알려진 CVE 를 가진 적어도 하나의 버전을 포함합니다.
• 심각도: 이러한 취약한 버전 중 **62.75%–74.51%**는 Critical 또는 High 심각도로 평가됩니다.
• 회피 가능성: **72.27%–91.37%**의 사례에서 관련 CVE 는 모델의 지식 컷오프 이전에 공개적으로 공개되었습니다. 이는 노출이 회피 가능하지만 모델에 의해 인식되지 않았음을 의미합니다.
• 구조적 위험: 취약한 (라이브러리, 버전) 쌍의 **95.11%**는 동일한 주요 버전 브랜치 내에서 CVE 가 없는 대안이 없습니다. 즉, 간단한 패치 업데이트로는 위험을 해결할 수 없습니다.

3. 호환성 (RQ3)

• 정적 호환성: 인라인 모드에서 비율은 **19.70%에서 63.20%**까지 다양합니다. 실패의 주된 원인은 의존성 설치 오류이며, 이는 종종 Python 3.12+ 환경에서 누락된 distutils 로 인해 발생합니다 (구식 버전 선택의 결과).
• 동적 호환성: 인라인 모드에서 통과율은 **6.49%–48.62%**로 급락합니다. 대부분의 작업은 실행 전에 설치 오류로 인해 실패합니다.
• 진단: 대체 실험은 LLM 이 지정한 버전을 인접 릴리스로 교체하는 것이 **17.19%–55.00%**의 사례에서 설치 실패를 해결함을 확인했습니다. 이는 코드 논리는 종종 타당하지만 버전 선택이 결함이 있음을 증명합니다.

4. 완화

• 프롬프팅: 자연어 안전 지침 ("취약한 버전 피하기") 을 추가하는 것은 미미한 개선 (<2.2% 노출 감소) 을 가져옵니다.
• 외부 고정: 사전 계산된 안전한 버전을 프롬프트에 주입하면 취약점 노출이 크게 감소 (~10–27% 로 하락) 하고 정적 호환성은 **80%–93%**로 향상됩니다.

중요성과 주장

본 논문은 LLM 버전 선택이 1 급의, 이전에 간과된 위험 표면이라고 주장합니다. 연구 결과는 다음과 같습니다:

1. 위험은 개별적이 아닌 시스템적입니다: 모든 모델 계열에서 동일한 취약한 버전으로의 수렴은 공유된 학습 신호 편향을 나타내므로, 단순히 모델을 전환하는 것만으로는 완화할 수 없습니다.
2. 문제는 안전 정렬 격차가 아닌 그라운딩 격차입니다: 대부분의 CVE 는 학습 전에 이미 알려져 있었으므로, 실패는 추론 시 버전 식별자를 보안 상태에 매핑하는 모델의 능력 부재에 있습니다.
3. 프롬프팅만으로는 부족합니다: 자연어 지침은 버전 선택과 보안 지식 사이의 격차를 메울 수 없습니다.
4. 외부 도구가 필요합니다: 저자들은 이 위험을 해결하려면 LLM 의 내부 지식에 의존하기보다는 외부 메커니즘 (예: SCA 도구, 버전 고정) 이 필요하다고 결론 내립니다.

저자들은 이러한 연구 결과를 평가된 모델 제공업체 (OpenAI, Alibaba, Moonshot AI 포함) 에 공개했으며, 그중 몇몇은 문제를 인정했습니다. 본 논문은 표준 LLM 평가 벤치마크에 버전 수준의 보안 및 호환성 평가를 통합할 것을 촉구하고 있습니다.