trust_remote_code는 항상 보호 장치가 아닌 모험이었다
요약
Hugging Face의 `trust_remote_code` 플래그가 모델 로딩 과정에서의 보안 취약점을 완전히 해결하지 못함을 경고합니다. 모델 저장소를 소프트웨어 공급망의 일부로 간주하고, 모델 출처 관리와 샌드박싱 등 엄격한 보안 프로토콜 도입이 필요함을 강조합니다.
핵심 포인트
- `trust_remote_code=False` 설정만으로는 모델을 통한 악성 코드 실행을 완전히 막을 수 없음
- 모델 저장소를 단순 데이터 저장소가 아닌 소프트웨어 공급망(Supply Chain)으로 취급해야 함
- 민감한 정보가 있는 환경에서 검증되지 않은 커뮤니티 모델을 직접 로드하는 것을 지양해야 함
- 모델 출처 증명(Provenance) 및 샌드박싱 등 보안 도구 생태계 구축이 시급함
trust_remote_code라는 이름의 안전 플래그가 정작 그것이 방어하려 했던 대상에 의해 우회되었습니다. 이 문장을 듣고도 긴장되지 않는다면, 여러분의 팀이 점심 식사 전에 얼마나 많은 pip install과 from_pretrained() 호출을 실행하는지 충분히 깊게 고민해보지 않은 것입니다.
Context (문맥)
이것은 새로운 영역이 아닙니다. 더 세련된 UI를 입은 오래된 문제입니다. 패키지 레지스트리(Package registries)는 npm과 PyPI가 공급망 공격(supply chain attacks)의 대명사가 된 이후로 의존성을 통한 악성 코드 문제를 계속 싸워왔습니다. 여기서 다른 점은 프레임워크(framing)입니다. Hugging Face 모델 저장소는 데이터처럼 보입니다. .safetensors 파일 하나, 설정(config), 그리고 몇몇 가중치(weights)들 말이죠. 개발자들은
과소평가된 사실은 ML 커뮤니티가 모델 허브(model hubs)를 중심으로 얼마나 많은 암묵적 신뢰를 쌓아왔는가 하는 점입니다. 아무도 4GB 크기의 체크포인트(checkpoint) 파일을 한 줄씩 감사(audit)하지 않습니다. 아무도 가중치(weights)를 디프(diff)하지 않습니다. 전체 워크플로우는 "허브를 검색하고, 벤치마크가 좋은 모델을 찾아, 그것을 로드한다"로 이루어져 있습니다. 이 워크플로우에는 아직 일상적인 습관으로 자리 잡은 npm audit과 같은 기능이 거의 없습니다. 모델 저장소에서 악성 코드를 스캔하기 위한 툴링 생태계는 전통적인 의존성(dependencies)을 위한 SCA(Software Composition Analysis) 툴링만큼 성숙하지 않으며, 특정 CVE 개수보다 이 격차 자체가 진짜 핵심적인 이야기입니다.
"AI는 독보적으로 위험하다"라는 프레임으로부터 누가 이득을 얻을까요? 솔직히 말해서, 무언가를 판매하는 모든 이들입니다. 벤더(Vendors)는 새로운 시장을 얻고, 연구자들은 언론 보도를 얻으며, 허브들은 패치를 적용할 때 선제적으로 대응하는 것처럼 보일 수 있습니다. 이 이야기에 대한 HN(Hacker News)의 참여도가 전혀 없다는 점 또한 시사하는 바가 있습니다. 즉, 이 이슈가 소음 속을 뚫고 나오지 못했다는 것인데, 이는 근본적인 버그가 정당하게 심각할 때조차 사람들이 "AI 보안 결함"이라는 헤드라인에 얼마나 무뎌졌는지를 보여주는 데이터 포인트입니다.
시사점 (Implications)
만약 여러분이 프로덕션 환경이나 심지어 샌드박스(sandboxed) 연구 환경에서 Hugging Face로부터 모델을 가져오고 있다면, trust_remote_code=False는 결코 종교적인 보증이 아니라 하나의 과속 방지턱에 불과했습니다. 모델 로딩을 처리할 때, GitHub 스타가 3개뿐인 관리자가 배포한 낯선 npm 패키지를 설치할 때 적용하는 것과 동일한 편집증적 주의를 기울이십시오. 이는 샌드박싱(sandboxing)을 의미하며, 자격 증명(credentials)이나 민감한 정보에 대한 네트워크 액세스 권한이 있는 머신에 임의의 커뮤니티 모델을 직접 로드하지 않는 것을 의미하며, 또한 여러분 팀의 누군가가 의존성 출처(dependency provenance)를 관리하듯 모델 출처(model provenance)를 실제로 책임져야 함을 의미합니다.
업계 입장에서는 이를 모델 허브를 소프트웨어 공급망 (software supply chains)으로 취급해야 한다는 강력한 권고로 받아들여야 합니다. 서명 (Signing), 출처 증명 (provenance attestation), 재현 가능한 빌드 (reproducible builds) 등, 수많은 사고를 겪은 후 소프트웨어 세계가 20년에 걸쳐 마지못해 구축해 온 도구 상체 전체가 필요합니다. AI 툴링은 이 타임라인을 압축하려고 시도하고 있으며 이는 긍정적이지만, 이러한 압축은 실무자들이 "그저 가중치 (weights)일 뿐이다"라는 가정이 안전 속성 (safety property)이라는 착각을 멈출 때에만 유효합니다.
미결 과제 (Open question)
신뢰 플래그 (trust flag)가 어떻게 설정되어 있든 모델을 로드하는 것이 코드를 실행할 수 있다면, 어느 시점에 "다운로드 후 실행"이 대부분의 합리적인 엔지니어링 조직이 수년 전 curl | bash를 버렸던 것처럼 머신러닝 (ML) 생태계가 완전히 폐기해야 할 안티 패턴 (anti-pattern)이 될까요?
— Cor, Skyblue Soft
출처 (Sources)
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기