허깅페이스 보안 사고, AI 시대 소프트웨어 공급망 리스크와 필수 역량

 

허깅페이스 보안 사고, AI 시대 소프트웨어 공급망 리스크와 필수 역량

 

안녕하세요,

그로메트릭 입니다. 🐸

 

최근 허깅페이스(Hugging Face)가 자사 프로덕션 인프라 일부가 자율 AI 에이전트 기반 공격에 의해 침해당했다고 공개했습니다. 악성 데이터셋이 데이터 처리 파이프라인의 코드 실행 경로 두 곳을 악용해 처리 워커에서 코드를 실행시켰고, 공격자는 이후 노드 단위 접근 권한으로 확대해 자격 증명을 확보한 뒤 내부 클러스터 곳곳으로 이동했습니다.

 

이는 단순한 "AI 공격" 사례가 아닙니다. 데이터 처리 워크플로우, 인프라, 자격 증명, 클라우드 시스템, 자율 에이전트를 모두 관통하는 소프트웨어 공급망 공격 사례입니다. 모델, 데이터셋, 에이전트 같은 AI 아티팩트가 소프트웨어 개발의 핵심 구성요소로 자리잡으면서, 신뢰와 실행 관계가 눈에 보이지 않거나 통제되지 않을 때 공격이 하나의 아티팩트에서 시작해 더 중요한 시스템으로 빠르게 확산될 수 있다는 점을 이번 사고가 보여줍니다.

 

이번 글에서는 이 사고의 경위와, AI 시대 소프트웨어 공급망 보안에서 조직이 갖춰야 할 역량을 살펴보겠습니다.

*아래 글은 소나타입(Sonatype)의 공식 블로그 글을 참고하여 재구성 했습니다.

---

허깅페이스 보안 사고 경위: 무슨 일이 있었나? 📰

허깅페이스는 프로덕션 인프라의 일부가 자율 AI 에이전트 시스템에 의해 침해됐다고 밝혔습니다. 공격의 출발점은 악성 데이터셋이었습니다. 이 데이터셋이 회사의 데이터 처리 파이프라인 안에 있던 두 개의 코드 실행 경로를 악용해 처리 워커에서 코드가 실행되도록 만들었습니다. 이후 공격자는 노드 단위 접근 권한으로 확대했고, 자격 증명을 확보해 내부 클러스터 곳곳으로 이동했습니다.

 

허깅페이스는 제한된 범위의 내부 데이터셋과 서비스 자격 증명에 대한 무단 접근이 있었다고 확인했지만, 공개된 모델·데이터셋·스페이스·컨테이너 이미지·패키지가 변조됐다는 증거는 찾지 못했다고 밝혔습니다. 이후 AI 기반 분석 기법을 활용해 1만 7,000건 이상의 공격자 행위를 며칠이 아닌 몇 시간 만에 재구성했습니다.

 

이 사고를 단순한 "AI 공격" 사례로 보기는 어렵습니다. 데이터 처리 워크플로우, 인프라, 자격 증명, 클라우드 시스템, 자율 에이전트가 모두 연결된 소프트웨어 공급망 공격 경로였다는 점이 핵심입니다. 모델·데이터셋·라이브러리·에이전트·도구, 그리고 그 에이전트가 접근할 수 있는 시스템들이 새로운 신뢰·실행 관계를 만들어내고 있으며, 이 관계가 가시화되거나 통제되지 않을 경우 공격이 하나의 아티팩트에서 시작해 더 중요한 시스템으로 빠르게 옮겨갈 수 있습니다.

 

AI 보안 위협, 왜 예방보다 빠른 탐지가 중요할까? 🚨

모든 AI 관련 신규 취약점, 악성 아티팩트, 공격 경로를 사전에 막아내는 것은 현실적으로 불가능합니다. 더 시급한 과제는 특정 위협이 조직에 실제로 영향을 미치는지, 그리고 그 영향이 확산되기 전에 이를 파악할 수 있는지입니다.

소프트웨어 공급망이 확장될수록 이 과제는 더 어려워지고 있습니다. 2025년 한 해 신규 오픈소스 악성 패키지가 45만 4,600건 이상 발견됐고, npm·PyPI·Maven Central·NuGet·허깅페이스를 합쳐 알려진 악성 패키지 누적 건수는 123만 건을 넘어섰습니다.

AI는 소프트웨어 조립 속도와 보안 의사결정량을 동시에 늘려 이 문제를 키우고 있습니다. 2022년 6월부터 2026년 6월 사이 신규로 영향을 받는 컴포넌트 버전 수는 AI 도입 이전 대비 46배 증가했고, 같은 기간 엔터프라이즈 애플리케이션의 월평균 생성량은 4.84배 늘었습니다. 대형 보안 사고가 발생했을 때 조직에 필요한 것은 단순한 알림이 아니라, 무슨 일이 있었는지, 어떤 기술이 관련돼 있는지, 그리고 그 위협이 자사 환경과 교차하는지에 대한 시의성 있는 맥락 정보입니다

 

AI 시대 소프트웨어 공급망 보안, 조직이 갖춰야 할 4가지 역량

이번 사고는 AI가 기업 소프트웨어 환경과 더 깊이 연결될수록 중요해지는 네 가지 역량을 다시 확인시켜줍니다.

1) 선제적 의존성 인텔리전스: AI 코딩 도구에 최신 리스크 정보 제공하기 ℹ️

AI 코딩 어시스턴트는 스스로 최신 컴포넌트·버전·리스크 정보를 갖고 있지 않습니다. 당장의 개발 요구를 해결해 주는 의존성 선택이 동시에 취약점, 악성코드, 라이선스 문제, 향후 유지보수 부담을 끌어들일 수 있습니다. 선택 시점에 최신 정보를 반영해 의사결정을 내리도록 하면, 더 나은 컴포넌트 선택이 가능해지고 이후의 리메디에이션 부담도 줄어듭니다.

소나타입 가이드(Sonatype Guide)는 이러한 최신 컴포넌트·버전·리스크 맥락을 개발자와 AI 기반 워크플로우에 직접 제공해, 코딩 어시스턴트가 스스로는 갖지 못한 정보를 바탕으로 더 안전한 의존성 결정을 내리도록 돕습니다.

2) 실시간 인지: AI 공급망 위협의 노출 지점 파악하기 ✅

인지는 단순히 "이런 보안 공지가 있었다"는 사실을 아는 것이 아닙니다. 그 위협이 어떻게 작동하는지, 자사 환경 어디가 노출될 수 있는지를 이해하는 것입니다. AI 아티팩트가 어디에서 처리되는지, 로드될 때 어떤 코드가 실행될 수 있는지, 그 환경에서 어떤 자격 증명에 접근할 수 있는지, 자동화된 에이전트가 내부 시스템이나 도구에 접근할 수 있는지를 함께 살펴봐야 합니다. AI를 활용하는 공격자는 개별적으로는 낮은 심각도로 분류될 수 있는 취약점, 자격 증명 노출, 설정 오류를 서로 엮어 실질적인 공격 경로로 만들어낼 수 있습니다.

소나타입 가이드의 시큐리티 이벤트(Security Events) 기능은 주요 보안 사안이 발생했을 때 관련 맥락을 제공해, 팀이 조사와 대응의 우선순위를 빠르게 정할 수 있도록 지원합니다.

3) 가시성과 거버넌스: AI 아티팩트 전반을 통제하기 🚧

AI 소프트웨어 공급망은 코드 의존성 목록보다 훨씬 넓습니다. AI 기반 애플리케이션은 모델, 데이터셋, 프레임워크, 컨테이너, API, 도구, 에이전트, 오픈소스 컴포넌트에 의존합니다. 조직은 자신이 어떤 AI 아티팩트를 어디에서 사용하고 있는지, 그 아티팩트가 무엇에 접근할 수 있는지, 정해진 보안·정책 요건을 충족하는지 파악해야 합니다.

 

특히 팀이 공개된 소스에서 모델이나 관련 아티팩트를 직접 내려받는 경우가 문제입니다. 통제되지 않은 "섀도 다운로드"는 자산 인벤토리에 잡히지 않고, 보안 스캔이나 정책 적용을 건너뛰며, 신뢰할 수 있는 출처 정보를 갖추지 못한 채 리스크를 키울 수 있습니다. 오픈소스 AI는 혁신 속도를 높여주지만, 다른 소프트웨어 공급망 구성요소와 동일한 수준의 관리 원칙 아래에 있어야 합니다. 전통적인 컴포넌트와 AI 아티팩트(허깅페이스 모델 포함) 전반에 일관된 통제를 적용하고, 새로운 리스크가 발생했을 때 조사를 뒷받침할 수 있는 SBOM·AI-BOM 수준의 기록을 유지하는 것이 필요합니다. 소나타입은 오픈소스 컴포넌트, 컨테이너, 허깅페이스 모델을 포함한 AI 아티팩트 전반에 이러한 가시성과 거버넌스를 적용할 수 있도록 지원합니다.

4) 신속한 대응: 발견된 리스크를 검증된 조치로 전환하기 🛠️

가시성과 인텔리전스는 실제로 조치를 취할 수 있을 때만 의미가 있습니다. 영향을 받는 의존성을 식별한 뒤에도 조직은 적절한 버전을 선택하고, 호환성을 확인하고, 변경을 적용·검증하고, 리뷰와 배포 절차를 거쳐야 합니다. 이 과정은 보안 이벤트가 빠르게 전개되는 상황에서 병목이 되기 쉽습니다.

 

조직들의 대응 속도는 개선되고 있습니다. 해결된 위반 사항 중 절반 이상이 하루 안에 처리됐다는 조사 결과도 있습니다. 그럼에도 애플리케이션당 크리티컬·하이 등급 취약점 수는 4년간의 조사 기간 동안 4.31배 늘었습니다. 사고 이후의 정리 속도를 높이는 것도 중요하지만, 애초에 더 나은 컴포넌트를 선택해 리메디에이션 작업 자체를 줄이는 것이 근본적인 대응입니다.

 

소나타입의 의존성 관리 에이전트인 Agent P는 의존성을 교체해야 하는 시점에 더 안전한 업그레이드 경로를 찾아내고, 업데이트를 적용하고, 그 결과를 검증하는 역할을 합니다. 개발자가 풀 리퀘스트를 검토하기 전에 호환성이나 브레이킹 체인지 문제까지 미리 짚어줄 수 있어, 의존성 리메디에이션을 지연시키는 수작업 부담을 줄여줍니다. 다만 이는 사고 대응이나 침해 격리, 복잡한 변경에 필요한 엔지니어링 판단을 대체하지는 않으며, 알려진 의존성 리스크를 AI 가속 개발 속도에 맞춰 검증된 조치로 빠르게 전환하는 데 초점을 둡니다.

 

결론: AI 공급망 리스크에 대응하는 현실적인 방법

허깅페이스 사고가 모든 조직이 동일한 공격 경로에 노출돼 있다는 뜻은 아닙니다. 다만 AI 기반 공격이 더 이상 이론적인 위협이 아니며, 소프트웨어 공급망이 패키지와 라이브러리 범위를 넘어 확장되고 있다는 점을 보여줍니다.

조직이 모델, 데이터셋, 에이전트, AI 기반 개발 워크플로우를 도입할수록 외부 아티팩트와 내부 시스템 사이에 새로운 연결이 생겨납니다. 이 연결은 혁신 속도를 높여주지만, 개별 취약점 점수나 주기적인 검토만으로는 파악하기 어려운 공격 경로를 만들어내기도 합니다.

 

현실적인 대응 방향은 AI 도입 속도를 늦추는 것이 아닙니다. 초기 단계부터 가시성을 확보하고, 최신 정보를 활용하고, 엔지니어링 워크플로우에 들어오는 것을 거버넌스 하에 두고, 상황이 바뀔 때 신속하게 대응하는 체계를 갖추는 것입니다. AI는 소프트웨어가 조립되고 업데이트되고 공격받는 속도를 높이고 있습니다. 보안 체계도 그 속도에 맞춰야 합니다

 

---

출처

소나타입 블로그 : Hugging Face Security Incident: A New Class of Threat Is Here