Vercel OAuth 공급망 공격, 환경변수 한 줄이 통째로 털린 사건

조용히 일어났지만 파장이 큰 사고

Vercel에서 OAuth 토큰을 매개로 한 공급망 침해(supply chain attack) 사건이 확인됐어요. 이번 사건의 무서운 점은 코드 저장소가 털린 것도, 서버가 해킹당한 것도 아니라는 거예요. 개발자들이 Vercel에 저장해둔 환경변수(environment variables)가 제3자 통합 앱을 통해 유출된 구조거든요. 요즘 서버리스·정적 호스팅 플랫폼에서 환경변수는 API 키, DB 비밀번호, 결제 시크릿 같은 "서비스의 금고 열쇠"를 모아놓는 곳이라, 이게 새어나가면 해당 프로젝트의 외부 연동 전체가 위험해져요.

사건의 구조를 단순하게 풀어볼게요. Vercel은 GitHub, Slack, Sentry 같은 서드파티 서비스와 OAuth로 연동돼 있어요. 사용자가 "이 앱이 내 Vercel 계정에 접근해도 돼"라고 권한을 주면, 토큰 하나가 발급돼서 그 앱이 사용자 대신 API를 호출할 수 있게 되죠. 이번엔 특정 통합 앱의 토큰이 공격자 손에 들어가면서, 그 토큰을 가진 공격자가 Vercel API를 호출해 프로젝트의 환경변수를 줄줄 읽어간 거예요.

왜 막기 어려웠을까

OAuth 공급망 공격이 까다로운 이유는 정상 트래픽과 구분이 안 된다는 데 있어요. 공격자가 사용한 건 합법적으로 발급된 토큰이고, API 호출은 정해진 스코프(scope) 안에서 이뤄졌으니 로그만 봐서는 "평소 연동 앱이 일 잘하고 있네" 수준으로만 보여요. 전통적인 웹 공격 탐지 시그니처에는 안 걸리는 구조죠.

게다가 OAuth 토큰은 보통 장기간 유효해요. 비밀번호 바꾸는 것처럼 주기적으로 교체하는 관행이 아직 덜 자리잡았거든요. 여기에 OAuth 스코프가 너무 넓게 설정돼 있던 것도 피해를 키웠어요. 만약 "프로젝트 목록 읽기"만 필요한 앱이 "환경변수 전체 읽기" 권한까지 함께 요구했고, 사용자는 관성적으로 "Allow"를 눌렀다면, 그 앱이 뚫렸을 때 피해 범위는 훨씬 커지죠. 이걸 보안 업계에서는 over-privileged OAuth scope 문제라고 불러요.

기술적으로 더 들어가 보면, 공격자는 환경변수를 덤프한 뒤 그 안에 있는 AWS 키, Stripe 시크릿, 데이터베이스 연결 문자열을 이용해 2차, 3차 공격으로 번져나갈 수 있어요. 이게 바로 "공급망 공격"이 무서운 이유예요. 한 플랫폼이 뚫리면 그 플랫폼을 쓰는 수백 개 서비스가 연쇄적으로 노출돼요. SolarWinds, Codecov, 최근의 여러 npm 패키지 사건이 같은 카테고리에 들어가요.

업계 맥락에서 보면

이번 건은 단발 사고가 아니라 플랫폼 시대 보안 모델의 구조적 숙제를 다시 드러낸 사건이에요. Vercel, Netlify, Cloudflare Pages, Railway, Render 같은 호스팅 플랫폼들은 개발자 생산성을 극적으로 끌어올렸지만, 그 편의성의 대가로 "내 서비스의 시크릿이 남의 서버에 저장된다"는 위험을 안고 있어요.

비슷한 문제의식으로 나온 기술이 Secret Manager + Workload Identity 조합이에요. AWS Secrets Manager, Google Secret Manager, HashiCorp Vault 같은 전문 시크릿 저장소에 실제 값을 두고, 애플리케이션은 런타임에 짧은 수명의 토큰으로 값을 가져가는 방식이죠. Vercel도 Edge Config, Fluid Compute 같은 기능에서 이런 방향을 조금씩 제시하고 있지만, 대다수 프로젝트는 여전히 플랫폼 대시보드에 평문 환경변수를 박아두고 써요.

한국 개발자가 지금 할 수 있는 것

당장 점검해볼 일이 몇 개 있어요. 첫째, Vercel 계정의 Connected Integrations를 열어보세요. 기억도 안 나는 앱이 권한을 쥐고 있다면 과감히 revoke 하세요. 둘째, 환경변수 중 민감한 값들은 즉시 로테이션하는 게 안전해요. 특히 결제·데이터베이스·클라우드 관리 권한이 있는 키는 우선순위 최상위예요. 셋째, 가능하면 장기 시크릿 대신 OIDC 페더레이션으로 전환하세요. GitHub Actions나 Vercel이 AWS에 접근할 때 고정 키 대신 단기 토큰으로 인증하는 방식이에요.

조직 차원에서는 시크릿 유출 탐지 도구를 파이프라인에 끼워두는 걸 권해요. GitGuardian, TruffleHog 같은 오픈소스 도구로 커밋과 로그에서 키 패턴을 스캔하고, 클라우드 쪽에서는 의심스러운 API 호출 패턴을 감지하는 CloudTrail·CloudWatch 알람을 설정해두면 좋아요. 그리고 가장 중요한 건 "이 앱이 정말 그 권한까지 필요한가?"를 한 번 더 묻는 습관이에요. OAuth 동의 화면에서 스코프를 꼼꼼히 보는 1초가 나중의 대형 사고를 막아줍니다.

한 줄 정리

플랫폼이 편해진 만큼, 시크릿은 내 금고가 아니라 남의 금고에 맡겨져 있어요. 여러분 프로젝트에 지금 살아 있는 OAuth 연동은 몇 개이고, 그중 마지막으로 권한을 재검토한 게 언제인가요?