Vercel 침해가 드러낸 OAuth 기반 SaaS 공급망 공격의 신뢰 체인

2026년 4월 19일 Vercel은 서드파티 AI 도구 Context AI를 경유한 공급망 공격으로 내부 시스템이 침해됐다고 밝혔다. 한 직원의 OAuth 권한 허용이 고객 프로젝트 환경변수 노출로 이어진 사건이다. 이 사례는 SaaS 공급망에서 코드 자체보다 인증 위임과 신뢰 관계가 공격 표면이 될 수 있음을 보여준다.

Context AI에서 Vercel까지 이어진 침해 경로

공격 체인은 2026년 2월부터 시작됐다. Context AI 직원이 Roblox “auto-farm” 스크립트를 내려받는 과정에서 Lumma Stealer에 감염됐고, 이후 Context AI의 Google Workspace OAuth 토큰이 탈취됐다.

공격자는 이 토큰으로 Context AI 레거시 제품 사용자의 Google Drive 데이터에 접근했다. Vercel 직원이 엔터프라이즈 계정으로 Context AI에 “Allow All” 권한을 부여한 상태였고, 이 신뢰 관계가 Vercel 내부 시스템 진입 경로가 됐다.

최종적으로 고객 프로젝트의 환경변수가 노출됐다. 위협 행위자는 BreachForums에 탈취한 Vercel 데이터베이스를 $2M에 판매 게시했으며, Vercel은 npm 패키지 공급망은 침해되지 않았다고 확인했다.

⤢✕

직접 목표를 겨냥하지 않고, 이미 신뢰된 서드파티를 경유하는 것이 이 공격의 특징이다.

초기 접근에는 Lumma Stealer가 쓰였다. Context AI 직원은 게임 핵 도구인 Roblox auto-farm executor를 내려받는 과정에서 감염됐으며, Lumma Stealer는 브라우저에 저장된 쿠키, 세션 토큰, OAuth refresh token을 추출하는 인포스틸러다. 게임 핵 커뮤니티는 Lumma, Redline 같은 인포스틸러의 대표적 유포 경로로 알려져 있다.

탈취된 OAuth refresh token은 만료되기 전까지 재사용될 수 있다. 공격자는 이를 통해 Google Workspace API로 Context AI 사용자 데이터에 접근했다. Refresh token은 새 access token을 발급받는 데 사용되므로, 취소되지 않으면 장기적인 접근이 가능하다.

결정적인 지점은 권한 연쇄 침해였다. Context AI에 부여된 “Allow All” 스코프는 Google Drive 전체 읽기 권한을 허용했고, 그 결과 Vercel 내부 자격증명과 환경변수로 이어졌다. 기업 계정의 서드파티 앱 연결이 IT 정책 검토 없이 이뤄진 것이 직접적인 원인이 됐다.

토큰 탈취가 권한 연쇄로 확장되는 방식

OAuth 2.0은 사용자가 서드파티 애플리케이션에 제한된 권한을 위임하는 인증 프로토콜이다. 하지만 스코프 관리가 느슨하면 토큰 하나의 탈취가 광범위한 권한 침해로 번질 수 있다.

Access Token: 단기 유효(보통 1시간)하며 API 호출에 직접 사용된다. 탈취 시 단기 위협이 된다.
Refresh Token: 장기 유효(수개월~무기한)하고 Access Token 갱신에 사용된다. 탈취되면 장기 지속적 접근이 가능하다.

토큰이 탈취되는 경로도 여러 가지다.

인포스틸러(Lumma, Redline, Vidar 등)가 브라우저 저장소에서 토큰을 직접 추출할 수 있다.
피싱 페이지는 가짜 로그인 화면을 통해 OAuth authorization code interception을 유도한다.
오픈 리다이렉트는 redirect_uri 조작으로 인증 코드를 탈취하는 데 악용될 수 있다.
PKCE가 적용되지 않으면 authorization code 재사용 공격을 허용할 수 있다.

이 사건의 권한 경로는 Context AI 서드파티 앱, Vercel 직원 Google 계정, Vercel 내부 자격증명, 고객 환경변수 순으로 이어졌다. 각 단계는 앞선 단계의 신뢰 관계를 발판으로 횡적 이동한다. 기업 안에서 SaaS 앱 연결이 늘수록 이 관계는 기하급수적으로 복잡해진다.

SaaS 연결이 만드는 공격 표면

SaaS 공급망 공격은 소프트웨어 공급망 공격과 달리 코드 대신 인증 위임과 신뢰 관계를 겨냥한다. 주요 취약점은 다음과 같다.

과도한 OAuth 스코프: 사용자가 편의를 위해 “Allow All” 권한을 허용하고, 기업 IT가 이를 통제하지 못할 수 있다.
OAuth 앱 거버넌스 부재: 직원의 개인 OAuth 앱 연결을 사전 검토하거나 추적하지 못한다.
서드파티 보안 검증 미흡: SaaS 공급업체의 보안 수준을 검증하지 않은 채 신뢰를 부여한다.
토큰 만료 정책 부재: 장기 유효 refresh token을 주기적으로 폐기하지 않는다.
Single Sign-On 과의존: 기업 SSO 계정 하나가 수백 개 서드파티 연결의 신뢰 루트가 된다.

Obsidian Security 분석에 따르면 기업 평균 SaaS 앱 연결 수는 수백 개에 달하며, 각 연결은 잠재적인 공격 표면을 만든다. GitHub Copilot, Slack, Notion 등 일상 업무 도구를 경유한 OAuth 기반 공급망 공격도 증가 추세이며, Vercel 사건은 이를 보여주는 사례다.

OAuth 권한을 제로 트러스트 경계로 다루기

제로 트러스트는 “절대 신뢰하지 말고, 항상 검증하라(Never Trust, Always Verify)”는 원칙이다. SaaS 공급망 방어에서는 애플리케이션 연결과 OAuth 스코프를 신뢰 경계로 다뤄야 한다.

OAuth 최소 권한 원칙은 다음과 같이 적용할 수 있다.

앱에 필요한 최소 권한만 요청하고 허용한다.
drive.readonly 대신 drive.file처럼 세분화된 스코프를 사용해 특정 파일만 접근하도록 지정한다.
“Allow All” 클릭이 갖는 보안 위험을 사용자 교육에 포함한다.
기업 IdP에서 고위험 스코프를 자동 차단하고 관리자 승인을 필수화한다.

⤢✕

SSPM은 SaaS 설정 오류와 과도한 OAuth 권한을 자동으로 탐지한다. CASB는 SaaS 사용 가시성을 확보하고 정책을 일관되게 적용하는 역할을 맡는다. 여기에 기업 계정에 연결된 모든 서드파티 앱을 찾아 위험도를 분류하는 OAuth 앱 인벤토리, 토큰 유효성을 실시간으로 감시하고 이상 접근 시 자동 폐기하는 지속적 접근 검증이 필요하다.

사고 이후에 우선할 조치와 운영 설계

사고 직후에는 서드파티 OAuth 앱을 전수 조사하고 불필요한 연결을 취소해야 한다. Google Workspace Admin에서 앱과 서드파티 앱 접근을 확인하고, Refresh Token을 강제로 폐기한 뒤 재발급한다.

노출 가능성이 있는 API 키와 DB 자격증명은 환경변수와 함께 즉시 로테이션해야 한다. 고위험 스코프를 보유한 앱에는 관리자 승인 절차를 즉시 적용한다.

장기적으로는 서비스 계정 키 대신 임시 자격증명(short-lived tokens)을 쓰는 Workload Identity Federation을 도입할 수 있다. HashiCorp Vault나 AWS Secrets Manager로 환경변수를 중앙 관리하고 자동 로테이션을 적용하는 방법도 있다.

SaaS 공급업체에는 SOC 2 Type II와 ISO 27001 인증을 요구하고 정기적으로 검토해야 한다. SaaS 접근 로그를 SIEM에 통합하면 비정상 OAuth 접근 패턴을 실시간으로 탐지하고 자동 대응하는 체계를 구성할 수 있다.

Vercel 사건에서 드러난 문제는 단일 사용자의 권한 승인에만 있지 않다. 수천 명의 고객 환경변수 노출로 이어질 수 있는 SaaS 신뢰 체인을 어떻게 발견하고, 제한하고, 계속 검증할 것인가의 문제다.