소프트웨어 개발자에게 ‘의존성’이란 무엇일까? 단순한 코드 조각 이상의 의미를 지닌다. 그것은 다른 개발자의 시간과 노하우를 빌려 쓰는 행위이자, 무형의 신뢰를 전제한 거래다. 그런데 이 신뢰가 한순간에 무너졌을 때, 우리는 무엇을 잃게 되는가?
최근 LiteLLM이라는 이름의 파이썬 패키지가 PyPI에서 악성 코드에 감염되었다는 소식은 이런 질문을 다시금 떠올리게 한다. LiteLLM은 LLM(Large Language Model) API를 통합하는 인기 라이브러리로, 수많은 프로젝트에서 의존성 목록에 올라 있었을 것이다. 문제는 이 패키지의 특정 버전(1.82.7, 1.82.8)에 공격자가 삽입한 악성 코드가 포함되어 있었다는 점이다. 설치된 시스템의 환경 변수를 읽어 AWS 자격 증명, 암호화폐 지갑 키 등 민감한 정보를 탈취하는 기능을 수행했다.
공격 방식은 놀랍도록 단순하면서도 효과적이었다. 공격자는 먼저 PyPI 계정을 탈취하거나 위조한 후, 원본 패키지와 유사한 이름의 악성 버전을 업로드했다. CI/CD 파이프라인이 자동으로 최신 버전을 가져가는 특성을 악용한 셈이다. 실제로 많은 조직에서 이러한 자동화된 프로세스가 악성 패키지를 무심코 배포했을 가능성이 높다. 이 사건은 소프트웨어 공급망 공격이 얼마나 은밀하고 파괴적인지를 보여준다.
이 공격이 특히 주목받는 이유는 두 가지다. 첫째, LiteLLM이 인기 있는 라이브러리였다는 점이다. 인기 패키지는 그만큼 많은 프로젝트에 의존성으로 포함되어 있어 공격 표면이 넓어진다. 둘째, LLM 관련 기술이 현재 가장 뜨거운 분야 중 하나라는 점이다. AI 기술의 확산과 함께 관련 라이브러리들의 사용량도 급증하고 있는데, 이런 추세가 공격자들에게 새로운 기회를 제공하고 있다.
공급망 공격은 사실 새로운 문제가 아니다. 2020년 SolarWinds 해킹 사건이나 2021년 Codecov 브리치 등 대규모 공격 사례가 이미 있었다. 하지만 최근 들어 이러한 공격이 점점 더 정교해지고 빈번해지고 있다는 점이 우려스럽다. 특히 오픈소스 생태계의 특성상, 누구나 패키지를 배포할 수 있고, 그 패키지를 전 세계 개발자들이 사용한다는 점에서 근본적인 취약점이 존재한다.
개발자들은 종종 ‘이 패키지가 안전할 것이다’라는 가정을 무의식적으로 한다. 하지만 그 가정은 언제든 깨질 수 있다.
그렇다면 우리는 어떻게 대응해야 할까? 첫째, 의존성 관리에 더 신중을 기해야 한다. 단순히 최신 버전을 사용하는 것이 항상 안전하지 않다는 점을 인식해야 한다. 둘째, 패키지 설치 시 서명 검증이나 해시 체크 등 추가적인 보안 조치를 도입해야 한다. 셋째, CI/CD 파이프라인에 보안 검증 단계를 필수적으로 포함해야 한다. 넷째, 오픈소스 프로젝트 유지보수자들에게 더 많은 지원이 필요하다. 많은 오픈소스 프로젝트가 자원 부족으로 보안 업데이트를 제때 수행하지 못하는 현실을 개선해야 한다.
이 사건은 또한 기술 생태계 전체의 책임에 대해 생각하게 한다. 개발자 개개인의 노력만으로는 한계가 있다. 패키지 저장소 운영자, 클라우드 서비스 제공자, 기업 보안 팀 등 모든 이해관계자가 협력해야만 이러한 위협에 효과적으로 대응할 수 있다. PyPI 같은 저장소는 악성 패키지 탐지 시스템을 강화하고, 사용자에게 더 명확한 경고를 제공해야 한다.
마지막으로, 이 사건을 통해 우리가 다시 한번 깨달아야 할 것은 기술에 대한 맹신이 얼마나 위험한지이다. 어떤 도구나 라이브러리도 절대적으로 안전하지 않다. 개발자는 항상 의심의 눈초리를 유지해야 하며, 보안은 사후 대응이 아니라 설계 단계부터 고려되어야 한다. LiteLLM 공격은 단순한 보안 사고를 넘어, 소프트웨어 개발 문화 자체에 대한 경고로 받아들여야 한다.
더 자세한 내용은 BleepingComputer의 원문 기사에서 확인할 수 있다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
