Slopsquatting
Slopsquatting은 AI가 만들어 낸 패키지 이름을 악용해 개발자가 악성 의존성을 설치하도록 유도하는 소프트웨어 공급망 공격입니다.
Slopsquatting은 공격자가 AI 코딩 어시스턴트가 만들어 낸 이름으로 악성 패키지를 게시한 뒤, 개발자나 자동화 도구가 해당 패키지를 설치하도록 유도하는 소프트웨어 공급망 공격입니다. 이 공격은 그럴듯한 의존성 추천을 실행 가능한 서드파티 코드로 바꿉니다. 이는 사실처럼 제시된 허위 정보인 LLM의 환각과 소프트웨어 빌드에 사용되는 패키지 관리자를 연결합니다.
보안 연구원 Seth Larson은 2025년 4월 이 용어를 만들었으며, Andrew Nesbitt는 Larson에게 공을 돌리면서 최초의 slopsquatting 정의를 통해 이 용어를 널리 알렸습니다. 이 이름은 AI 슬롭과 다른 사람들이 찾게 될 소프트웨어 이름을 선점하는 것을 뜻하는 '스쿼팅'을 결합한 것입니다.
Slopsquatting의 작동 방식#
대규모 언어 모델은 만들어 낸 패키지 이름이나 설치 명령이 포함된 코드를 생성합니다. 공격자는 해당 이름을 파악하고 PyPI 또는 npm과 같은 레지스트리에 그 이름으로 패키지를 게시합니다. 같은 추천이 다시 나타나면 설치 과정에서 공격자의 패키지를 가져옵니다. 패키지 환각은 여러 프롬프트와 모델에서 반복될 수 있어, 공격자가 선점할 수 있는 이름에 수요가 집중됩니다.
레지스트리의 상태에 따라 결과가 달라집니다. 등록되지 않은 이름은 설치 실패를 일으키지만, 공격자가 제어하는 이름은 정상적으로 확인되어 환경에 악성 코드를 주입합니다. 개발자가 어시스턴트를 신뢰하는 것이 소프트웨어 공급망으로 침투하는 경로가 됩니다.
이 위험은 사람의 지원을 받는 개발과 에이전트 기반 코딩 모두에 영향을 미칩니다. 도구 사용 기능을 갖춘 AI 에이전트는 생성된 의존성을 설치 작업으로 이어지게 할 수 있습니다. 악성 패키지 코드는 설치 중이나 이후 사용 과정에서 실행되어, 환경 권한에 따라 파일, 자격 증명, 빌드 산출물을 노출할 수 있습니다.
만들어 낸 패키지가 개발자에게 도달한 경로#
AI 모델이 존재하지 않는 의존성으로 추천한 뒤, Bar Lanyado는 huggingface-cli이라는 이름의 빈 Python 패키지를 게시했습니다. 2024년 3월 28일까지 3개월간 환각으로 만들어진 이 패키지는 실제 다운로드 횟수가 30,000회를 넘었습니다. Alibaba 연구 저장소의 README에도 설치 안내가 게시되었습니다. 빈 패키지가 채택된 사례는 만들어 낸 의존성 이름이 실제 개발 워크플로에 유입될 수 있음을 보여 주었습니다.
패키지 이름 지정 방식은 또 다른 혼란의 원인입니다. 명령줄 실행 파일, 가져올 수 있는 모듈, 설치 가능한 배포 패키지는 서로 다른 이름을 사용할 수 있습니다. 어시스턴트가 환경 설정 안내를 생성하는 컴퓨터 비전 개발에서는 이 점이 중요합니다. Ultralytics YOLO는 학습, 예측, 내보내기 워크플로를 제공하는 ultralytics Python 패키지를 통해 YOLO26을 지원합니다. 생성된 설치 안내가 해당 패키지의 식별 정보와 일치하는지 확인하면 slopsquatting이 발생하는 의존성 선택 단계를 방어할 수 있습니다.
Slopsquatting과 관련 공격#
이 용어들은 의존성 보안에 영향을 주는 서로 다른 메커니즘을 설명합니다.
- 패키지 환각: 모델이 의존성을 지어냅니다. Slopsquatting은 적대적인 패키지 등록을 통해 이러한 이름 오류를 악용합니다.
- 타이포스쿼팅: 공격자는 기존 패키지와 비슷한 이름을 등록해 오타를 이용합니다. Slopsquatting은 AI가 생성한 이름을 노립니다.
- 의존성 혼동: 비공개 의존성을 사용하려던 상황에서 패키지 관리자가 공개 패키지를 가져옵니다.
- 프롬프트 인젝션: 공격자가 제어하는 콘텐츠가 AI 시스템의 동작을 다른 방향으로 유도합니다. Slopsquatting은 레지스트리를 통해 생성된 패키지 추천을 악용합니다.
빌드 파이프라인에서 Slopsquatting 방지하기#
의존성 승인 절차를 통해 설치 전에 프로젝트, 게시자, 소스 저장소, 릴리스 이력을 확인합니다. 보안 중심의 의존성 검토는 사람이 작성한 코드와 마찬가지로 AI가 생성한 추가 항목에도 적용됩니다. 레지스트리에서 이름을 확인하면 해당 이름이 존재하는지는 알 수 있지만, 소유권을 확인해야 실제로 실행될 소프트웨어의 주체를 파악할 수 있습니다. 어시스턴트를 승인된 패키지 문서에 기반하도록 설정하면 이러한 검토에 필요한 패키지 식별 정보를 제공할 수 있습니다.
지속적 통합에서는 검토 게이트를 통해 의존성 변경 사항이 빌드에 반영되기 전에 제어합니다. 버전을 고정하면 승인된 릴리스를 지정할 수 있고, 아티팩트 해시를 사용하면 해당 릴리스의 정확한 파일을 식별할 수 있습니다. 에이전트 샌드박싱, 제한된 네트워크 액세스, 최소 권한 자격 증명을 사용하면 의존성 코드가 접근할 수 있는 리소스를 제한하여 민감한 데이터와 배포 자격 증명에 대한 접근을 줄일 수 있습니다.
Python의 해시 확인 설치 모드는 --require-hashes을 사용하여 다운로드한 패키지 파일의 해시를 requirements 파일에 기록된 해시와 비교합니다. 전이 의존성, 즉 다른 라이브러리에 필요한 라이브러리를 포함해 모든 의존성에 정확한 버전과 허용된 아티팩트 해시를 지정해야 합니다. 다운로드한 패키지의 해시가 허용된 해시 중 어느 것과도 일치하지 않으면 pip는 해당 파일을 거부하고 설치를 중단합니다.










