“LLM/AI 지원 패키지 종속성, 앱 보안 위협 높인다” 엔돌 랩스 보고서

사이버보안 업체 엔돌 랩스(Endor Labs)의 연구에 따르면, 점점 더 많은 애플리케이션에 LLM 기반 생성형 AI 기능을 활용하는 사전 패키지 소프트웨어 구성요소가 포함되면서 취약점이 프로덕션에 적용될 위험도 그 어느 때보다 커지고 있다. 
 

‘2023년 종속성 관리 현황(State of Dependency Management 2023)’이라는 제목의 최근 보고서에 따르면, 애플리케이션 개발자가 패키지(소프트웨어 제작 시 쉽게 설치하도록 설계된 라이브러리 및 모듈과 같은 구성요소)의 일부만 사용하더라도 수많은 종속성이 발생하며, 위험한 API가 호출될 우려가 있다.

보고서 집필에 참여한 엔돌 랩스 보안 연구원 헨릭 플레이트는 “LLM은 여러 일상적인 프로그래밍 작업을 훌륭하게 지원한다. 하지만 개발자는 LLM이 제공하는 출력을 프로덕션 코드에 포함하기 전에 검증해야 한다”라고 말했다.

엔돌 랩스는 연구를 위해 리눅스 재단과 하버드에서 제공하는 센서스 II(Census II) 데이터 세트, 사내 API 카테고리 및 취약성 데이터베이스, 오픈소스 깃허브 리포지토리, npm 및 PyPI 패키지 리포지토리에 게시된 패키지를 사용했다.

LLM/AI 지원 패키지의 위험성

엔돌 랩스는 2023년 1월 챗GPT API가 출시된 이후 npm 및 PyPI 리포지토리에 업로드된 신규 패키지를 추적하는 과정에서 API를 사용하기 위해 새로 생성된 npm/PyPI 패키지가 636개 이상이라는 사실을 발견했다. 이미 게시된 276개의 패키지에서도 챗GPT API 지원이 추가됐다. LLM을 실험하는 민간 프로젝트의 수가 훨씬 많은 것을 고려하면 이런 규모는 일부에 불과하다.

상위 100개 AI 프로젝트에 대한 깃허브 리포지토리를 스캔한 결과, 직접 및 전이적 종속성을 참조하는 것은 평균 208개였고 11%의 프로젝트는 500개 이상의 종속성에 의존하고 있었다.

또한 엔돌 랩스가 스캔한 깃허브 리포지토리의 15%에는 알려진 취약점이 10개 이상 포함되어 있었다. 챗GPT 기반 아키텍처인 허깅 페이스(Hugging Face)의 트랜스포머(Transformers) 라이브러리에서 배포된 패키지에는 200개 이상의 종속성이 있었으며, 여기에는 알려진 취약점이 4개 포함되어 있었다.

종속성, 보안에 민감한 API 호출한다

엔돌 랩스가 추적한 애플리케이션의 55%는 보안에 민감한 API, 즉 손상될 경우 기업의 자산 보안에 영향을 미칠 수 있는 중요 리소스에 연결되는 API를 호출하는 것으로 나타났다. 소프트웨어 구성요소 패키지의 종속성까지 추적하면 이 수치는 95%까지 증가한다.

플레이트는 “모든 중요한 애플리케이션에는 자바 런타임에서 제공하는 핵심 API를 구성하는 자바 클래스 라이브러리인 JCL의 상당 부분을 호출하는 종속성이 포함되어 있다”라고 지적했다.

모든 종속성을 고려했을 때 센서스 II 자바 패키지의 71%는 보안에 민감한 API 5가지 이상을 호출하는 것으로 나타났다.

플레이트는 “애플리케이션은 오픈소스 구성요소의 일부만 사용하는 경우가 많은데, 개발자는 구성요소의 계단식 종속성을 거의 이해하지 못한다. 브랜드 평판을 보호하면서 투명성 요건을 충족하기 위해서는 기본적인 SBOM 작성을 뛰어 넘는 조치가 필요하다”라고 덧붙였다.

보고서 집필팀은 프로덕션에 어떤 구성요소가 포함되어 있는지 아는 것만으로는 더 이상 효과적이지 않으며, 해당 구성요소가 어떤 기능을 사용하는지 이해하는 것이 중요하다고 강조했다. 

LLM이 맬웨어 탐지에 취약한 이유

엔돌 랩스는 오픈 AI 및 구글 버텍스 AI의 LLM 모델을 맬웨어 분류에 활용하는 방법을 평가했다. 두 LLM에 동일한 코드 스니펫을 제시하고 악성 가능성을 0~9점으로 평가하도록 요청했다. 보고서 집필팀은 “3,374개의 테스트 사례로 두 모델의 평가 결과가 얼마나 일관적인지 알아보고자 했다. 0~1점 차이를 일치하는 것으로 간주했을 때, 89%의 사례가 일치했다”라고 말했다.

그러나 두 모델 모두 맬웨어를 효과적으로 분류하는 데는 어려움을 겪었으며, 오탐지하는 경우도 상당히 많았다. 오픈AI의 GPT 3.5는 코드 스니펫의 3.4%를 정확하게 분류했고 버텍스 AI의 텍스트 바이슨(text-bison)은 7.9%의 정확도를 보였다.

플레이트는 “주요 원인은 축소/패키징된 자바스크립트, 즉 사용자의 브라우저로 전송할 때 공간/대역폭을 절약하기 위해 어느 정도 변경된 자바스크립트 코드였다. 안타깝게도 축소/패키징은 매우 일반적이며 npm 패키지뿐 아니라 일종의 UI를 번들로 제공하는 파이썬 패키지에도 존재한다. LLM은 이런 코드가 난독화돼 보인다는 이유만으로 악성 코드로 분류하는 경우가 많다”라고 설명했다. 

이어 “오탐지가 이렇게 많으면 LLM의 피드백은 거의 쓸모 없어지는데, 난독화되지 않은 코드에 대한 피드백은 매우 좋은 경우가 많기 때문에 안타까운 일이다. 코드를 전처리하면 오탐지를 줄이는 데 효과적일 수 있지만, 난독화 예시는 LLM이 복잡한 프로그래밍 로직을 파악하는 데 어려움을 겪고 있다는 것을 보여준다”라고 덧붙였다.

공격자는 이런 점을 악용해 탐지를 회피할 수 있고 이로 인해 맬웨어가 탐지되지 않거나 오탐지로 이어질 수 있다. 

IDC 애널리스트 케이티 노턴은 “이번 보고서의 가장 큰 시사점은 GPT와 같은 범용 LLM을 특수한 목적에 사용하면 안 된다는 점이다. 맬웨어를 식별하는 것은 모델 학습이 불가능한 알려지지 않은 것을 찾는 것이므로 생성형 AI를 사용하기에는 여전히 까다로운 영역”이라고 지적했다.
editor@itworld.co.kr