AI가 제시한 패키지가 독이 될 때: 슬롭스쿼팅, 개발자를 노리는 치명적인 함정
2026. 7. 30.
AI가 제시한 패키지가 독이 될 때: 슬롭스쿼팅, 개발자를 노리는 치명적인 함정
오타를 노리는 타이포스쿼팅(Typosquatting)은 이제 구식입니다. 이제는 여러분의 AI 코딩 어시스턴트가 제시하는 가짜 패키지를 노리는 새로운 공격, 바로 슬롭스쿼팅(Slopsquatting) 시대가 왔습니다. AI 모델이 존재하지도 않는 패키지 이름을 마치 실존하는 것처럼 만들어내면, 공격자는 그 이름을 재빨리 등록하고 여러분이 install 명령어를 실행하기만을 기다립니다. 이 글에서는 이 교묘한 공격의 전개 과정, 기존 방어 체계가 이를 놓치는 이유, 그리고 npm, Composer, pip 등 주요 생태계에서 실제로 이 공격을 막아낼 방법을 상세히 파헤쳐 보겠습니다.
상상해 보세요. AI 코딩 어시스턴트가 여러분에게 다음과 같은 명령어를 실행하라고 조언합니다.
pip install requests-oauth2-helper
언뜻 보면 전혀 문제가 없어 보입니다. 여러분은 requests 호출에 OAuth2 토큰을 깔끔하게 붙이는 방법을 물었고, 패키지 이름은 정확히 그런 기능을 할 것 같습니다. 이름의 표기법도 파이썬 생태계에 흔한 방식이고, 하이픈 사용도 자연스럽습니다. PyPI에 있는 수십 가지 다른 헬퍼 라이브러리처럼 그럴듯하게 들리죠. 그래서 여러분은 이 명령어를 실행합니다. 테스트도 문제없이 통과하고, 다음 작업으로 넘어갑니다.
하지만 문제가 있습니다. requests-oauth2-helper는 AI 모델이 이 이름을 제안했을 당시에는 세상에 존재하지 않는 패키지였습니다. 모델이 이 이름을 지어낸 겁니다. 그리고 만약 공격자가 이 순간을 노리고 있었다면, 그 이름은 더 이상 비어 있지 않습니다.
이것이 바로 슬롭스쿼팅입니다. 기존 타이포스쿼팅의 핵심인 '사람의 오타' 대신 '기계의 환각(hallucination)'을 활용하는 공급망 공격이죠. 이 용어는 Python Software Foundation의 상주 개발자인 세스 라슨(Seth Larson)이 처음 만들었고, 2025년에 Ecosyste.ms의 앤드루 네스빗(Andrew Nesbitt)이 대중화했습니다. 작지만 섬뜩한 이 아이디어는 더 이상 여러분이 reqeusts처럼 손가락을 삐끗할 필요가 없다는 것을 의미합니다. AI는 뻔뻔한 표정으로 가짜 패키지를 건네줄 것이고, 여러분은 자신의 오타보다 AI의 말을 더 신뢰하게 될 겁니다.
타이포스쿼팅은 '여러분의 실수'를 필요로 했습니다. 이건 그렇지 않죠.
타이포스쿼팅은 오래된 수법입니다. express 옆에 expres를, python-dateutil 옆에 python-dateutl을 등록해 두고 누군가의 손가락이 미끄러지기를 기다리는 방식이죠. 효과는 있지만, 확률 싸움이라 성공률이 희박합니다. 대부분의 사람들은 express를 정확하게 타이핑하니까요. 공격자는 1% 미만의 실수를 저지르는 사람들을 낚시하는 셈입니다.
슬롭스쿼팅은 이 '인간의 실수' 의존성을 완전히 제거합니다. 개발자는 AI 어시스턴트가 제시한 이름을 한 글자도 틀리지 않고 정확히 복사해서 붙여넣습니다. 그 순간만큼은 자기 자신보다 더 신뢰하는 출처에서 온 것이기 때문입니다. 실수는 이미 상류에서, 즉 모델에 의해 저질러졌고, 인간은 그 실수를 충실히 재현할 뿐입니다.
여기서 중요한 전환점이 있습니다. 타이포스쿼팅에서 공격자는 여러분의 손가락이 무엇으로 미끄러질지 추측했습니다. 하지만 슬롭스쿼팅에서는 공격자가 전혀 추측할 필요가 없습니다. 그들은 모델이 대규모로 실제로 어떤 출력을 내보내는지 읽어내고, 반복적으로 나타나는 이름을 등록합니다. 모델이 그들을 대신해 표적을 선정해 주는 셈이죠. 제가 실무에서 이 부분을 테스트해 봤을 때, 익숙한 유틸리티 라이브러리 설치 명령어를 AI에 물어보면, 처음에는 정확한 답을 내놓다가도 몇 번의 재시도 끝에 "혹시 이런 패키지도 괜찮으세요?"라며 전혀 듣도 보도 못한 가상의 이름을 추천하는 것을 경험했습니다.
이 공격이 통하는 이유: 환각은 잦고, 더 나쁜 것은 반복된다는 점입니다
모델의 환각이 드물고 무작위적이라면, 슬롭스쿼팅은 그저 흥미로운 주석에 불과했을 겁니다. 가짜 이름을 등록해 놓고 영원히 기다리다가 아무도 잡지 못하는 꼴이겠죠. 이 공격이 실제 위협이 되는 이유는 환각이 드물지도, 무작위적이지도 않기 때문입니다.
먼저 그 규모를 보시죠. 2025년 USENIX Security 컨퍼런스에서 발표된 연구, We Have a Package for You!는 파이썬과 자바스크립트용 16개 LLM에서 57만 6천 개의 코드 샘플을 생성하고, 모델이 추천한 모든 패키지를 확인했습니다. 결과는 충격적이었습니다. 추천된 패키지의 19.7%가 존재하지 않는 패키지였습니다. 이건 벤치마크 오차 범위 수준이 아닙니다. 다섯 개 중 하나 꼴이라는 거죠. 연구팀은 총 20만 5,474개의 서로 다른 환각 패키지 이름을 기록했습니다. 상업용 모델은 그나마 나았지만 (평균 최소 5.2%), 오픈소스 모델은 훨씬 심각했습니다 (최소 21.7%). 그 어떤 모델도 환각에서 자유롭지 못했습니다.
설령 모든 환각이 저마다 독특한 눈송이처럼 매번 다르게 나타난다면, 이 규모도 여전히 관리할 만했을 겁니다. 공격자가 20만 개가 넘는 이름을 모두 등록할 수도 없고, 어떤 이름이 사용자에게 다시 보일지 알 길이 없으니까요. 여기서 핵심은 환각이 **재현 가능(reproducible)**하다는 점입니다. 연구원들은 가짜 패키지를 생성했던 500개의 프롬프트를 가져와 각각 10번 더 실행했습니다. 그 결과, 환각 패키지의 43%가 매번 다시 나타났습니다. 58%는 한 번 이상 재현되었죠. 단 39%만이 다시 나타나지 않았을 뿐입니다.
이 대목에 주목하세요. 이런 조작된 이름의 거의 절반이 단순한 노이즈가 아닌, 모델의 안정적인 행동 특성이라는 겁니다. 이것은 공격의 경제성을 완전히 뒤집어 놓습니다. 공격자는 모든 이름을 등록할 필요가 없습니다. 그들은 모델의 출력을 채굴하고, 반복적으로 나오는 이름을 가려내어, 사용자에게 각인될 가능성이 높은 이름들만 등록합니다. 재현 가능성 자체가 공격자에게는 정찰 임무를 수행해 주는 것과 같습니다. 모델은 미래의 개발자가 어떤 가짜 이름을 가장 많이 건네받을지 반복해서 알려주는 셈이죠.
경고 패키지 이름이 실제 패키지처럼 보일 필요도 없습니다. 같은 연구에서 레벤슈타인 거리(Levenshtein distance)를 사용해 분석한 결과, 환각 이름 중 단 13%만이 실제 패키지의 단순한 오타였습니다. 약 38%는 중간 정도의 유사성을 가졌고, 거의 절반은 기존 패키지와 매우 달랐습니다. 즉, 완전히 지어낸 이름이지만, 주변 코드 맥락에서 보면 충분히 그럴듯하게 느껴졌다는 거죠. 이 마지막 범주에 속하는 패키지들은 타이포스쿼팅 탐지 시스템을 고스란히 통과하며, 그 이유에 대해서는 뒤에서 다시 설명하겠습니다.
킬 체인, 단계별 분석
이 모든 이야기는 단순한 이론이 아닙니다. 이는 깨끗하고 반복 가능한 일련의 과정이며, 각 단계는 여러분이 평범한 업무 중에도 목격했을 법한 일들입니다.
1. 모델이 임포트를 제안합니다. 여러분은 특정 기능을 요청하고, AI 어시스턴트는 코드와 함께 해당 문제에 맞는 의존성을 찾습니다. 그리고 하나의 이름을 제시합니다. 이 이름은 AI가 만들어낸 것이지만, 문법적으로는 완벽합니다. 해당 생태계의 관습을 따르고, 올바른 대소문자를 사용하며, "왠지 존재할 것 같은" 느낌을 줍니다.
2. 이름이 그럴듯해서 여러분은 그것을 신뢰합니다. 이것이 가장 핵심적인 단계이며, 기술적인 것이 아니라 심리적인 부분입니다. 자신감 넘치는 AI의 출력은 마치 노련한 선배 개발자의 PR을 검토하듯이 여러분의 경계심을 자연스럽게 무너뜨립니다. 패키지 이름은 관용적입니다. 어떤 부분도 "위험"으로 패턴 매칭되지 않습니다. 여러분은 로직을 검토하고 있지, 네 단어짜리 패키지 이름이 진짜인지 감사하고 있지 않습니다. 누가 그런 것까지 확인하겠어요?
3. 설치 과정에서 코드가 실행됩니다.
npm과 pip에서는 패키지를 설치하는 과정에서 스크립트가 자동으로 실행될 수 있습니다. postinstall 훅이나 setup.py 빌드 스텝 같은 것들 말이죠. 공격자의 페이로드는 여러분이 어떤 것을 임포트하거나 함수를 호출할 필요가 없습니다. install이 완료되는 순간, 코드는 이미 실행된 겁니다.
4. 자격 증명이 유출됩니다.
페이로드는 빌드 에이전트에 흔히 노출되어 있는 것들을 읽어들입니다. 환경 변수, ~/.aws/credentials, ~/.npmrc 토큰, GITHUB_TOKEN, .env 파일 등. 이 정보들은 공격자가 통제하는 엔드포인트로 POST됩니다. 외부에서 보면 패키지가 설치 중에 메타데이터를 가져오는 것처럼 보이지만, 내부적으로는 여러분의 CI/CD가 낯선 이에게 열쇠를 넘겨준 것과 다름없습니다.
이 모든 과정은 섬뜩할 정도로 조용합니다. 익스플로잇도, CVE도, 교묘한 메모리 손상도 없습니다. 개발자는 그저 AI가 제시한 이름을 신뢰했고, 하루에도 수십 번 실행하는 표준 설치 명령어를 실행했을 뿐입니다. 공격의 전부가 바로 이것입니다.
그리고 사람들이 이 '신뢰' 단계에 빠져든다는 것은 가설이 아닙니다. Lasso Security의 보안 연구원 바르 라냐도(Bar Lanyado)는 모델들이 반복적으로 huggingface-cli라는 파이썬 패키지를 환각하는 것을 발견했습니다. 그는 실험 삼아 PyPI에 정확히 그 이름으로 빈 패키지를 등록했습니다. 그 후 3개월 동안 이 패키지는 1만 5천 건 이상의 실제 다운로드를 기록했으며, 심지어 Alibaba의 GraphTranslator 프로젝트는 README에서 pip install huggingface-cli를 추천하기에 이르렀습니다. 실제 도구는 pip install -U "huggingface_hub[cli]"로 설치되는데 말이죠. 라냐도의 패키지는 의도적으로 무해했지만, 슬롭스쿼터의 패키지는 그렇지 않을 것입니다.
동일한 아이디어, 네 가지 생태계, 네 가지 다른 피해 범위
간략하게 말하면 "자바스크립트, PHP, Go 모두에 영향을 미친다" 정도입니다. 하지만 더 정확히 말하면, 각 생태계가 공격자에게 허용하는 공격 범위가 다르며, 그 차이를 아는 것이 방어 예산을 어디에 집중할지 결정하는 데 도움이 됩니다.
npm은 공격자에게 가장 많은 것을 제공합니다. preinstall, install, postinstall과 같은 라이프사이클 스크립트는 npm install 시 자동으로 실행됩니다. 이것이 고전적인 공격 벡터이며, 이 때문에 npm 생태계가 마침내 변화하고 있습니다. pnpm v10은 2025년 초 의존성 라이프사이클 스크립트를 기본적으로 비활성화했으며, npm도 뒤를 따랐습니다. 2026년 6월에는 npm v12에서 자동 스크립트 실행이 기본적으로 꺼질 것이라고 발표되었습니다. 여러분이 해당 버전들을 사용하기 전까지는 postinstall은 CI/CD에 겨눠진 장전된 총과 같습니다.
package.json (악성 의존성)
{
"name": "requests-oauth2-helper",
"version": "1.0.3",
"scripts": {
"postinstall": "node ./collect.js"
}
}
pip은 그 뒤를 바짝 쫓고 있습니다. 소스 배포판(source distribution)은 설치 시 메타데이터를 계산하고 빌드하기 위해 setup.py를 실행합니다. 이는 pip install 시 임의의 코드가 실행될 수 있음을 의미합니다. 휠(Wheel, .whl)은 설치 시 코드를 동일하게 실행하지 않기 때문에 --only-binary는 단순한 기능이 아니라 실제적인 강화 수단이 됩니다.
# 소스 빌드를 거부하고, 미리 빌드된 휠만 허용합니다.
pip install --only-binary :all: requests-oauth2-helper
Composer는 의도적으로 세 생태계 중 가장 안전합니다. Composer는 루트 패키지의 composer.json에 정의된 스크립트만 실행합니다. 의존성 패키지 자체의 scripts 블록은 무시됩니다. 따라서 슬롭스쿼팅된 Composer 패키지는 npm 패키지가 postinstall을 실행하는 것처럼 자동 post-install-cmd를 실행할 수 없습니다. 유일한 예외는 플러그인입니다. 악성 Composer 플러그인은 설치 이벤트를 후킹할 수 있으므로, 신뢰할 수 없는 프로젝트에 대해서는 composer install --no-plugins --no-scripts를 사용하는 이유가 됩니다. 페이로드가 실행되려면 여러분의 코드가 실제로 그것을 호출할 때까지 기다려야 하는데, 이는 '설치 시 실행'보다 훨씬 더 높은 장벽입니다.
Go는 설치 스크립트 자체가 없으므로 킬 체인이 바뀝니다. go get이나 go build는 패키지를 추가하는 순간 임의의 설정 코드를 실행하지 않습니다. 슬롭스쿼팅된 Go 모듈의 악성 코드는 프로그램이 이를 처음 실행할 때, 즉 임포트 시 init() 함수를 통해 또는 go test 중에 실행됩니다. 늦게 실행되지만, 실행되지 않는 것은 아닙니다.
Go는 모듈 프록시를 통해 독특한 변수를 추가합니다. Socket은 2021년 11월에 업로드되었던 BoltDB의 백도어 타이포스쿼트 버전 github.com/boltdb-go/bolt를 발견했습니다. 이 버전은 Go 모듈 미러에 캐시된 후 Git 태그가 깨끗한 코드로 재작성되었습니다. 하지만 프록시는 캐시된 악성 버전을 계속 제공했습니다. 이 문제는 3년 넘게 감지되지 않았습니다. 빌드를 재현 가능하게 만들도록 설계된 캐싱이 오히려 오염된 버전을 영구적으로 만드는 결과를 낳은 거죠.
따라서 단순히 "하나의 공격, 세 가지 언어"로 생각할 것이 아닙니다. npm과 pip은 설치 시 발동하고, Composer는 플러그인이나 명시적 호출을 기다리며, Go는 실행을 기다린 후 악성 버전을 영원히 기억합니다. 슬롭스쿼터는 가장 빠르고 조용한 트리거를 제공하는 생태계를 선택할 것입니다.
왜 기존 공급망 방어 체계는 이를 잡아내지 못할까
이제 불편한 진실을 이야기할 차례입니다. 여러분이 이미 실행하고 있는 대부분의 보안 통제는 다른 위협 모델을 위해 구축되었고, 슬롭스쿼팅은 그 틈새를 미끄러져 통과합니다.
록파일(Lockfiles)은 첫 설치 이후에만 도움이 됩니다. package-lock.json이나 composer.lock은 정확한 버전과 해시를 고정하여 의존성이 사용자 모르게 변경되는 것을 방지합니다. 이것은 여러분이 이미 검증하고 잠근 패키지에는 훌륭한 방어책입니다. 그러나 슬롭스쿼팅은 완전히 새로운 이름의 첫 설치를 노립니다. 록파일에는 아직 아무것도 없습니다. 여러분이 이 패키지를 설치한 적이 없기 때문입니다. AI가 방금 30초 전에 제안했을 뿐이죠. 록파일은 여러분이 처음 가져온 악성 버전을 충실히 기록하고, 이제 그 버전이 고정됩니다. 록파일은 연속성을 보호하지, 첫 접촉을 보호하지 않습니다.
스캐너는 '알려진 악성'을 찾지만, 이것은 '전례 없는' 것입니다. 취약점 스캐너나 악성 코드 피드는 이미 누군가 플래그한 패키지와 일치하는 것을 찾습니다. 어제 등록되어 이번 분기부터 반복되는 환각을 노리는 슬롭스쿼팅 패키지는 CVE도, 권고도, 평판도, 이력도 없습니다. 부재로 인해 '클린' 상태로 간주됩니다. 스캐너가 고장 난 것이 아닙니다. 그것은 다른 질문에 답하고 있을 뿐입니다. "이것이 알려진 위협인가?"는 "이것이 사람이 선택한 진짜 패키지인가?"와 다른 질문입니다.
타이포스쿼팅 탐지는 편집 거리에 기반하지만, 환각 이름의 절반은 아무것도 닮지 않았습니다. 타이포스쿼팅에 대한 표준 방어는 문자열 유사성을 측정합니다. expres를 express로 바꾸는 데 몇 번의 편집이 필요한가요? 유사한 오타를 플래그합니다. 하지만 레벤슈타인 거리 연구 결과를 기억하세요. 환각 이름의 거의 절반은 어떤 실제 패키지와도 매우 달랐습니다. requests-oauth2-helper는 실제 패키지에서 한 번의 편집으로 얻어지는 이름이 아닙니다. 기존 이름을 변형한 것도 아닙니다. 그럴듯하게 들리는 완전히 새로운 발명품일 뿐이죠. 거리를 측정할 만한 실제 이웃 패키지가 없으므로 탐지기는 걸릴 것이 없습니다.
이 세 가지를 종합해 보면, 이 방어 체계의 빈틈이 명확해집니다. 이 모든 방어책은 악성 패키지가 변경되었거나(록파일), 이전에 플래그되었거나(스캐너), 실제 패키지를 모방했거나(타이포스쿼팅 탐지) 하는 상황을 가정합니다. 슬롭스쿼팅은 이 중 아무것도 해당하지 않습니다. 이것은 기계가 자신감 넘치는 어조로 선택한, 완전히 새로운 이름이며, 전례가 없고, 아무것도 닮지 않은 이름입니다. 방어책이 약한 것이 아닙니다. 그저 다른 곳을 겨냥하고 있을 뿐이죠.
실제로 작동하는 방법: 맹목적으로 이름을 리포지토리에 넣지 마세요
다행스러운 소식은 해결책이 특별한 것이 아니라는 점입니다. 어떤 의존성에도 적용되어야 하는 기본적인 본능을, 여러분이 과도하게 신뢰하기 시작한 출처에 적용하는 것입니다. 새로운 제품 카테고리가 필요한 것이 아닙니다. AI의 패키지 제안을 인용문처럼 취급하는 것을 멈춰야 합니다.
패키지가 존재하는지, 그리고 유지보수되고 있는지 확인한 후에 여러분의 시스템에 닿게 하세요. 모델이 알려준 것을 설치하기 전에 반드시 검색해 보세요. 레지스트리에 존재하는가? 다운로드 수는 몇 회인가? 버전은 얼마나 되며, 마지막 릴리스는 언제인가? 누가 퍼블리시하고 있으며, 사람이 명확히 유지보수하는 리포지토리가 있는가? 슬롭스쿼팅 패키지는 보통 등록된 지 며칠밖에 되지 않았고, 의심스러울 정도로 딱 떨어지는 다운로드 수를 가지며, 이력이 전혀 없을 겁니다. 30초만 살펴봐도 대부분의 이런 공격은 무력화됩니다.
# npm: 존재하는가, 누가 소유하는가, 얼마나 오래되었는가?
npm view requests-oauth2-helper
# PyPI: 프로젝트 페이지, 릴리스 이력, 유지보수자를 확인하세요.
pip index versions requests-oauth2-helper
첫 번째 명령이 404를 반환한다면, 모델이 숨겨진 보석을 찾아준 것이 아닙니다. 그냥 지어낸 겁니다.
설치 스크립트를 기본적으로 비활성화하세요. 이 하나의 통제만으로도 킬 체인의 가장 시끄러운 버전이 무력화됩니다. 자동 실행을 끄고, 실제 빌드 스텝은 명시적인 예외로 허용하고 기본값은 아니게 만드세요.
:::tabs
npm
# 전역적으로 라이프사이클 스크립트를 비활성화합니다.
# 필요한 드문 패키지만 예외적으로 허용 목록에 추가하세요.
npm config set ignore-scripts true
pnpm
# pnpm v10+는 의존성 스크립트를 기본적으로 차단합니다.
# 실제로 신뢰하는 것만 승인하세요.
pnpm approve-builds
pip
# 미리 빌드된 휠을 선호하여 설치 시 setup.py가 실행되지 않도록 합니다.
pip install --only-binary :all: <package>
composer
# 신뢰할 수 없는 프로젝트인가요? 플러그인도, 스크립트도 실행하지 마세요.
composer install --no-plugins --no-scripts
:::
약 2%의 npm 패키지만이 설치 스크립트를 합법적으로 사용하며, 바로 이 때문에 생태계는 '기본적으로 비활성화'가 합리적인 선택이라고 결정했습니다. 여러분은 거의 아무것도 잃지 않고 페이로드가 의존하던 문을 닫아버리는 겁니다.
모든 것을 허용 목록(Allowlist)이 있는 프라이빗 레지스트리를 통해 프록시하세요. 빌드 에이전트는 공개 레지스트리에 접근하여 모델이 지정한 어떤 것이든 가져올 수 있어서는 안 됩니다. Artifactory, Verdaccio, 프라이빗 PyPI, Composer의 Satis와 같은 프록시를 앞에 두고, 검토된 패키지만 허용하세요. 이제 환각 이름은 설치 후에 실패하는 것이 아니라, 승인된 목록에 없기 때문에 설치 전에 실패하게 됩니다. 이것이야말로 확장 가능한 통제 방법입니다. 의사 결정의 주체가 "개발자가 알아차렸는가"에서 "이것이 목록에 있는가"로 바뀌기 때문입니다.
새로운 버전에 대한 '성숙 지연(maturity delay)'을 추가하세요.
pnpm v11에는 minimumReleaseAge 기능이 추가되었으며, 기본값은 1440분(24시간)입니다. 이 기능은 패키지 버전이 충분히 공개되어 커뮤니티가 명백한 악성 코드를 발견할 시간을 가질 때까지 설치를 거부합니다. 신선한 환각을 노리고 서두르는 슬롭스쿼팅 패키지는 바로 이 '냉각 기간'이 막아내기 좋은 유형입니다.
그리고 이 모든 규칙 아래에 있는 단 하나의 규칙: AI가 제안했다는 이유만으로 의존성을 리포지토리에 추가하지 마세요. AI의 패키지 제안은 가설이지, 인용문이 아닙니다. 이전에 본 적 없는 계정의 Stack Overflow 답변을 대하는 것과 똑같이 대하세요. 맞을 수도 있지만, 확인해 볼 가치가 있으며, 절대 맹목적으로 신뢰해서는 안 됩니다. 이 공격 전체는 킬 체인의 두 번째 단계에서 발생하는 '잘못된 신뢰'라는 한순간에 달려 있습니다. 이름을 확인하면 공격은 설 자리를 잃게 됩니다.
불편한 진실은 모델이 당분간 이런 행동을 멈추지 않을 것이라는 점입니다. 환각은 이러한 시스템이 텍스트를 생성하는 방식의 본질적인 속성이며, 가짜 패키지 이름은 내부적으로 실제 이름과 똑같이 보입니다. 그러므로 부담은 여러분에게 있습니다. install 명령어를 실행하는 인간에게 말이죠. 여러분의 어시스턴트가 방금 알려준 이름은 실제 라이브러리일 수도 있고, 실제 라이브러리의 이름을 가장한 공격자의 패키지일 수도 있습니다. 이 둘을 구별하는 유일한 방법은 설치 전에 확인하는 것이고, 슬롭스쿼팅의 핵심은 바로 여러분이 그렇게 하지 않을 것이라는 점을 노리는 것입니다.
P.S. 이 글을 읽어주셔서 감사합니다! 여기에 표현된 아이디어와 의견은 저의 개인적인 생각입니다. 영어가 모국어가 아니어서 AI의 도움을 받아 문법 교정 및 글의 명확성을 높였습니다. 혹시라도 어색하게 느껴지는 부분이 있다면 너그러이 이해해 주시면 감사하겠습니다!
원본은 nazarboyko.com에 게재되었습니다.
이 글이 마음에 드셨나요? LinkedIn에서 연락 주세요. 언제든 기꺼이 대화하고, 아이디어를 나누고, 인사 나눌 준비가 되어 있습니다. 👋
원문: https://dev.to/nazar-boyko/slopsquatting-the-supply-chain-attack-that-weaponizes-ai-hallucinations-2m2 수집일: 2026-07-30 01:13:02