베타에서 얻은 교훈
5억 회 이상의 다운로드, 오픈소스 커뮤니티로부터 수년간의 요청, 그리고 Hugging Face의 상위 제품 자리를 거쳐 Unsloth는 베타 데스크톱 앱인 Unsloth Studio를 출시했다. Unsloth는 AI 모델의 파인튜닝과 실행, 직접 소유한 하드웨어에서의 로컬 실행까지 더 빠르고, 더 쉽고, 더 저렴하게 만든다. 이 앱은 Unsloth Studio를 통해 여러 기능을 한곳에 모아 사용자가 이제 대시보드 설치 또는 수동 설치를 사용할 수 있게 한다.
오픈소스 프로젝트는 다른 코드 소스나 플랫폼에 의존하는데, Unsloth의 경우 로컬 모델링의 얼리 어답터로서 Hugging Face 플랫폼의 자유로움과 Unsloth의 다양한 패키지가 제공하는 파인튜닝 기능을 결합한 제품을 만들었다.
Unsloth Studio는 제품 출시 이후 OSS로서 빠른 속도로 업데이트를 진행하면서 AI 분야에서 급변하는 보안 환경에 적응해 왔다. 예를 들어, Constructors에 의해 침해된 LiteLLM 버전 1.82.7과 1.82.8이 PyPI에 등장했는데, 침해된 Trivy 스캐너로부터 고정되지 않은(unpinned) 상태로 가져와져 LiteLLM의 CircleCI 파이프라인에 유입되어 배포 자격 증명이 노출되었다. PyPI는 한 시간 이내에 두 버전을 신속히 격리했지만 보안 도구 자체가 공격 경로의 일부가 되어 다운스트림에서 사용되고 있었다. Unsloth는 신속하게 제품 업데이트를 푸시하여 대응했다.
한 달 후, Unsloth의 데스크톱 보안을 규정짓는 또 다른 사건이 발생했다. Hugging Face 저장소 안에 숨어 있던 정보 탈취 프로그램(infostealer)이었다. 모델 다운로드 및 공유의 선도적 플랫폼인 Hugging Face는 자신도 모르게 정보 탈취 프로그램을 포함한저장소를 호스팅하고 있었던 것이다. 이 저장소는 OpenAI의 Privacy Filter 릴리스를 사칭하며 모델 카드를 거의 그대로 복사했다. 이 저장소의 loader.py는 Windows에서 정보 탈취 프로그램을 가져와 실행했다. 이후 이 저장소는 트렌딩 1위에 올랐고 약 244,000회의 다운로드 수를 기록했는데, HiddenLayer는 이 수치가 거의 확실히 부풀려진 것이라고 밝혔다.
이 두 사건은 Unsloth의 보안 제품 로드맵의 기본 방향, 즉 빠르게 움직이라는 원칙을 형성하는 데 기여했다.
Unsloth가 제품 보안을 다듬은 방식
이 데스크톱 앱은 초기부터 OSS의 최전선에 있었으며 변화하는 환경에 빠르게 적응해 왔다. Unsloth는 최종 사용자에게 최적의 안전을 보장하기 위한 프로토콜을 수립했다. 여러 차례의 릴리스 끝에, 다가오는 Open Source AI 주간을 맞아 Unsloth는 Unsloth Studio와 Unsloth Desktop을 위한 보안 개요 를 발표하며 그들의 보안이 작동하는 방식을 높은 수준에서 설명했다.
데스크톱 앱은 파인튜닝 환경에서의 안전을 최우선으로 하면서도, 사용자는 여전히 전 범위의 모델을 선택할 수 있다. Unsloth 보안의 작동 방식은 워크플로가 다운로드에서 실행 단계로 넘어갈 때 4단계 검사 프로세스, 즉 지문에 묶인 코드 승인, 별도의 가중치 파일 게이트, 프로브된 OS 샌드박스, 그리고 강제된 패키지 콘텐츠 스캔을 트리거하는 것이다. 이러한 프로토콜은 기존 통제를 대체하는 것이 아니라 보완하는 방식으로 보호를 위해 마련되었으며, 사용자는 이러한 검사를 활용하면서도 권고 기반 스캔, 고정된 리비전, 네트워크 제한, 범위가 지정된 자격 증명을 그대로 유지할 수 있다. 하나씩 살펴보면 각 작업은 보안 계층화에서 서로 다른 목적을 수행한다.

1. 승인은 이름이 아니라 코드를 따른다
모델의 커스텀 Python 코드를 승인한 뒤, 저장소가 변경된 후에 다시 돌아왔다고 상상해 보자. 과거의 승인이 여전히 유효해야 할까? Unsloth Studio는 그렇지 않다고 말한다. 저장소는 스캔된 코드의 지문을 생성하며 매번 로드 시 그 지문과 스캐너 버전을 재검증한다. 저장된 승인은 반복되는 대화 상자를 없애줄 수 있으며, 새로운 스캔과 함께 계속 진행된다. 변경된 코드에는 새로운 동의가 필요하다. 어댑터와 베이스 모델을 함께 로드하는 경우, Studio는 토크나이저, 프로세서, 중첩된 구성을 포함해 두 저장소를 모두 평가한다. 본질적으로 무언가 변경되었다면 Unsloth Studio는 그 사실을 알아차린다.
어떤 변경이든 이전 지문을 갱신한다. 높음 및 중간 심각도의 발견 항목에는 현재 지문과 일치하는 승인이 필요하다. 원격 코드를 검사해야 하지만 가져올 수 없는 경우, 로드는 차단된다. 신뢰할 수 있는 퍼블리셔에게도 일괄 면제는 주어지지 않으며, 자사(first-party) 저장소라도 중단될 수 있다. 스캐너는 구체적인 행동들을 찾는다: 리버스 셸 열기, 클라우드 메타데이터 엔드포인트에 접근, 자격 증명 탈취 등이다. Studio는 추론, 학습, 내보내기 워커에서 이 게이트를 호출한다. 스캔은 샌드박스가 아니다. 일단 승인되면 원격 모델 코드는 Studio 사용자 권한으로 제한 없이 실행된다. 이 문서는 정적 패턴은 우회될 수 있다고 밝히고 있다.
관문 이미 인기 모델에서 작동합니다. deepseek-ai/deepseek-ocr은 승인을 요청하며 exec/eval 탐지 결과를 표시합니다. moonshotai/Kimi-VL-A3B-Instruct 역시 승인을 요청하며, 고급 난독화로 플래그가 지정되었습니다. 승인 대화상자는 결정을 내리기 전에 탐지 결과들을 나열합니다. 스캐너가 우려되는 내용을 찾지 못한 경우에도 사용자 지정 코드는 여전히 사용자의 허가가 필요합니다. Unsloth는 자체 조정 버전인 unsloth/DeepSeek-OCR 및 unsloth/DeepSeek-OCR-2 저장소에서 eval 호출과 기타 문제가 있는 부분들을 제거했습니다. 사용자는 앱 내에서 자신의 모델을 결정하고 승인 여부를 직접 판단할 수 있습니다.
2. 웨이트 파일 경고가 로딩 결정이 될 때
안전하지 않은 직렬화된 가중치, 악성 pickle 파일을 포함한 것들이 또 다른 위험 요소를 만듭니다. Studio는 이러한 파일들을 원격 코드 동의와 별도로 검사합니다. 커스텀 Python은 실행 경로 중 하나일 뿐이며, Unsloth Studio는 여러 접근 지점을 고려해 설계되었습니다.
Hugging Face 이후로 저장소에서 악성코드를 검사합니다 모델 페이지에 경고를 표시하며, studio는 해당 결과를 읽어 플래그된 파일을 차단합니다 선택된 로더가 역직렬화하는 경로에 포함됩니다. 여기에는 weight index가 참조하는 중첩된 shard도 포함됩니다. 이 스캐너는 플래그가 지정된 아티팩트를 unpickle하지 않고 스캔 결과를 읽습니다. 이 게이트는 fail-closed가 아닙니다. 저장소에 따르면, 스캔 메타데이터를 사용할 수 없거나 보류 중인 경우에도 로드가 진행될 수 있습니다. 일반 로컬 모델 폴더는 적용 대상이 아닙니다. Unsloth의 PyTorch 2.6+ 최소 요구 사항은 .bin 가중치가 다음과 함께 로드됨을 의미합니다. weights_only=True 그리고 동작은 테스트 가능합니다. 해당 테스트 저장소 mcpotato/42-eicar-street 경고에 안전하지 않은 파일들이 나열되고 해당 파일들이 한 번도 다운로드된 적 없음이 확인되기 때문에 로딩이 차단됩니다. Hugging Face 모델 중 1% 미만만이 잠재적 보안 문제를 가지고 있으며, Unsloth는 추가 보안을 위한 프로세스를 만들어 오픈소스에 대한 증거로서 Unsloth Studio 제품이 얼마나 견고해지고 있는지 잘 보여줍니다.
3. 의존성 내부 들여다보기
LiteLLM 사건의 교훈을 보면 권고(advisory) 검사만으로는 부족하다는 것이 분명합니다. 패키지는 익숙한 이름을 가진 채 어떤 권고가 존재하기도 전에 악성 릴리스를 배포할 수 있기 때문입니다. Unsloth의 패키지 콘텐츠 스캐너 자격 증명 접근, 난독화된 페이로드, 실행 가능한 시작 파일 및 설치 시점의 다운로드 후 실행 동작을 찾기 위해 아카이브 자체를 조사하십시오. Python 스캔 선언된 종속성과 전이적(transitive) 종속성을 모두 다룹니다. npm 스캐너는 설치 라이프사이클 스크립트를 실행하지 않고 다운로드한 tarball을 검사합니다. 변경된 페이로드는 영구 면제를 상속하는 대신 해당 발견 사항을 다시 열어 Unsloth 권고는 스캔 보고에는 포함되지만 차단하지는 않습니다; 콘텐츠 발견 사항이 강제 계층이므로 Unsloth는 여기에 관련성 규칙을 추가합니다.허용 목록에 있는 패키지만 스크립트를 실행할 수 있으며 npm 설치는 게시된 지 7일이 지나지 않은 패키지를 거부합니다. 검토되지 않은 패키지가 이를 실행하려 하면 CI가 실패합니다. 설치는 lockfile과 npm ci를 사용하며, 설치 프로그램은 사용자를 npm 11 이상으로 업그레이드합니다. npm ci 또는 cargo fetch 실행 전에 lockfile_supply_chain_audit.py가 Shai-Hulud 방식의 주입 징후를 검사합니다. 린터는 안전하지 않은 로더와 동적 실행을 검사하며, 발견 사항을 추적하기 위한 베이스라인을 사용합니다. Dependabot 업데이트에는 3~7일의 쿨다운이 적용됩니다. pip-audit, 서명 검사가 포함된 npm audit, cargo audit, OSV-Scanner, Semgrep 및 TruffleHog가 콘텐츠 검사와 함께 실행됩니다. 이 감사 워크플로우의 주석에는 2026년의 이전 침해 사고로 인해 Trivy를 의도적으로 사용하지 않는다고 명시되어 있습니다.
4. 샌드박스는 스스로의 가치를 증명해야 한다
AI와 모델링 시대에 샌드박스 검증이 매우 현실적인 문제가 되었기 때문에, 설치된 샌드박스 바이너리는 출발점일 뿐 보장은 아닙니다. Unsloth Studio는 도구를 안에서 실행합니다 OS 수준 샌드박스: Linux의 bubblewrap, macOS의 Seatbelt, Windows의 MXC입니다. Linux에서는 bubblewrap 바이너리와 그 상위 디렉터리들이 시스템 소유이며 그룹 또는 전체 사용자가 쓸 수 없는지 확인합니다. 그런 다음 저장소에 따르면, 이는 경계를 탐구한다. 샌드박스 처리된 코드가 호스트 센티넬 파일을 읽을 수 있습니까? 워크스페이스 심링크를 따라 그 파일에 접근할 수 있습니까? 워크스페이스 밖에 쓸 수 있습니까? 이 프로브는 또한 정상적인 워크스페이스 및 자식 프로세스 작업이 여전히 작동하는지 확인합니다.
사용자는 여전히 선택지가 있으며, 원하는 것을 고를 수 있습니다 승인 모드: ask, auto 또는 full. 자동 모드에서는 네트워크 및 파일시스템 가져오기가 승인 대상으로 표시되고, 파일 경로도 승인이 필요합니다. 위험한 셸 명령은 아예 차단됩니다. 도구 요청에는 Allow, Always allow, Deny 버튼이 표시됩니다. 엄격한 정책은 OS 격리를 사용할 수 없거나 필수 워크스페이스 검사가 완료되지 않으면 도구 실행을 거부합니다. 관대한 정책은 소프트웨어 보호 장치로 대체할 수 있으며, 실행 기록에 그 사실이 명시됩니다. 각 기록 에는 백엔드, 격리 상태, 제한 사항 및 정리 결과가 나열됩니다. HTML 및 MCP 아티팩트는 자체 Content Security Policy를 갖는 샌드박스 프레임 에서 렌더링됩니다.
리눅스 샌드박스는 네트워크 접근을 허용하고, 쓰기 가능한 모델 캐시 접근을 제공하며, 호스트 커널을 공유합니다. 네트워크 제한과 엄격하게 범위가 지정된 자격 증명과 함께 사용하면 이 프로세스가 최종 게이트 검사 역할을 합니다.
원격 접근 및 데스크톱 앱
앱에서 여러 사용자를 지원하면 관리형 계정도 가능해집니다: 각 사용자는 자신의 폴더만 볼 수 있고, 소유자의 Hugging Face 토큰은 절대 볼 수 없습니다. 관리형 계정은 모델을 사용하려면 소유자의 승인이 필요하며, 저장소 코드 실행은 차단됩니다. 최근 Unsloth는 Jev와의 협력을 발표했으며, 자신의 결정 모델을 관리하는 사용자.
Unsloth의 보안 감사 워크플로 는 읽기 전용 저장소 권한과 비지속 체크아웃 자격 증명을 사용합니다. 모든 GitHub Action은 전체 커밋 해시에 고정되어 있고, 아웃바운드 네트워크 허용 목록이 예기치 않은 송신을 차단합니다. CodeQL은 Python, JavaScript/TypeScript, Rust 및 GitHub Actions를 다룹니다. Unsloth는 개발 과정에서 보안 문제와 버그를 잡기 위해 Codex Security 와 반복적인 Codex 리뷰를 수행한다고 밝혔습니다.
라이브러리 접근 및 변경 사항
Unsloth의 핵심 라이브러리도 표현식을 평가하는 대신 고정된 조회 테이블을 사용하는 커스텀 데이터 타입 처리 로 표적화된 강화를 거쳤습니다. 상속된 실행 가능한 구성 필드는 삭제(sanitize) 처리되며, 회귀 테스트가 이 수정 사항을 보호합니다. Studio의 미들웨어 테스트는 과도하게 큰 청크 요청을 거부하여 Content-Length 검사만으로는 놓칠 수 있는 사례를 잡아내며, 데스크톱 릴리스에는 자체 검사가 적용됩니다.
사전 빌드된 llama.cpp 바이너리는 SHA-256 다이제스트로 검증되고, Windows 서명은 별도로 감사됩니다. 모든 Unsloth Desktop 릴리스는 VirusTotal로 스캔됩니다. 공개된 1건의 예시에서는 스캔 당시 70개 벤더 전체에서 0건의 탐지 결과를 보였습니다. Unsloth는 각 결과가 해당 시점에 검사한 파일 또는 커밋에만 적용된다고 밝혔습니다.
더 단순한 접근 방식과 비교한 변화
| 기능 | Unsloth 솔루션 |
|---|---|
| 이름으로 모델 저장소 신뢰 | 결합된 어댑터 및 베이스 대상을 포함한 코드의 지문(fingerprint)에 승인을 연동 |
| 원격 코드 동의를 유일한 모델 로딩 검사로 취급 | 선택된 로딩 경로에서 표시된 직렬화 파일에 대한 별도의 게이트 추가 |
| 샌드박스 바이너리를 탐지하고 격리 상태로 간주 | 호스트에서 격리 상태를 점검하고 유효 보호 수준을 기록 |
| 취약점 권고문에만 의존 | 발견 항목별 기준선과 7일 npm 릴리스 경과 기준을 적용한 패키지 콘텐츠 스캔 강제 |
| 로컬 AI를 1명의 암묵적 신뢰 사용자로 실행 | 암호화된 키를 갖춘 비밀번호 보호, 스로틀링 적용 다중 사용자 계정 |

보안을 넘어, NPU 경험 개선
Unsloth 창업자들이 공유한 피드백은 초당 토큰 수를 포함해 NPU에 대한 더 풍부한 성능 지표를 요구합니다. 또한 이 앱은 GPU 모델에서 이미 가능한 것처럼 실행 전에 모델 로딩 설정을 구성할 수 있는 기능을 요청합니다. 이들은 로컬에서 모델을 실행할 때 더 나은 가시성과 제어를 위한 요청된 개선 사항이지 확인된 릴리스가 아닙니다.
Unsloth의 개요와 저장소에 대한 정적 소스 검토를 바탕으로, 우리가 다룬 커밋 285d157a은(는) 다음과 같습니다. 릴리스 가용성은 이 기사를 위해 제공된 정보를 기반으로 합니다. 승인 모드, macOS 및 Windows 샌드박스, 자격 증명 암호화, npm 릴리스 경과 규칙 및 데스크톱 검사는 개요에서 나옵니다. 지문 바인딩 승인, 샌드박스 점검, 실행 기록 및 로그인 임계값은 저장소에서 나옵니다. 여러 보호 기능은 Unsloth Studio와 Desktop에 속하며, 의존성 스캔과 감사 제한은 개발 워크플로우에 속합니다. 이들은 독립형 라이브러리를 임포트하는 노트북을 자동으로 보호하지 않습니다.
핵심 요약
- Unsloth Studio는 원격 코드 승인을 스캔된 코드의 지문에 연계합니다. 변경된 코드는 새로운 동의가 필요합니다.
- Hugging Face 악성 판정은 trust_remote_code와 무관하게 로딩 경로에서 플래그된 가중치 파일을 차단합니다.
- 도구는 OS 샌드박스(bubblewrap, Seatbelt, MXC)에서 실행될 수 있습니다. Linux에서는 저장소에 따르면 Studio가 먼저 격리 상태를 점검합니다.
- 패키지 내용 스캔에서 새로 발견된 높은 심각도 또는 심각한 심각도의 취약점이 있으면 CI가 실패하며, npm은 7일 미만의 패키지를 거부합니다.
- Studio는 기본적으로 비밀번호로 보호되는 다중 사용자 시스템으로, 로그인 속도 제한과 암호화된 API 키를 제공합니다.
출처
- https://unsloth.ai/blog/security
- https://github.com/unslothai/unsloth/tree/285d157a412fb30c11d223f85df84357d946a00a
- https://www.hiddenlayer.com/insight/malware-found-in-trending-hugging-face-repository-open-oss-privacy-filter — Hugging Face 인기 저장소에서 멀웨어 발견: Open OSS 프라이버시 필터에 관한 HiddenLayer의 분석 자료
- https://www.theregister.com/2026/03/24/trivy_compromise_litellm/
- https://docs.litellm.ai/blog/security-townhall-updates
- https://jfrog.com/press-room/jfrog-report-warns-ai-governance-fails-as-software-supply-chain-attacks-hit-record-highs/ — JFrog 보고서: 소프트웨어 공급망 공격이 사상 최고치를 기록하면서 AI 거버넌스의 실패를 경고하는 보도자료
- https://huggingface.co/docs/hub/security-malware
참고:이 기사에 대한 통찰력 있는 리소스를 제공해 주신 Unsloth 팀에 감사드립니다. 이 기사는 Unsloth의 지원을 받았습니다.
본 게시물 신뢰하는 모델 저장소가 변경되면 어떻게 될까? Unsloth Studio가 실행 전에 재검사합니다 는 최초 MarkTechPost에 게재되었습니다.
