Hugging Face의 ‘OpenAI 사칭’ 악성 저장소가 남긴 경고
OpenAI 공개 모델처럼 보이게 꾸민 악성 Hugging Face 저장소 보도는, AI 모델을 내려받아 실행하는 과정도 npm이나 PyPI 패키지를 쓰는 일만큼 꼼꼼히 확인해야 한다는 경고다. 이제는 모델 파일만이 아니라 로더, 노트북, 설치 스크립트, 의존성까지 출처와 실행 범위를 봐야 한다.
2026-05-13
왜 중요한가
- AI 도입에서 중요한 것은 모델 성능만이 아니다. 어떤 모델, 어댑터, 데이터셋, 노트북을 어디서 가져와 어떻게 실행하는지도 똑같이 중요해졌다.
- 모델 허브는 이미 개발자들이 패키지 저장소처럼 쓰는 공간이지만, 많은 팀은 아직 패키지를 설치할 때보다 느슨하게 저장소를 내려받고 실행한다.
- AI 저장소에는 가중치 파일만 있는 것이 아니다. 로더, 토크나이저, 커스텀 모델 코드, 노트북, 설치 스크립트, 의존성 목록이 함께 들어갈 수 있다.
- 보도에 따르면 HiddenLayer는 OpenAI 배포물처럼 보이게 만든 악성 Hugging Face 저장소와 비슷한 로더 로직을 가진 추가 저장소들을 발견했다.
- IDC가 언급한 것처럼 agentic AI 시스템에서 BOM 요구가 커지면, 모델 출처와 구성요소를 기록하는 일이 기업 도입의 실제 운영 절차가 될 가능성이 높다.
핵심 관찰
- Hugging Face 검색 결과에서는 공식 OpenAI 저장소와 서드파티 양자화·파생 저장소가 한 화면에 함께 보인다.
- 공식 저장소에도 .bin 같은 바이너리 파일이 있을 수 있어, 확장자만 보고 위험 여부를 판단하면 오탐이 생긴다.
- 반대로 악성 동작은 README 명령어, 설치 스크립트, 노트북, 커스텀 코드, 의존성 경로에 숨어 있을 수 있어 파일명 확인만으로는 부족하다.
- 실무에서는 작성자와 네임스페이스, base_model 출처, 파일 목록, 실행되는 구성요소, 고정된 커밋 SHA, 오프라인·샌드박스 로딩, 기본값으로 trust_remote_code를 쓰지 않는 절차를 함께 봐야 한다.
해석
핵심은 Hugging Face가 위험하다는 말이 아니다. 모델 허브를 쓰는 방식이 이미 소프트웨어 공급망의 일부가 되었는데, 검토 절차는 그만큼 따라오지 못했다는 점이다.
AI 저장소는 ‘모델 파일 하나’가 아니라 실행될 수 있는 여러 파일과 설정의 묶음에 가깝다. 그래서 출처 확인도 모델 카드나 다운로드 수에서 끝나지 않고, 실제로 무엇이 실행되는지까지 내려가야 한다.
연구 단계에서는 빠르게 받아 실험하는 흐름이 필요하지만, 제품이나 내부 시스템에 붙일 때는 허용 목록, 파일 목록 기록, 커밋 고정, 샌드박스 실행 같은 기본 절차를 따로 두는 편이 안전하다.
누구에게 도움이 되나
- ML/플랫폼 팀: 모델 허브 allowlist, artifact BOM, pinned revision, sandboxed loading, egress 제한을 표준 배포 절차로 넣는다.
- 보안 팀: SCA를 dependency manifest만 보지 말고 AI repo의 custom loader/notebook/script/file-tree까지 확장한다.
- 제품팀: 고객에게 “HF에서 아무 모델이나 붙이세요” 대신 verified source/import policy를 제공해야 한다.
- 교육/개인 개발자: 모델을 실행하기 전 README의 명령어를 그대로 복붙하지 말고, 공식 조직/파일 목록/확장자/커밋을 먼저 확인한다.
어디에 바로 써볼 수 있나
- 공개 모델/벤치마크 재현 시 model card citation만이 아니라 artifact provenance와 file manifest를 같이 기록하는 기준으로 쓸 수 있다.
- HF/GitHub에서 모델을 받기 전 공식 namespace 여부, base_model tag, commit SHA, safetensors/GGUF 여부, custom code 필요 여부, 실행 파일/스크립트 존재 여부를 체크리스트화한다.
- raw/knowledge에 AI artifact를 기록할 때 URL만 남기지 말고 source namespace, version/sha, artifact type, executable components, load policy를 함께 남기게 할 수 있다.
- 외부 repo를 clone/run하기 전 lightweight metadata scan을 기본 preflight로 두고, trust_remote_code=True, notebook 실행, install script 실행은 별도 승인 대상으로 분리하는 것이 좋다.
- 모델 허브 allowlist, artifact BOM, pinned revision, sandboxed loading, egress 제한을 표준 배포 절차로 넣는다.
- SCA를 dependency manifest만 보지 말고 AI repo의 custom loader/notebook/script/file-tree까지 확장한다.
- 고객에게 “HF에서 아무 모델이나 붙이세요” 대신 verified source/import policy를 제공해야 한다.
- 모델을 실행하기 전 README의 명령어를 그대로 복붙하지 말고, 공식 조직/파일 목록/확장자/커밋을 먼저 확인한다.
주요 출처
- AI News
- HiddenLayer Research landing
- Official OpenAI HF org
- Official OpenAI HF API: ,
- [HF search API used in scan](<https://huggingface.co/api/models?search=openai%20gpt-oss&limit=10>)
공식 repo / docs
- AI News
- HiddenLayer Research landing
- Official OpenAI HF org
- Official OpenAI HF API: ,
- [HF search API used in scan](<https://huggingface.co/api/models?search=openai%20gpt-oss&limit=10>)
주의점
- 이번 정리는 보도와 공개 메타데이터 확인에 근거한 신호이며, HiddenLayer 원문의 상세 IOC는 충분히 확보하지 못했다.
- 악성 의심 저장소는 안전상 다운로드하거나 실행하지 않았다. 따라서 악성 동작을 직접 재현한 검토는 아니다.
- 메타데이터 스캐너는 탐지기가 아니라 사전 점검용 체크리스트에 가깝다. .bin은 정상 가중치일 수도 있고, 악성 로더는 평범한 .py, 노트북, 의존성 안에 숨어 있을 수도 있다.
- 공식 네임스페이스라고 해서 언제나 안전하다는 뜻도 아니다. 계정 탈취, 의존성 변조, 커스텀 코드 취약점은 별도로 봐야 한다.
- 공급망 보안 절차는 속도를 늦출 수 있다. 연구용 프로토타입과 실제 배포 환경은 점검 강도를 다르게 가져가는 것이 현실적이다.
다음에 볼 포인트
- 모델 허브와 기업 AI 도입 과정에서 모델·데이터셋·노트북까지 포함한 artifact BOM 요구가 실제 제품 기본값으로 들어오는지 볼 것.
- Hugging Face나 보안 도구들이 네임스페이스, 커밋 고정, 실행 파일, trust_remote_code, 노트북 실행을 더 쉽게 점검하도록 만드는지 볼 것.
- 기업과 연구팀이 외부 모델 저장소를 받을 때 허용 목록, 샌드박스 로딩, 외부 통신 제한을 표준 절차로 두기 시작하는지 볼 것.