
AI 모델 파일은 정말 '안전'한가 — 스캐너를 실기에서 돌려보고 알게 된, 막을 수 있는 공격과 막을 수 없는 공격
요약
AI 모델 파일(pickle, .pt 등)을 통한 원격 코드 실행(RCE) 위험성을 분석하고, modelscan과 picklescan 스캐너의 탐지 성능을 실기 테스트로 검증합니다. 스캐너의 한계를 지적하며 safetensors 사용 및 다중 레이어 방어 전략을 제안합니다.
핵심 포인트
- 모델 파일은 데이터가 아닌 실행 가능한 코드로서 RCE 공격의 통로가 될 수 있음
- modelscan은 블랙리스트 방식의 한계로 인해 미등록 모듈 경유 공격에 취약함
- picklescan은 상대적으로 견고하지만 단일 스캐너에만 의존하는 것은 위험함
- safetensors 사용, 다중 스캐너 병용, 샌드박스 로드 등 계층적 방어가 필수적임
OWASP MCP Top 10의 MCP04:2025 — 공급망 공격과 의존성 변조 (Supply Chain Attack and Dependency Tampering) 는, AI 에이전트가 '외부에서 가져온 것'을 검증 없이 받아들이는 구조 그 자체를 공략합니다. 그 가장 알기 쉬운 공격 표면이 바로 모델 파일 (Model Files) 입니다.
pickle
/.pt
/.joblib
/.h5
/.keras
의 상당수는, 로드하는 순간 임의의 Python 코드를 실행할 수 있습니다. 데이터가 아니라 실질적인 '코드'입니다.
torch.load()
나 joblib.load()
에 악의적인 파일을 전달하는 것만으로 RCE(원격 코드 실행)가 발생합니다. 이는 이미 알려진 사실입니다. 문제는 MCP 서버나 에이전트가 외부 모델을 읽어들이는 구성이 급증하고 있으며, HuggingFace 유래 모델이 사실상의 신뢰 경계(Trust Boundary)가 되고 있다는 점입니다. 그렇다면 HuggingFace의 자동 스캔은 실제로 어디까지 지켜줄 수 있을까요? 직접 돌려보며 확인했습니다.
실기 랩: 스캐너 2개를 나란히 배치하여 검증하기
격리 환경(Kali / venv 분리)에, HuggingFace 파이프라인에서 실제로 사용되는 두 가지 스캐너를 도입했습니다.
- modelscan (ProtectAI / OSS 버전. 상용 Guardian의 토대)
- picklescan (HF 네이티브의 최전선 스캐너)
'양성', '기존 악성 (os.system)', '블랙리스트 외 모듈 경유', '미지원 포맷' 파일을 생성하고, **스캔 결과와 로드 시의 실제 동작(무해한 카나리아 생성으로 탐지)**을 대조하는 하네스(Harness)를 구축했습니다. 결과는 다음과 같습니다:
手法 modelscan picklescan
os.system(既知の悪性・対照) FLAGGED FLAGGED
블록리스트 외 모듈 경유 clean FLAGGED
...
알게 된 점
1. modelscan은 '블랙리스트 방식' = 원리적인 허점이 있음
위험 모듈의 고정 리스트 (os, subprocess, builtins.eval …)로 판정하기 때문에, 리스트에 없는 모듈을 경유한 실행이나, 스캐너가 미구현한 포맷 (.npz = zip 버전 numpy)은 그냥 통과되었습니다. 동작(Behavior)이 아니라 '이름'을 보고 있는 것입니다.
2. 하지만 HF 최전선의 picklescan은 예상보다 견고함
동일한 파일을 picklescan은 모두 탐지했습니다. 블랙리스트가 넓고, .npz도 zip으로서 재귀적으로 전개하여 내부를 검사합니다.
'OSS 버전 modelscan을 회피할 수 있었다 = HuggingFace를 회피할 수 있었다'는 아닙니다. 로컬 도구 단독의 결과를 실제 환경의 증거로 오인해서는 안 됩니다.
3. 그럼에도 단독으로는 불완전함
picklescan 역시 과거에 파서(Parser) 레벨의 회피(연결된 pickle, 부정확한 zip 등)로 인해 여러 개의 CVE가 발생했습니다. 어떤 스캐너도 단독으로는 완전하지 않습니다.
방어 측(SOC/탐지)의 실무적인 결론
스캐너에만 의존하지 않고, 레이어(Layer)로 방어하는 것이 현실적인 해답입니다.
- 단일 스캐너를 신뢰하지 말 것 — 여러 엔진을 병용하여, 하나라도 FLAG라면 격리할 것.
- 포맷으로 차단할 것 — 가능하다면
.pkl/.joblib을 금지하고, 코드 실행을 포함하지 않는safetensors로 한정할 것. - 프로비넌스(Provenance) 검증 — 서명, 해시, 발행처 확인. '유명 리포지토리 이름과 유사하게 만든 가짜'는 MCP04의 전형적인 수법입니다.
- 샌드박스에서 로드할 것 — 검증되지 않은 모델은 네트워크가 차단된 컨테이너 내부에서 실행할 것. 로드 시의
exec/connect()를 탐지 규칙화할 것. - 탐지할 것 —
pickle.load/torch.load계열의 호출과, 직후의 자식 프로세스 생성 및 외부 통신을 **상관관계(Correlation)**로 모니터링할 것.
모든 내용은 공개된 지식(공개 도구, OWASP, 공개 CVE)으로만 구성되었으며, 방어 및 퍼플 팀(Purple Team) 목적으로 본인의 격리된 랩 환경에서만 검증했습니다. 악용을 의도한 신규 공격 코드는 포함하지 않습니다.
관련 링크
- 작동하는 OSS: github.com/kta1kri/mcp-detection-lab (MCP 전체 10가지 리스크에 대한 Sigma 탐지 규칙)
- 무료 기사: OWASP MCP Top 10 총람 / 툴 포이즈닝 (Tool Poisoning)
- 구현·탐지·격리 상세 해설 (유료 Book): OWASP MCP Top 10 구현·탐지·격리 가이드의 MCP04 장에서 공급망 전체의 탐지 설계를 다루고 있습니다.
토론 (Discussion)

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기