Vercel 침해: OAuth 공격이 플랫폼 환경 변수의 숨은 위험 노출

7 hours ago 1

OAuth 공급망 침해가 Vercel 내부 시스템 접근으로 이어졌고, 제한된 일부 고객 프로젝트의 환경 변수 노출 발생
시작점은 Context.ai 직원의 Lumma Stealer 감염이었고, 유출된 Google Workspace OAuth 토큰이 Vercel 직원 계정과 내부 시스템 접근에 사용됨
공격자는 고객 프로젝트의 환경 변수를 열거할 권한을 얻었고, 특히 non-sensitive로 표시된 변수를 통해 하류 서비스 자격 증명 노출 가능성 확대
공개된 정황상 최소 한 건에서는 Vercel 공개 전 유출 API 키 탐지가 있었고, 탐지와 통지 사이의 시간 차가 주요 위험 요인으로 부각
이번 침해는 OAuth 신뢰 관계와 플랫폼 환경 변수 저장 방식이 함께 공급망 전반의 자격 증명 확산으로 이어질 수 있음을 드러낸 사건

핵심 함의

OAuth 증폭 효과 확인
- 하나의 OAuth 신뢰 관계 손상으로 벤더에서 Vercel 내부 시스템까지 연쇄 확장
- 손상된 벤더와 직접 관계가 없는 고객 프로젝트 환경 변수까지 제한적으로 노출
AI 가속형 공격 행위 가능성 제기
- CEO가 공격자의 이례적 속도를 AI 보강과 연결해 공개 발언
- 다만 이 평가는 공식 포렌식 결론이 아니라 공개 발언 수준
탐지에서 공개까지의 지연 부각
- 적어도 한 건의 공개 고객 보고에서 Vercel 공개 9일 전 유출 키 탐지 정황 존재
- 플랫폼 침해에서 탐지 후 통지 지연이 중요한 위험 요인으로 지목됨
2026년의 더 넓은 패턴과 연결
- LiteLLM, Axios, Codecov, CircleCI와 함께 개발자 저장 자격 증명을 겨냥하는 공급망 흐름과 맞물림

사고 타임라인

약 2026년 2월, Context.ai 직원이 Lumma Stealer에 감염되어 기업 자격 증명, 세션 토큰, OAuth 토큰 유출
약 2026년 3월, 공격자가 Context.ai의 AWS 환경에 접근해 소비자 사용자 대상 OAuth 토큰 탈취
- 여기에는 Vercel 직원의 Google Workspace 토큰 포함
2026년 3월, 탈취된 OAuth 토큰으로 Vercel 직원의 Google Workspace 계정 접근 발생
2026년 3월부터 4월, Vercel 내부 시스템으로 이동한 뒤 고객 환경 변수 열거 시작
약 2026년 4월, ShinyHunters 연계 행위자가 Vercel 데이터 판매를 시작했다는 주장 제기
2026년 4월 10일, 한 Vercel 고객이 OpenAI로부터 유출 API 키 알림 수신 사실 공개 언급
2026년 4월 19일, Vercel 보안 공지 게시 및 X 스레드 공개
2026년 4월 19일 이후, 고객 통지, 자격 증명 회전 안내, 대시보드 변경 배포 진행
약 2개월의 상대적으로 짧은 체류 기간에도 제3자 벤더 감염에서 고객 환경 변수 유출까지 이어진 속도 확인
Google Workspace OAuth 감사 로그 기본 보존 기간은 다수 요금제에서 6개월
- 이번 약 2개월 체류 기간은 보존 창 안에 남아 있을 가능성
- 더 장기적인 유사 침해는 기본 보존 기간을 초과할 수 있다는 점도 지적

공격 체인

1단계: 제3자 OAuth 침해
- Context.ai는 Vercel 직원이 승인한 Google Workspace OAuth 애플리케이션 보유
- 이 애플리케이션 손상은 2026년 2월경 Context.ai 직원의 Lumma Stealer 감염으로 추적됨
- Hudson Rock과 CyberScoop 보도에 따르면, 해당 직원은 Roblox 게임 익스플로잇 스크립트를 내려받은 뒤 감염된 것으로 보도됨
- 탈취된 자격 증명으로 공격자는 Context.ai의 AWS 환경에 접근했고, 2025년 6월 출시된 Context AI Office Suite 소비자 사용자용 OAuth 토큰 유출
- Context.ai는 2026년 3월 AWS 환경의 비인가 접근을 탐지하고 중단했다고 공지
- 다만 OAuth 토큰 유출 자체는 Vercel 조사 전까지 식별되지 않았다고 명시
- 승인된 OAuth 애플리케이션은 다음 특성 보유
  - 사용자 비밀번호 불필요
  - 비밀번호 변경 후에도 지속 가능
  - 이메일, 드라이브, 캘린더 등 넓은 권한 범위 빈번
  - 최초 승인 이후 드물게 감사 대상이 됨
2단계: Workspace 계정 탈취
- 손상된 OAuth 애플리케이션 접근으로 Vercel 직원의 Google Workspace 계정으로 이동
- 이를 통해 이메일 접근, Google Drive 내부 문서 접근, 캘린더 및 연결 자원 가시성, 다른 OAuth 연결 서비스 접근 가능성 확보
3단계: 내부 시스템 접근
- 손상된 Workspace 계정에서 Vercel 내부 시스템으로 추가 이동
- Rauch는 동료의 손상된 Vercel Google Workspace 계정에서 시작된 일련의 조작으로 에스컬레이션이 진행됐다고 언급
- 구체적 측면 이동 기법은 비공개
  - SSO 연동
  - 이메일 또는 Drive에서 수집된 자격 증명
  - 다른 OAuth 연결 내부 도구
  - 위 항목 중 어느 것인지 공개되지 않음
4단계: 환경 변수 열거
- 공격자는 고객 프로젝트 환경 변수를 열거할 수 있을 정도의 권한으로 Vercel 내부 시스템 접근
- Vercel은 고객 환경 변수를 저장할 때 “non-sensitive” 지정 기능 제공
- 공개 발언 기준으로, 고객 환경 변수는 모두 동일 방식으로 보호되지 않았고 민감 표시가 없는 변수 열거를 통해 추가 접근 획득
5단계: 하류 서비스 악용 가능성
- 노출된 환경 변수에는 보통 하류 서비스 자격 증명 포함
- Andrey Zagoruiko의 2026년 4월 19일 공개 보고에 따르면, 4월 10일 OpenAI의 유출 키 경고 수신
- 해당 키는 보고자 주장 기준 Vercel 외에는 존재하지 않았음
- 이 정황은 적어도 하나의 노출 자격 증명이 Vercel 공개 전 외부에서 탐지됐을 가능성 제기

공개 시점의 9일 공백

Guillermo Rauch의 4월 19일 X 스레드 답글에서 고객 Andrey Zagoruiko가 2026년 4월 10일 OpenAI 유출 키 알림 수신 사실 공개
OpenAI의 유출 자격 증명 탐지는 일반적으로 GitHub, paste 사이트 등 공개 위치에서 발견될 때 작동
Vercel 환경 변수에서 OpenAI 알림으로 이어지는 경로는 기사에서 단순하지 않다고 평가
날짜상으로는 가장 이른 공개 노출 증거와 Vercel 공개 사이에 9일 창 존재
이 9일 공백이 의미하는 것과 의미하지 않는 것
- 단일 공개 보고이며 포렌식 확정 결과 아님
- Vercel이 4월 10일에 이미 침해를 인지했다는 증거로 해석하면 안 됨
- 반면 최소 하나의 자격 증명이 고객의 비밀 교체 통지 이전에 외부에서 탐지됐다는 정황으로는 의미 존재
이해관계자별 시사점
- 규제기관
  - GDPR에서는 통제자가 침해 인지를 한 시점부터 72시간 통지 시계 시작
  - Vercel이 언제 인지했는지가 공개 쟁점으로 부상
- 감사인
  - SOC 2와 ISO 27001 평가자는 탐지-통지 지연을 지속 모니터링 증거로 검토 가능
- 고객
  - 노출 창이 4월 19일에 시작됐다고 가정할 수 없음
  - 그 이전부터 적극 악용됐을 수 있음으로 기사에서 제시
- 공급자 발송형 유출 자격 증명 알림은 조기 경보 채널로 중요도 상승
- OpenAI, Anthropic, GitHub, AWS, Stripe 등 예시 포함

AI 가속형 공격 행위

Guillermo Rauch는 2026년 4월 19일 X에서 공격 그룹이 고도로 정교하며 AI로 상당히 가속됐다고 강하게 의심한다고 발언
기사에서는 이 발언을 영향을 받은 플랫폼 CEO의 공개 기록상 평가로 다루며 신중한 검토 필요성 언급
포렌식 증거에서 기대될 수 있는 징후
- 수작업 속도를 넘는 열거 속도
  - 스크립팅만으로 일부 설명 가능
  - LLM 기반 정찰은 스키마 탐색, 엔드포인트 탐침, 자격 증명 형식 인식 병렬화 가능
- 맥락 인지형 질의 구성
  - 명백한 사전 정찰 없이도 Vercel 고유 용어, 프로젝트 slug, 배포 대상 이름, env var 명명 규칙을 아는 듯한 질의
- 오류 대응 적응성
  - API 오류와 rate limit 이후 전략 변경이 정적 스크립트보다 유연
- 현지화된 듯한 사회공학 산출물
  - 피싱 유도문, 커밋 메시지, 지원 티켓이 번역문이나 템플릿보다 로컬 맥락에 가까운 품질
Vercel 사건을 넘어서는 중요성
- 이 평가가 정식 포렌식에서 유지되는지와 무관하게, AI 보강형 공격 운영 범주는 더 이상 순수 추정만은 아님
- Microsoft 2026년 4월 발표에서 AI 기반 device-code phishing, 동적 코드 생성, 초개인화 유인, 백엔드 자동화 오케스트레이션 사례 문서화
- 인간 속도 기준으로 맞춘 텔레메트리 베이스라인은 AI 가속 운영자에 대해 false negative를 낼 수 있다는 지적
탐지 엔지니어링 함의
- 열거와 측면 이동 압축이 발생하면 기존 체류 시간 및 속도 임계치 기반 규칙이 과소 경보 가능
- 다음 항목의 재검토 필요성 제기
  - 세션당 고유 자원 열거 속도
  - 오류 대비 성공 회복 곡선
  - 짧은 시간 내 질의 패턴 다양성

환경 변수 설계상의 핵심 취약점

기사에서 가장 중대한 측면은 초기 접근 벡터 자체보다 Vercel의 환경 변수 민감도 모델
당시 Vercel 환경 변수 동작 방식
- 프로젝트는 서버리스 함수와 빌드 과정에 환경 변수 주입
- 변수별로 sensitive 플래그 존재
- 기본값은 non-sensitive
- sensitive는 명시적으로 활성화 필요
- non-sensitive 변수는 대시보드에 표시
- sensitive 변수는 생성 후 마스킹
- 내부 API를 통한 접근은 non-sensitive에서 가능, sensitive는 제한
- 암호화 저장은 공개 발언 기준 non-sensitive에 적용되지 않음, sensitive에는 추가 제한과 함께 적용
- 이번 침해에서 공격자 접근 가능 대상은 non-sensitive로 표시됨
결정적 설계 선택
- sensitive 플래그가 기본 비활성
- 개발자가 명시적으로 켜지 않은 모든 DATABASE_URL, API_KEY, STRIPE_SECRET_KEY, AWS_SECRET_ACCESS_KEY가 Vercel 내부 접근 모델에서 암호화되지 않은 형태로 저장
- 개별 비밀마다 명시적 opt-in을 요구하고 기본 보호와 가드레일이 없는 보안 제어는 실제 도입률이 낮다고 평가
Vercel 대응
- 환경 변수 개요 페이지와 민감 변수 생성·관리 UI 개선 배포 확인
- 가시성 측면 개선은 있었지만 작성 시점 기준 기본값 변경은 아님
- 여전히 변수별 opt-in 필요
- 기본값 전환 여부는 공개 질문으로 남아 있음
업계 비교
- 업계는 Vault, AWS Secrets Manager, Doppler, Infisical 같은 전용 비밀 저장소 쪽으로 이동
- Vercel의 환경 변수 기반 접근과 비교해 전용 비밀 관리 구조 선택을 이번 사건이 뒷받침한다고 평가
- 비교 표에 따르면
  - Vercel은 non-sensitive 기본값, 자동 감지 없음
  - AWS SSM Parameter Store는 SecureString 지원
  - HashiCorp Vault는 모든 비밀 암호화와 ACL 제공
  - GitHub Actions는 모든 비밀 로그 마스킹
  - Netlify는 secret 토글이 있는 환경 변수 방식

자격 증명 팬아웃과 하류 위험

Credential fan-out은 하나의 플랫폼 침해가 그 플랫폼에 저장된 자격 증명으로 인증되는 모든 하류 서비스까지 연쇄 노출되는 현상
Vercel 프로젝트 환경 변수에 자주 포함될 수 있는 항목과 하류 영향 정리
- 데이터베이스
  - DATABASE_URL, POSTGRES_PASSWORD
  - 전체 데이터 접근 가능성
- 클라우드
  - AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
  - 클라우드 계정 침해 가능성
- 결제
  - STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET
  - 재무 데이터, 환불 사기 위험
- 인증
  - AUTH0_SECRET, NEXTAUTH_SECRET
  - 세션 위조, 계정 탈취 가능성
- 메일 발송
  - SENDGRID_API_KEY, POSTMARK_TOKEN
  - 신뢰 도메인 기반 피싱 가능성
- 모니터링
  - DATADOG_API_KEY, SENTRY_DSN
  - 텔레메트리 조작 가능성
- 소스 및 패키지
  - GITHUB_TOKEN, NPM_TOKEN
  - 공급망 주입 가능성
- AI/ML
  - OPENAI_API_KEY, ANTHROPIC_API_KEY
  - API 남용, 비용 발생 가능성
단일 Vercel 프로젝트는 보통 10~30개의 환경 변수 포함
조직 규모에서 50개 프로젝트 포트폴리오는 500~1,500개의 자격 증명이 플랫폼에 존재할 수 있음
이번 사건은 제한된 일부 고객 프로젝트만 접근됐다고 하나, 노출된 자격 증명 하나마다 별도의 시스템으로 이동할 지점이 될 수 있음
기사에서는 이 점을 플랫폼 침해를 단순 기밀성 사건이 아니라 소프트웨어 공급망 전반으로 확산되는 배수 효과로 규정

OAuth 신뢰 관계와 경계 방어 우회

OAuth 기반 침입은 전통적 자격 증명 기반 공격을 탐지·차단하는 다수 통제를 비켜감
기사에는 약 22개월이라는 문장이 있으나, 상단 정정에서는 체류 기간이 약 2개월로 수정되어 있음
보안팀이 좌측 열에서 의존하는 방어 통제들이 OAuth 앱 침해 경로에서는 무의미하거나 이미 충족된 항목이 된다고 서술
이 비대칭성 때문에 OAuth 거버넌스가 IAM과 별도 보안 영역으로 부상
OAuth 거버넌스는 벤더 리스크 기능
- 많은 조직은 OAuth 승인을 개발자 셀프서비스 문제로 취급
- 직원별 필요 도구 승인과 최소한의 중앙 검토에 머무름
- 이번 사건은 승인된 OAuth 앱을 지속 접근 권한을 가진 제3자 벤더로 다뤄야 한다는 근거로 제시
- 벤더 검토, 주기적 재승인, 이상 사용 모니터링 필요

위협 행위자 주장과 귀속

지하 포럼의 위협 행위자 주장은 본질적으로 신뢰하기 어렵다는 전제
여기의 정보는 확인 사실이 아니라 인식 및 추적 목적으로 정리
ShinyHunters 연계 주장
- BreachForums 게시자는 ShinyHunters 연계를 주장하며 Vercel 데이터 보유 주장
- 주장된 데이터 항목
  - 직원 기록 약 580건
  - 소스 코드 저장소
  - API 키와 내부 토큰
  - GitHub 및 NPM 토큰
  - 내부 커뮤니케이션
  - Linear workspace 접근
- 위 수량과 범위는 모두 검증되지 않음
귀속을 어렵게 하는 요소
- 알려진 ShinyHunters 구성원은 BleepingComputer에 관여를 부인
- Telegram을 통한 200만 달러 몸값 요구가 있었다는 주장 존재
- ShinyHunters 브랜드는 원래 캠페인 이후 다수 또는 무관한 행위자에게 사용돼 왔음
- Vercel 보안 공지에는 해당 포럼 주장 언급 없음
- Rauch의 스레드는 공격 체인은 다루지만 포럼 게시물은 직접 다루지 않음
공급망 릴리스 경로에 대한 Vercel 입장
- Rauch는 Next.js, Turbopack, 다수 오픈소스 프로젝트의 공급망을 분석했고 커뮤니티에 안전하다고 언급
- 작성 시점 기준 독립 검증은 진행 중
- Next.js, Turbopack, 기타 Vercel 오픈소스 사용 조직은 체크섬, 서명, provenance attestation 등 패키지 무결성 신호를 계속 점검해야 한다고 권고
- 포럼 주장 데이터에 대한 독립 검증이 없는 만큼 미확인 정보로 취급 필요
- Vercel이 밝힌 OAuth 기반 공격 체인만으로도 사건은 기술적으로 성립하며, 포럼 게시자가 주장한 광범위한 접근 범위까지 필수 조건은 아니라는 평가

MITRE ATT&CK 매핑

확인된 공격 체인은 기존 MITRE ATT&CK 기법에 자연스럽게 매핑
매핑 항목
- Initial Access / Trusted Relationship / T1199
  - Context.ai OAuth 앱을 신뢰된 제3자로 활용
- Persistence / Application Access Token / T1550.001
  - OAuth 토큰이 비밀번호 변경 후에도 지속
- Credential Access / Valid Accounts / T1078
  - 손상된 직원 Workspace 자격 증명
- Discovery / Account Discovery / T1087
  - 내부 시스템 및 프로젝트 열거
- Credential Access / Unsecured Credentials: Credentials in Files / T1552.001
  - non-sensitive 환경 변수 접근 가능
- Lateral Movement / Valid Accounts: Cloud Accounts / T1078.004
  - 노출된 클라우드 자격 증명 사용 가능성
- Collection / Data from Information Repositories / T1213
  - 프로젝트 전반 환경 변수 열거
이 매핑에서 가장 가치 높은 탐지 지점은 OAuth 애플리케이션 접근에서 내부 시스템 접근으로 넘어가는 구간
조직은 기대 범위를 벗어나거나 예상하지 않은 IP 범위에서 자원에 접근하는 OAuth 앱의 이상 행동 모니터링 필요

공급망 포위전: LiteLLM, Axios, Vercel

Vercel 사건은 단독 사건이 아니라 2026년 3월~4월에 집중된 공급망 공격 흐름 속에 위치
기사에서는 이것을 협조된 캠페인일 수도 있고, 더 가능성 높은 해석으로는 여러 공격자가 동일한 구조적 약점인 패키지 저장소, CI/CD, OAuth 제공자, 배포 플랫폼 간 신뢰 경계를 동시에 발견한 결과일 수 있다고 적시
2026년 3월 24일: LiteLLM PyPI 공급망 침해
- 악성 PyPI 패키지 litellm 1.82.7, 1.82.8 게시
- Aqua Security의 취약점 스캐너 Trivy에서 탈취한 CI/CD 배포 자격 증명 사용
- LiteLLM은 일일 약 340만 다운로드 규모의 LLM 프록시
- 3단계 백도어가 주요 클라우드 제공자 전반 50종 이상의 자격 증명 유형을 겨냥
- Kubernetes DaemonSet 지속성 포함
- 탐지 및 제거 전 체류 시간은 약 40분~3시간
- 관련 CVE는 CVE-2026-33634
2026년 3월 31일: Axios npm 공급망 침해
- npm 패키지 axios는 주당 7천만~1억 다운로드 규모
- 유지관리자 계정 탈취로 악성 버전 1.14.1, 0.30.4 배포
- plain-crypto-js@4.2.1 의존성 주입, 크로스플랫폼 RAT 포함
- 감염된 135개 엔드포인트가 공격자 C2와 통신한 것으로 탐지
- 체류 시간은 2~3시간
- Microsoft는 이 공격을 북한 후원 위협 행위자 Sapphire Sleet에 귀속
수렴 패턴
- 3주 동안 3건의 공격
- 서로 다른 벡터
- 공통 표적은 개발자가 툴체인에 저장한 자격 증명과 비밀
- 표 요약에는 다음이 제시됨
  - LiteLLM: CI/CD 자격 증명 탈취 → PyPI, 개발자 자격 증명과 API 키, 40분~3시간
  - Axios: 유지관리자 계정 탈취 → npm, 개발자 워크스테이션 RAT, 2~3시간
  - Vercel: OAuth 앱 침해 → 플랫폼, 고객 환경 변수, 표에는 약 22개월로 기재되나 상단 정정과 본문에서는 약 2개월로 수정됨

이전 플랫폼 침해와의 공통 패턴

Vercel 침해는 플랫폼 수준 침해가 고객 비밀을 노출시키는 반복 패턴과 연결
Codecov Bash Uploader 침해, 2021년 1월~4월
- 공격자가 Bash Uploader 스크립트를 수정해 고객 CI 환경의 환경 변수 유출
- 약 2개월간 미탐지
- 2만9천 개 이상 고객 잠재 영향, Twitch, HashiCorp, Confluent 포함
- Vercel과의 공통점은 플랫폼 침해를 통한 고객 환경 변수 노출
CircleCI 보안 사고, 2023년 1월
- 개인 기기 악성코드로 직원 SSO 세션 토큰 탈취
- 내부 시스템 접근 후 고객 비밀과 암호화 키 유출
- CircleCI는 모든 고객에게 플랫폼에 저장된 모든 비밀 회전 권고
- Vercel과 거의 동일한 구조
  - 직원 계정 침해
  - 내부 시스템 접근
  - 고객 비밀 유출
Snowflake 고객 자격 증명 공격, 2024년 5~6월
- UNC5537이 infostealer로 획득한 자격 증명과 MFA 미적용 계정을 사용
- 165개 이상 조직 영향
- Ticketmaster, Santander Bank, AT&T 포함
Okta 지원 시스템 침해, 2023년 10월
- 탈취 자격 증명으로 고객 지원 케이스 관리 시스템 접근
- HAR 파일 내 세션 토큰 열람
- Cloudflare, 1Password, BeyondTrust 포함 고객 영향
패턴 요약
- 신뢰 관계 또는 자격 증명을 통한 초기 접근
- 내부 시스템으로 측면 이동
- 고객 비밀 유출
- 대상 범위는 일부 표적에서 플랫폼 전반까지 다양
- 표에는 사건별 초기 벡터, 노출 자산, 탐지 지연 정리
  - Codecov 약 2개월
  - Okta 수주
  - CircleCI 수주
  - Snowflake 수개월
  - Vercel 약 2개월

아직 공개되지 않은 사항

공개 보도와 임원 발언이 많지만 핵심 공백도 여전히 존재
공개 기록상 미해결 질문
- Vercel이 이상 활동을 최초 탐지한 시점
- 가장 이른 공개 자격 증명 악용 증거와 공개 사이 9일 차이의 이유
- 영향 고객 수
  - Rauch는 “quite limited”라고 표현했지만 구체 숫자 비공개
- ShinyHunters 포럼 주장이 동일 공격자에 의한 것인지 여부
- Context.ai의 현재 상태와 하류 고객 통지 여부
- Vercel 내부 접근 전체 범위
  - 영향 팀 수, 프로젝트 수, 환경 변수 수 비공개
  - 고객 환경 변수 외 다른 내부 시스템 접근 여부도 미확인
기사에서는 알려진 사실뿐 아니라 공개되지 않은 사항을 명시적으로 인정하는 태도가 엄밀한 분석에 필요하다고 강조

탐지 및 헌팅 가이드

Vercel 고객용 즉시 조치
- 모든 프로젝트 환경 변수 감사 필요
- 기사에는 다음 CLI 예시 포함
  - vercel env ls --environment production
  - vercel env ls --environment preview
  - vercel env ls --environment development
- CLI는 현재 sensitive 플래그를 직접 노출하지 않으므로 대시보드 또는 API 확인 필요
노출 자격 증명의 비인가 사용 탐색
- 클라우드 제공자 감사 로그 검색
  - AWS CloudTrail
    - sts.amazonaws.com, iam.amazonaws.com, s3.amazonaws.com 포함 eventSource 필터
    - 회전한 Vercel 저장 access key와 일치하는 userIdentity.accessKeyId 검색
    - 조직의 알려진 CIDR 바깥 sourceIPAddress, python-requests, curl, Go-http-client, 익숙하지 않은 자동화 문자열 userAgent 탐지
    - 기간은 2026년 2월부터 현재
  - GCP Audit Logs
    - Vercel에 저장된 키를 쓰는 서비스 계정의 protoPayload.authenticationInfo.principalEmail 검색
    - 알려진 범위를 벗어난 callerIp
    - storage.objects.get, compute.instances.list, iam.serviceAccountKeys.create 등 메서드 확인
  - Azure Activity Logs
    - Vercel env vars에 있던 애플리케이션 ID 또는 서비스 프린시펄 기준 필터
    - 예상 범위를 벗어난 callerIpAddress
    - Microsoft.Storage/storageAccounts/listKeys, Microsoft.Compute/virtualMachines/write, Microsoft.Authorization/roleAssignments/write 우선 점검
- 데이터베이스 접근 로그 검색
  - 연결 문자열이 Vercel 환경 변수에 있었던 모든 DB 대상
  - 2026년 2월~4월 전체 창 분석
  - Vercel edge IP, VPN, 사무실 등 알려진 egress 범위를 벗어난 IP 확인
  - 정상 배포 창 외 노출 자격 증명 사용 접속 탐지
  - PostgreSQL은 pg_stat_activity, log_connections
  - MySQL은 general log 또는 audit plugin
  - MongoDB Atlas는 Project Activity Feed의 DATA_EXPLORER, CONNECT 이벤트
- 결제 처리 로그 검색
  - Stripe Dashboard → Developers → Logs
  - 예상 서버 외 source_ip
  - /v1/charges, /v1/transfers, /v1/payouts, /v1/customers
  - Braintree, Adyen의 동등 로그 확인
  - 아직 회전되지 않은 non-sensitive env var 저장 API 키 우선
  - 이메일 발송 서비스 로그의 예상치 못한 발송도 점검
- OpenAI, Anthropic, GitHub, AWS, Stripe 등에서 온 비자발적 유출 자격 증명 알림 확인 필요
회전과 재배포 동시 필요
- Vercel 문서 기준 환경 변수 회전만으로 과거 배포의 기존 자격 증명 값이 무효화되지 않음
- 이전 배포는 재배포 전까지 이전 자격 증명을 계속 사용
- 따라서 모든 회전은 해당 변수를 사용한 모든 환경의 재배포 또는 과거 배포의 명시적 비활성화 필요
- 우선순위는 다음 순서
  - 클라우드 제공자 자격 증명
  - 데이터베이스 연결 문자열
  - 결제 처리 키
  - 인증 비밀
  - 제3자 API 키
  - 모니터링 및 로깅 토큰
보안팀용 사전 대응
- Google Workspace Admin Console → Security → API Controls → Third-party app access에서 모든 승인 OAuth 앱 검토
- Drive, Gmail, Calendar 등 광범위 스코프 앱 표시
- 활성 비즈니스 관계가 없는 벤더 앱 조사
- 예상하지 않은 IP 범위에서의 OAuth 토큰 사용 감시
- 알려진 악성 OAuth Client ID 검색 필요
  - 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

SIEM 탐지 로직

OAuth 애플리케이션 이상 징후, 1~2단계
- 알려진 악성 OAuth Client ID와 연관된 토큰 refresh 또는 authorization 이벤트 즉시 경보
- 메일 전체 접근, Drive 읽기/쓰기, 캘린더 접근 등 광범위 스코프 권한 부여 이벤트를 현재 벤더 목록과 대조
- 더 이상 비즈니스 사용이 없는 앱은 철회 대상
- 승인된 OAuth 앱의 토큰 사용이 기업 및 벤더 예상 CIDR 범위 밖 IP에서 발생하면 조사 필요
내부 시스템 접근과 측면 이동, 3단계
- 이상한 SSO/SAML 인증 이벤트
  - 손상된 Workspace 계정이 처음 보는 IP, 지역, 디바이스 지문으로 내부 애플리케이션에 로그인하는 경우
- 이메일 및 Drive 기반 자격 증명 수집
  - API key, secret, token, password, .env 같은 키워드 대량 검색
  - 공유 자격 증명 저장소, 엔지니어링 런북, 인프라 문서 접근
  - 메일 포워딩 규칙 생성
- OAuth 연결 내부 도구 접근
  - Slack, Jira, GitHub, 내부 대시보드 등에서 평소와 다른 시간대나 인프라에서 세션 생성 또는 API 활동
- 권한 상승 시도
  - 새 그룹·역할 참여
  - 미사용 관리자 콘솔 접근
  - Google Workspace의 Directory API 호출, 위임 변경, 다른 사용자 OAuth 토큰 열거 시도 감시
환경 변수 열거, 4단계
- Vercel 팀 감사 로그에서 env read, list, decrypt 성격 호출의 비정상적 대량·빈도 패턴 탐지
- 먼저 정상 CI/CD 빌드 시점 베이스라인 수립 필요
- 그 후 볼륨, 시점, 소스 주체가 베이스라인을 벗어나는 접근 경보
- 서비스 계정이 아닌 사용자 계정에서의 접근, 평소 프로젝트와 상호작용하지 않던 계정의 접근에 주목
하류 자격 증명 남용, 5단계
- 2026년 2월~4월 창 동안 non-sensitive Vercel 환경 변수로 저장됐던 모든 자격 증명 대상 서비스 로그 점검
- AWS는 특정 access key ID 기준 CloudTrail 검색
- GCP, Azure는 서비스 계정 또는 애플리케이션 ID 기준 감사 로그 검색
- Stripe, OpenAI, Anthropic, SendGrid, Twilio 등 SaaS API는 대시보드 또는 API 로그에서 미인지 IP, 비활성 시간대 사용 여부 확인
- 자체 인프라로 귀속할 수 없는 사용은 즉시 손상 자격 증명으로 간주해 회전 및 행위 조사 필요
제3자 자격 증명 유출 알림
- GitHub secret scanning partner program, AWS compromised key detection, OpenAI, Anthropic, Stripe, Google Cloud 등 자동 비밀 스캔 알림 모니터링 필요
- 배포 플랫폼에만 존재하던 키에 대한 알림은 단순 위생 경고가 아니라 플랫폼 침해 지표로 취급 필요

위협 헌팅 수동 절차

Google Workspace Admin Console 수동 검색
- Admin Console → Reports → Audit and Investigation → OAuth Log Events
- Application Name = Context.ai 또는 Client ID = 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
- 기간은 2026년 2월부터 현재
- 결과가 있으면 즉시 권한 철회 및 사고 조사 필요
광범위 스코프 제3자 OAuth 앱 점검
- Admin Console → Security → API Controls → Third-party app access → Manage Google Services
- App access가 Unrestricted인 앱 정렬
- 각 앱별 확인 항목
  - 활성 벤더 관계 존재 여부
  - 스코프의 비즈니스 정당성
  - 최근 사용일
- 90일 이상 미사용 앱은 철회 대상

방어 권고

즉시 조치, 0~48시간
- sensitive로 표시되지 않은 모든 Vercel 환경 변수 회전
- 회전 후 모든 환경 재배포
- 자격 증명, 토큰, 키, 시크릿이 포함된 모든 환경 변수에 sensitive 플래그 활성화
- Google Workspace 또는 Microsoft Entra 관리자 콘솔에서 OAuth 앱 승인 감사
- 더 이상 활발히 사용하지 않는 앱 접근 철회
- 2026년 2월부터 현재까지, Vercel 환경 변수에 저장됐던 자격 증명이 사용된 모든 서비스의 접근 로그 검토
단기 강화, 1~4주
- HashiCorp Vault, AWS Secrets Manager, Doppler, Infisical 같은 전용 비밀 관리자 사용으로 이전
- 플랫폼 환경 변수 저장 대신 런타임 주입 방식 사용
- 지원되는 곳에서는 OIDC 기반 인증으로 장기 자격 증명 제거
- OAuth 앱 모니터링 도입
  - Nudge Security, Grip Security, Valence Security 또는 Google Workspace 기본 관리 기능
- 자격 증명 회전 자동화 구축
  - 30~90일 주기 제시
- OAuth 승인을 계약 벤더와 같은 제3자 리스크 인벤토리에 포함
구조적 변경, 1~6개월
- 환경 변수에 대한 Zero Trust 자세 채택
  - 배포 플랫폼에 저장된 모든 비밀은 플랫폼 침해 시 노출될 수 있다고 가정
- 최소 권한 범위 적용
  - DB 계정 최소 권한
  - API 키 연산 범위 제한
  - 클라우드 자격 증명은 장기 access key 대신 역할 기반 임시 자격 증명
- 기업 아이덴티티 시스템에 접근하는 모든 OAuth 앱·통합에 대해 제3자 보안 검토와 주기적 재검토 수행
- PaaS 플랫폼을 SBOM/ASPM 인벤토리에 포함
  - 외부 서비스가 아니라 1급 공급망 의존성으로 취급 필요
권장 모니터링
- Google Workspace Admin Console에서 위 OAuth Client ID 감사
- Vercel 감사 로그에서 예상치 못한 env.read, env.list API 호출 모니터링
- 2026년 2월~4월 사이 Vercel env vars 저장 자격 증명의 예상 밖 IP, user agent 사용 여부를 CloudTrail, GCP Audit Logs, Azure Activity Logs에서 검토
- 의존성 트리에 LiteLLM 또는 Axios가 있다면 각 권고문에 나온 IOC도 함께 모니터링
- 노출 기간 동안 주요 API 제공자의 비자발적 유출 자격 증명 알림 감시

규제 및 컴플라이언스 영향

이 침해로 자격 증명 노출을 겪었을 수 있는 조직은 다음 의무 평가 필요
GDPR
- 노출된 자격 증명이 EU 개인정보가 있는 시스템 접근을 허용했다면 72시간 통지 시계가 노출 확인 시점부터 시작될 수 있음
- 4월 10일 OpenAI 알림은 일부 조직의 인지 시점이 4월 19일 공개보다 앞설 수 있다는 질문 제기
CCPA/CPRA
- 소비자 데이터 접근 권한을 주는 자격 증명 노출은 통지 의무를 유발할 수 있음
PCI DSS
- Stripe, Braintree, Adyen 등 결제 처리 자격 증명 노출 시 사고 대응 절차와 포렌식 조사 요구 가능
SOC 2
- 사고 기록, 자격 증명 회전 조치, 갱신된 통제를 지속 모니터링 증거에 반영 필요
SEC Cybersecurity Rules 8-K
- 중요성이 있다고 판단한 상장사는 4영업일 공시 의무
- 기사에서는 실제 무단 접근 사용 여부를 아직 모를 수 있어도, 다수 규제 프레임워크는 악용 확인이 아니라 노출 자체를 기준으로 작동할 수 있다고 지적