문제점을 한 문장으로 요약하면 다음과 같습니다.
다음번에는 AI 어시스턴트가 설치할 패키지를 추천합니다해당 패키지가 실제로 존재하는지 확인해 보실 건가요? 대부분의 개발자는 그렇지 않습니다. 제안과 검증 사이의 이러한 간극이 바로 슬롭스쿼팅 공격의 시작점이며, 슬롭스쿼팅의 진화 과정과 실질적인 예방책을 이해하는 것이 AppSec 및 DevSecOps 팀의 최우선 과제가 된 이유입니다.
슬롭스쿼팅 공격이란 무엇인가요?
슬롭스쿼팅 공격은 변형된 공격입니다. 타이포 스쿼팅 (일반적인 철자 오류를 이용하여 합법적인 도메인이나 패키지 이름을 모방하여 등록하는 행위, 예를 들어) 요청 대신 요청(사용자의 오타를 이용해 해당 패키지 이름으로 바로 연결되는 것을 기대하는 방식)과 유사하지만, 오류가 발생하는 지점에 중요한 차이가 있습니다. 타이포스쿼팅은 사람의 오타를 악용하는 반면, 슬롭스쿼팅 공격은 대규모 언어 모델(LLM)이 만들어내는 오류를 악용합니다. LLM이 완벽하게 합법적으로 들리지만 공개 레지스트리에 존재하지 않는 패키지 이름을 "환각처럼" 만들어내면, 공격자는 선의의 의도를 가진 다른 사용자보다 먼저 해당 이름을 등록하여 우선권을 확보합니다.
일반적인 슬롭스쿼팅 공격의 메커니즘은 간단하며, 바로 그 단순함이 그 공격을 효과적으로 만드는 요인입니다.
- 한 개발자가 AI 비서에게 코딩 문제를 해결하는 데 도움을 요청합니다.
- 해당 모델은 존재하지 않는 패키지를 가져오거나 설치를 권장하는 솔루션을 생성합니다.
- 공격자는 여러 모델이 동일한 허구의 이름을 반복해서 사용하는 것을 발견하고, 악성 코드가 포함된 해당 패키지를 npm, PyPI 또는 다른 공개 레지스트리에 등록합니다. 바로 이 순간, 허구의 이름이 실제 슬롭스쿼팅 공격으로 변모합니다.
- 같은 제안을 받고 검증하지 않는 다음 개발자는 이제 실제로 존재하는 패키지를 설치하게 되는데, 이는 개발자 환경에 대한 백도어 역할을 합니다.
"슬롭스쿼팅(slopsquatting)"이라는 용어는 파이썬 소프트웨어 재단의 보안 개발자인 세스 라슨이 만들어냈고, 앤드류 네스빗이 널리 퍼뜨린 것으로, 바로 이러한 패턴, 즉 "패키지 환상"이 공격 벡터로 변질된 것을 설명합니다.
쓰레기 무단 점거의 진화: 연구 대상의 호기심이 어떻게 실제 위협으로 변모했는가
슬롭스쿼팅의 진화에서 주목할 만한 점은 개념 자체뿐만이 아닙니다. 연구 관찰 단계에서 문서화되고 측정 가능한 공격 유형으로 빠르게 발전했다는 점입니다.
2023년: 첫 번째 경고 신호. 보안 연구원 바르 라냐도 몇몇 LLM들이 반복적으로 특정 패키지를 추천하는 것을 발견했습니다. 포옹얼굴-cli이는 존재하지 않습니다 (실제 패키지는 다음 명령으로 설치됩니다). pip install -U “huggingface_hub[cli]”그는 이러한 위험성을 보여주기 위해 해당 패키지의 빈 버전을 공개 레지스트리에 업로드했습니다. 3개월 만에 아무런 홍보 없이 3만 건이 넘는 다운로드를 기록했습니다. 심지어 이 가짜 이름은 알리바바의 연구와 관련된 저장소의 README 파일에까지 등장하여, 이러한 "가짜" 이름이 실제 문서에 어떻게 스며들어 이후에 발생할 슬롭스쿼팅 공격의 발판을 마련할 수 있는지를 일찌감치 보여주었습니다.
2024년: 해당 위험은 연구원의 블로그 게시글에서 주류 기술 언론의 주요 관심사로 떠오릅니다. 3 월 2024, 등록 AI 모델이 개발자들이 다운로드하는 소프트웨어 패키지 이름을 자신 있게 지어내고, 그중 일부는 악성코드에 감염되었을 가능성이 있다는 보도가 나왔습니다. 이 보도는 기술적인 내용 자체보다는 시사하는 바가 컸습니다. 바로 huggingface-cli 사건이 더 이상 일회성 사건이 아니라는 점입니다. 이는 주류 기술 언론이 주목할 만큼 심각한 패턴의 첫 징후였으며, 1년 후 그 규모를 확인하게 될 대규모 학술 연구에 앞서 나온 신호였습니다.
2025년: 해당 문제에 대한 최초의 엄격하고 대규모적인 측정이 이루어질 것이다. 종이 "여러분을 위한 패키지가 있습니다! 코드 생성 LLM을 통한 패키지 환각에 대한 종합 분석" (Spracklen et al., USENIX 보안 심포지엄(Symposium)은 상용(GPT-4, GPT-3.5) 및 오픈 소스(CodeLlama, DeepSeek, WizardCoder, Mistral)를 포함한 16개의 코드 생성 모델을 576,000개의 Python 및 JavaScript 코드 샘플에 대해 테스트했습니다. 이 결과는 슬롭스쿼팅이 단순한 일화에서 데이터로 진화하는 중요한 전환점을 보여줍니다.
- 19.7% 모델에서 권장하는 패키지 중 존재하지 않는 패키지가 있었습니다.
- 오픈소스 모델은 훨씬 더 자주 허황된 주장을 펼쳤다.21.7% 평균적으로 상용 모델보다 (5.2%).
- 가장 심각한 문제를 보인 CodeLlama 7B와 CodeLlama 34B는 출력물의 3분의 1 이상에서 환각 현상을 유발했습니다.
- 연구원들은 테스트한 모든 모델에서 100건 이상의 로그를 기록했습니다. 205,000개의 독특하고 환각적인 패키지 이름여러 생태계에 걸쳐 지속적인 무단 점거 공격을 부추길 만큼 충분히 큰 웅덩이.
- 예방에 특히 중요한 한 가지 세부 사항은 다음과 같습니다. 대략적으로 38% 환각으로 나타난 이름들은 실제 포장과 매우 유사하여, 누군가가 한눈에 알아차릴 가능성을 낮춥니다.
이 연구에서 중요한 세부 사항, 그리고 아마도 슬롭스쿼팅의 진화가 잦아들지 않고 가속화된 이유일 것은, 만들어낸 이름들이 무작위가 아니며 시도할 때마다 바뀌지도 않는다는 점입니다. 동일한 모델은 비슷한 프롬프트가 주어지면 같은 가상의 이름을 반복해서 사용하는 경향이 있는데, 이는 공격자가 추측할 필요가 없다는 것을 의미합니다. 공격자는 모델의 동작을 관찰하고 반복적으로 나타나는 이름을 식별한 다음, 실제 개발자보다 먼저 등록하기만 하면 됩니다. 이러한 반복성에 대한 후속 분석 결과, 연구원들이 동일한 프롬프트를 각각 10번씩 실행했을 때, 만들어진 패키지 이름의 43%가 매번 실행에서 나타났고, 58%는 두 번 이상 반복되었습니다. 이는 대부분의 환각이 일회성 노이즈가 아니라 반복 가능한 인공물이라는 증거입니다. 바로 이러한 반복성 때문에 일회성 환각이 확장 가능한 슬롭스쿼팅 공격으로 이어지는 것입니다.
2026년: 개별 패키지에서 자율 에이전트로. 올해는 슬롭스쿼팅이 더 이상 개발자가 제안된 코드를 복사해서 붙여넣는 행위에만 국한되지 않는다는 가장 명확한 증거가 드러났습니다. 핍 설치 or npm 설치 명령. 2026년 1월, 연구원 찰리 에릭슨 아이키도 보안팀은 AI 코딩 에이전트가 허구의 npm 패키지를 참조하는 지침을 이미 퍼뜨렸다는 사실을 발견했습니다. 리액트 코드시프트 (두 가지 실제 도구를 그럴듯하게 혼동한 이름입니다.) jscodeshift react-codemod), 237개의 저장소에 걸쳐 존재하며, 에이전트들은 여전히 매일 설치를 시도하고 있습니다. 에릭센은 공격자가 이를 악용하기 전에 방어적으로 직접 해당 이름을 등록했습니다. 이와는 별도로, 실제 악성 패키지는 다음과 같은 이름으로 존재합니다. 사용되지 않는 수입품정당한 것을 대신하여 환각이 나타났다 eslint-plugin-사용되지 않는 가져오기npm이 보안 조치를 취했음에도 불구하고 2026년 초에도 여전히 주간 다운로드 횟수가 약 233회에 달했던 이 프로젝트는, 슬롭스쿼팅 공격이 경고를 받은 후에도 얼마나 오랫동안 피해자를 끌어들일 수 있는지를 보여주는 사례입니다. 더 최근인 2026년 7월에는 연구원들이 "할루스쿼팅(HalluSquatting)"이라는 관련 기법을 설명했는데, 이는 AI 환각과 프롬프트 주입을 결합하여 사용자를 대신해 환각된 리소스를 가져오는 AI 코딩 에이전트를 탈취해 공격자가 제공한 코드를 실행하게 하는 것입니다. 이는 슬롭스쿼팅이 수동적인 설치 위험에서 에이전트 기반 개발 워크플로 내에서 능동적인 원격 코드 실행 벡터로 진화했음을 보여줍니다.
"바이브 코딩"이 왜 슬롭스쿼팅 공격의 빌미를 제공했을까?
AI 생성 코드가 틈새 시장에 불과했다면 슬롭스쿼팅 공격은 큰 문제가 되지 않았을 것입니다. 하지만 그렇지 않습니다. 코딩 어시스턴트, 자율 에이전트, 그리고 개발자가 코드를 실행하기 전에 검토하는 시간을 점점 줄이는 "바이브 코딩" 워크플로의 등장으로 소프트웨어 공격 표면이 두 가지 구체적인 방식으로 변화했으며, 이 두 가지 모두 슬롭스쿼팅의 진화를 가속화하고 있습니다.
- 진입점은 더 이상 개발자에만 국한되지 않습니다. 과거에는 타이포스쿼팅 공격이 한 사람의 오타에 의존했지만, 이제는 모델 자체 내부에서 오류가 발생하여 유사한 질문을 하는 수백 명의 개발자에게 전파되고, 이들이 동일한 잘못된 추천을 받게 되면서 단일 슬롭스쿼팅 공격의 파급 효과가 배가될 수 있습니다.
- 공격 표면이 체인의 더 위쪽으로 이동했습니다. 이제는 사람이 작성한 코드만 감시하는 것으로는 충분하지 않습니다. 팀은 AI 어시스턴트가 제안하는 종속성, 연결하는 MCP 서버, 그리고 사람의 직접적인 검토 없이 자율적으로 패키지를 설치하는 에이전트까지 감시해야 합니다. 기존의 애플리케이션 보안(AppSec) 방식은 저장소와 사람의 검토에 기반을 두고 있습니다. commits는 개발자, AI, 패키지 레지스트리 간의 이러한 새로운 상호 작용을 관찰하도록 설계되지 않았으며, 바로 이 지점에 슬롭스쿼팅 공격이 숨어 있습니다.
이 모든 것이 생성형 AI가 본질적으로 불안정하다는 것을 의미하는 것은 아닙니다. 이는 기존 보안 도구로는 감지할 수 없었던 새로운 유형의 공급망 위험을 초래한다는 것을 의미하며, 우리가 이미 모든 외부 의존성에 적용하고 있는 것과 동일한 검증 원칙을 요구합니다. 즉, 기본적으로 신뢰하지 말고, 출처를 검증하고, 개발자 개개인의 기억이나 경계심에 의존하는 대신 검증 과정을 자동화해야 합니다. 이러한 자동화는 진정한 슬롭스쿼팅 방지 전략의 기반입니다.
쓰레기 무단 점거 방지: 팀이 오늘 할 수 있는 일
다행히 슬롭스쿼팅 방지에는 특별한 도구가 필요하지 않습니다. 이미 존재하는 의존성 관리 관행을 체계적으로 적용하기만 하면 되지만, 많은 팀은 신뢰하는 AI가 코드를 "제안"하는 순간 방심하는 경향이 있습니다. 효과적인 슬롭스쿼팅 방지 접근 방식은 일반적으로 다음과 같은 요소들을 결합합니다.
- 새 패키지를 설치하기 전에 수동으로 확인하십시오.특히 AI 비서의 제안일 경우 더욱 그렇습니다. 공식 등록부에 등록되어 있는지, 누가 관리하는지, 언제 게시되었는지, 다운로드 횟수가 실제와 일치하는지 확인하세요. 이 습관 하나만으로 어떤 팀이든 슬롭스쿼팅을 가장 저렴하게 예방할 수 있습니다.
- 인공지능이 생성한 코드가 기본적으로 안전하다고 절대 가정하지 마세요. "작동하는" 코드 조각이라고 해서 그 코드의 의존성이 타당하다는 의미는 아닙니다. 의존성 검토는 코드 검토의 일부로 포함되어야 하며, 예외로 두어서는 안 됩니다.
- 잠금 파일과 해시 검증을 사용하십시오. 정확한 버전을 고정하고, 자동 업데이트로 인해 원래 검증된 패키지와 다른 패키지가 사용되는 것을 방지합니다.
- 알려진 CVE 외에도 위험 패턴을 감지하는 종속성 검사를 배포하세요.비정상적인 패키지, 기존 패키지와 의심스러울 정도로 유사한 이름, 이력이 없는 새로운 관리자, 또는 비정상적인 동작을 보이는 설치 스크립트 등이 슬롭스쿼팅의 특징입니다. 특히, 이력이 거의 없는 새로 게시된 패키지가 "거의" 익숙한 무언가의 이름을 모방하는 것은 지금까지 보고된 대부분의 슬롭스쿼팅 공격의 전형적인 패턴입니다.
- 공공 등록기관도 같은 회의적인 시각으로 대해야 합니다.cism은 다른 검증되지 않은 외부 출처와 마찬가지입니다. 사실 그 핍 설치 or npm 설치 오류가 발생하지 않는다고 해서 정당성을 입증하는 것은 아닙니다.
- 교육 개발팀 AI 기반 코딩이 설치되는 내용을 검증해야 할 책임을 없애는 것이 아니라, 심각한 소프트웨어 무단 복제 방지 계획의 일환으로 워크플로에 포함시켜야 할 단계를 추가하는 것임을 알아야 합니다.
이러한 조치들 자체는 새로운 것이 아닙니다. 달라진 점은 규모입니다. 의존성 제안이 더 이상 스택 오버플로우나 동료로부터 오는 것이 아니라, 수천 명의 개발자에게 동일한 오류를 반복해서 표시할 수 있는 모델에서 나오게 되면, 수동 검증은 여전히 필요하지만 그 자체로는 더 이상 충분하지 않습니다. 이것이 바로 더 많은 팀이 코드 무단 복제 방지를 위한 이러한 단계를 자동화하는 이유입니다. 소프트웨어 구성 분석 (SCA) 툴링개별 개발자의 자율성에 맡기기보다는,
이것은 사전입니다cis엘리 왜 ASPM 플랫폼 처럼 제니 타이포스쿼팅, 종속성 혼동, 알려진 악성 패키지 등을 포함하는 의심스러운 종속성 탐지 기능을 동일한 오픈 소스 및 AI 기반 종속성 분석에 통합합니다. pipeline따라서 슬롭스쿼팅 방지는 모든 개발자가 AI 어시스턴트가 새로운 종속성을 제안할 때마다 이를 확인하는 것을 기억하는 것에 달려 있지 않습니다.
FAQ
슬롭스쿼팅 공격과 타이포스쿼팅 공격은 같은 것인가요?
완전히 같지는 않습니다. 둘 다 가짜 패키지 이름을 등록하여 설치하는 사람을 속이는 방식이지만, 오류의 원인은 다릅니다. 타이포스쿼팅은 사람의 오타를 악용하는 것이고, 슬롭스쿼팅 공격은 AI 모델이 만들어낸 (혹은 상상 속의) 패키지 이름을 악용하여, 해당 패키지가 실제로 존재하기 전에 공격자가 등록하는 것입니다.
패키지 관리자가 이러한 유형의 공격을 자동으로 방지할 수 있을까요?
완전히 막을 수는 없습니다. 바로 그 점 때문에 슬롭스쿼팅 방지는 패키지 관리자 수준에서만 멈춰서는 안 됩니다. 공격자가 개발자가 설치를 시도하기 전에 허위 패키지를 등록하면, 해당 패키지가 악성 패키지임에도 불구하고 실제로 존재하는 것처럼 인식되어 설치가 오류 없이 완료됩니다. 효과적인 방지를 위해서는 패키지의 출처와 동작 방식에 대한 추가적인 검증이 필요합니다.
이것은 오픈소스 모델에만 영향을 미치는 건가요?
아니요. Spracklen 등의 연구에서는 상용 모델을 포함하여 테스트한 모든 모델에서 환각 현상이 발견되었지만, 그 비율은 상당히 낮았습니다(평가된 오픈소스 모델의 21.7%에 비해 상용 모델은 5.2%). 어떤 모델도 이 문제에서 완전히 자유롭지 않으며, 이것이 바로 슬롭스쿼팅의 진화가 AI 기반 코딩 전반의 성장과 보조를 맞추는 이유 중 하나입니다.
이것은 이론적인 위험일까요, 아니면 이미 악용된 사례가 있을까요?
The 포옹얼굴-cli 한 연구원이 업로드한 빈 패키지가 아무런 홍보 없이 3개월 만에 3만 번 이상 다운로드된 사례는 위험이 단지 이론적인 것에 그치지 않음을 보여줍니다. 환각적인 이름이 여러 프롬프트에서 충분히 일관성만 있다면 누군가가 이를 실제 슬롭스쿼팅 공격으로 악용할 수 있습니다.
