Vercel 침해 사고 분석 — Context.ai 공급망 공격으로 본 SaaS 보안 점검 5가지

2026년 4월 19일 Vercel 보안 사고가 한국 개발자에게도 영향을 주는 이유를 정리합니다. 공격은 Vercel을 직접 뚫은 게 아니라 third-party 도구 Context.ai를 거쳐 들어왔습니다.

Frontend·DevOps 운영 관점에서 보면 이 사건은 SaaS 신뢰 경계가 무너지는 분기점입니다. 이 글을 끝까지 읽으면 사고 타임라인·공격 체인·점검 5가지·유사 사례 비교까지 가져갑니다.

이번 Vercel 침해 사고는 단순한 자격증명 유출 사건이 아닙니다. SaaS 공급망(supply chain) 자체를 신뢰 경계로 둔 운영 모델이 어떻게 무너지는지 보여주는 사례입니다. Vercel은 자사 인프라를 직접 공격당한 게 아닙니다. 직원이 사용하던 third-party 도구 Context.ai의 Google Workspace OAuth 통합이 권한을 그대로 들고 있었고, Context.ai 측 직원 PC가 Lumma Stealer에 감염되면서 그 토큰이 새 나갔습니다. 결과는 평문 환경변수 노출. 한국에서 Next.js · Vercel을 그대로 쓰는 팀이라면 이번 글이 남의 일이 아닙니다.

사고 타임라인 — 두 달간의 dwell time

가장 충격적인 건 시간 간격입니다. 첫 감염부터 공식 발표까지 약 두 달이 비어있습니다. 그 사이 공격자는 OAuth 토큰을 들고 자유롭게 이동했습니다.

날짜	사건	출처
2026-02	Lumma Stealer 감염 (Roblox cheat 미끼 다운로드 경유)	CyberScoop
2026-03	Context.ai, AWS 환경 침해 인지	Vercel KB
2026-04-19	Vercel 공식 보안 권고 발표	Vercel KB
2026-04-23	Vercel, 2차 피해 추가 확인 (환경변수 일부 평문 노출 포함)	TechCrunch

두 달 dwell time이 가능했던 이유는 OAuth 토큰이 "사람"이 아니라 "앱"으로 인증되기 때문입니다. 평소 보안팀이 모니터링하는 사람 계정의 비정상 로그인 패턴(국가 변경, 디바이스 변경)에 잡히지 않습니다. 정상 트래픽 안에 섞여 들어옵니다.

공격 체인 — Roblox cheat에서 환경변수까지

이 사고를 이해하려면 끝에서 거꾸로 보는 게 빠릅니다. 최종 피해는 평문 환경변수, 출발점은 Roblox cheat을 받으려던 누군가의 PC였습니다.

[Roblox cheat 다운로드 (Lumma Stealer 미끼)]
        ↓ 브라우저 세션·쿠키 탈취
[Context.ai 직원 PC 감염]
        ↓ Google Workspace 자격증명 + OAuth 토큰 추출
[Context.ai 소속 Google Workspace OAuth 앱 장악]
        ↓ Vercel 직원 계정에 신뢰 권한 보유
[Vercel 직원 계정 접근]
        ↓ 환경변수 평문 조회
[고객 환경변수(Database URL · API Key 등) 탈취]

핵심은 굵게 표시된 OAuth App ID입니다. 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com — Google Workspace 관리자가 이 App ID를 즉시 차단해야 합니다. Trend Micro 분석에서 이 App ID가 핵심 pivot point로 지목됐습니다.

 

여기서 한 번 더 짚고 갈 부분이 있습니다. Vercel 환경변수에는 sensitive 플래그라는 장치가 있습니다. 켜두면 대시보드에서 값이 마스킹되고 일부 API에서도 노출이 차단됩니다. 이번 사건에서 평문으로 새어나간 변수들은 sensitive 플래그가 켜지지 않은 상태였습니다. 즉, 기능이 없었던 게 아니라 운영 관행이 안 바뀌었던 것입니다.

Next.js · Vercel 운영자가 지금 점검할 5가지

Vercel 공식 권고를 한국 환경에 맞게 보강했습니다. 아래 5가지는 이번 주 안에 끝내는 게 합리적입니다.

 

1. 환경변수 sensitive 마킹
Production 환경의 모든 비밀값(DATABASE_URL, API_KEY, JWT_SECRET 등)에 sensitive 플래그를 켭니다. Vercel 대시보드 → Settings → Environment Variables에서 변수별로 토글합니다. 새 변수 등록 시 기본 sensitive로 들어가도록 팀 정책을 세팅하는 게 더 안전합니다.

 

2. API 키·토큰 회전 (Vercel 단독 X, 연결된 SaaS 전부)
Vercel만 키 회전하고 끝내면 의미가 없습니다. 환경변수에 들어 있던 자격증명이 어디로 가는지 추적해서 그 SaaS 측에서도 키 회전해야 합니다. 한국 스타트업이 흔히 쓰는 조합 기준으로:

• Supabase / Neon / PlanetScale → DB 자격증명 회전
• Datadog / Sentry → API 키 회전
• AuthKit / Clerk / Supabase Auth → JWT 시크릿 회전
• Stripe / Toss / PortOne → API 키 회전

3. 2FA · passkey 강제 적용
Vercel 팀 멤버 전원에게 2FA 또는 passkey를 강제합니다. 관리자 계정만 켜두면 의미 없습니다. 협업하는 외주·인턴 계정도 동일.

 

4. Activity log 검토 (지난 2개월 구간)
2026-02부터 4월 23일까지 Vercel Activity log를 살핍니다. 비정상 IP의 환경변수 조회, 평소 안 쓰던 시간대의 deploy, 모르는 OAuth 앱 인증 이벤트가 핵심입니다. Varonis 액션 가이드에 구체 쿼리 패턴이 정리돼 있습니다.

 

5. Google Workspace OAuth 앱 감사
Workspace 관리자 콘솔 → Security → API controls → App access control. 위에 박은 App ID(110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com)는 즉시 차단합니다. 그다음 production 환경변수 접근 권한을 가진 OAuth 앱 전부를 다시 들여다보고, "이게 왜 이 권한을 갖고 있지?" 질문에 답이 안 나오는 앱은 권한 회수합니다.

여기까지가 Vercel 측 권고와 직접 매칭되는 액션입니다. 우리 시스템이 자동 적용해 주는 도입부 4줄 공식이나 시리즈 인링크 같은 콘텐츠 자동화는 SEO 영역인 반면, 위 5가지는 운영 보안 영역입니다. 둘은 분리된 워크플로우라 같은 주에 같이 끝낼 수 있습니다.

유사 사례 비교 — They didn't break in. They logged in.

이번 Vercel 사고가 충격적인 건 사실이지만, 패턴 자체는 새롭지 않습니다. 최근 1~2년 사이 SaaS-to-SaaS 신뢰 경계를 노린 같은 구조의 공격이 반복되고 있습니다.

사건	시점	공격 벡터	공통 패턴
Snowflake 데이터 유출	2024	자격증명 탈취 → 미사용 SaaS 계정	비인간 신원·MFA 부재
Salesloft Drift–Salesforce (UNC6395)	2025-08	OAuth 토큰 탈취 → 700+ 조직	SaaS-to-SaaS 신뢰 경계
Gainsight–Salesforce	2025-11	OAuth 통합 → Salesforce 700+ 조직	OAuth 가시성 부재
Vercel	2026-04	OAuth + 평문 환경변수	Non-Human Identity 미감시

Obsidian Security 비교 분석이 이 패턴을 한 문장으로 정리합니다.

"They didn't break in. They logged in."
그들은 침입한 게 아니라 그냥 로그인했다.

방화벽·WAF·EDR이 잡지 못합니다. 정상 OAuth 토큰을 들고 정상 API로 들어오기 때문입니다. 보안 모델 자체가 "사람 계정 보호"에서 "비인간 신원(Non-Human Identity, NHI) 가시성"으로 옮겨가야 한다는 신호가 4건 연속으로 들어왔습니다.

그래서 뭘 바꿔야 하나 — Zero Trust + 환경변수 sensitive 분리

근본 해법은 Zero Trust 모델 + Non-Human Identity 가시성 도구입니다. 현실적으로 한국 스타트업이 6개월 내 도입하기는 비용·러닝커브 부담이 큽니다. 단기로는 4가지에 집중합니다.

1. 환경변수 sensitive 분리 — 새 변수 등록 시 sensitive 기본값
2. OAuth 앱 분기 감사 — 관리자 권한 OAuth 앱부터 우선
3. MFA 강제 + 키 회전 정책 — 분기마다 자동 회전 스크립트
4. Activity log 7일 이상 보관 — 침해 인지 지연 대비

정답은 없습니다. 팀 단위로 Vercel · Supabase · Datadog 동시에 쓰는 한국 스타트업이라면 이번 주에 환경변수 감사 한 번은 돌리길 권합니다. 사고가 없는 주에 점검을 끝내야 사고가 났을 때 대응이 빠릅니다.

자주 묻는 질문

Q. Vercel을 쓰던 한국 개발자도 영향을 받나요?
A. 영향 받을 가능성 있습니다. 환경변수에 평문 자격증명을 넣었거나 sensitive 마킹을 안 했다면 노출됐을 수 있습니다. 즉시 키 회전과 activity log 검토를 권합니다. Vercel 공식 권고도 "모든 고객은 키 회전을 검토하라"는 톤으로 나왔습니다.

Q. Context.ai는 정확히 무엇이고 왜 영향이 컸나요?
A. Vercel 직원들이 사용하던 third-party 도구입니다. 공격자가 Vercel을 직접 뚫은 게 아니라 Context.ai의 Google Workspace OAuth 앱이 Vercel 계정에 신뢰된 권한을 갖고 있었기 때문에, Context.ai 한 곳이 뚫리자 권한이 그대로 Vercel 환경변수까지 도달했습니다.

Q. sensitive 환경변수 마킹은 무엇이고 왜 중요한가요?
A. Vercel 환경변수에 sensitive 플래그를 켜면 대시보드에서 값이 표시되지 않고 일부 API 응답에서도 마스킹됩니다. 이번 사건에서 평문으로 노출된 변수들은 sensitive 마킹이 안 된 것이었습니다. 기능 자체는 원래 있었으나 운영 관행이 따라가지 못한 케이스입니다.

Q. 우리 팀이 OAuth 앱을 다 검토하기 어렵습니다. 우선순위는?
A. 1) Production 환경변수 접근 권한이 있는 OAuth 앱 → 2) Google Workspace 관리자 권한 OAuth 앱 → 3) 외부 SaaS 자동화 통합 순서로 좁혀가세요. 본문에 박은 App ID(110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com)는 무조건 즉시 차단입니다.

Q. 이런 SaaS-to-SaaS 공격을 근본적으로 막으려면?
A. 장기적으로 Zero Trust 모델 + Non-Human Identity 가시성 도구 도입이 필요합니다. 단기로는 환경변수 sensitive 분리, OAuth 앱 분기 감사, MFA 강제 + 키 회전 정책, Activity log 7일 이상 보관 4가지를 즉시 적용하는 게 비용 대비 효과가 좋습니다.

블로그 다른 글도 한번 둘러봐 주세요. AI 활용법과 실무 트러블슈팅 위주로 꾸준히 정리하고 있습니다.