Vercel 침해 사고의 핵심은 "플랫폼이 뚫렸다"가 아닙니다. 더 중요한 건, 작은 서드파티 OAuth 앱 하나가 직원의 Google Workspace 계정을 거쳐 내부 시스템과 고객 환경변수까지 이어지는 신뢰 사슬을 만들었다는 점입니다.12
현재까지 공개된 사실로는, 공격은 Context.ai 관련 OAuth 앱 손상에서 시작됐고, 그 결과 일부 Vercel 내부 시스템과 "sensitive"로 표시되지 않은 환경변수에 접근이 가능해졌습니다.1 이게 지금 중요한 이유는 많은 팀이 여전히 비밀정보를 "프로덕션/비프로덕션", "민감/비민감" 정도로만 나누는데, 실제 공격자는 그 중간 지점을 발판으로 더 큰 권한을 얻기 때문입니다.
위험했던 것은 데이터베이스보다 "안전하다고 믿은 자격증명"이었다
Vercel은 "sensitive"로 표시된 환경변수는 읽을 수 없는 방식으로 저장됐고, 현재까지 그 값이 접근됐다는 증거는 없다고 설명했습니다.1 반대로 말하면, 그렇게 표시되지 않은 값은 내부 접근을 얻은 공격자에게 의미 있는 단서가 될 수 있었다는 뜻입니다. CEO 설명과 외부 보도를 종합하면, 공격자는 이 변수들을 열람·열거하면서 추가 접근 경로를 찾았습니다.123
여기서 실무적으로 중요한 포인트가 나옵니다. "비민감" 환경변수라고 이름 붙어 있어도 실제로는 그렇지 않을 수 있습니다. 내부 API 엔드포인트, 서비스 계정 토큰, CMS 키, 배포 우회 토큰, GitHub 연동 토큰처럼 단독으로는 치명적이지 않아 보여도, 다른 시스템과 결합되면 권한 상승의 재료가 됩니다.
이 사고는 비밀관리의 분류가 너무 단순하면 방어도 단순해진다는 점을 드러냈습니다. 공격자는 가장 가치 있는 비밀 하나를 노리기보다, 여러 개의 "그럭저럭 괜찮아 보이는" 값들을 이어 붙입니다. 그래서 환경변수 보안에서 중요한 질문은 "이 값이 고객 DB 비밀번호인가?"가 아니라 "이 값이 다음 시스템으로 넘어가는 다리인가?"여야 합니다.
30분 안에 해야 할 일: 계정이 아니라 신뢰 관계를 그려라
이번 사고를 자기 조직에 대입할 때 가장 먼저 볼 것은 Vercel 자체가 아니라 연결 구조입니다. 특히 Vercel, GitHub, Google Workspace, Linear, npm, 내부 관리도구처럼 개발 워크플로에 묶여 있는 서비스들을 한 줄로 이어서 봐야 합니다.
빠르게 점검하려면 세 가지만 추적하면 됩니다.
첫째, 누가 어떤 OAuth 앱에 권한을 줬는가. Vercel은 문제의 Google OAuth 앱 ID까지 공개하며 관리자 점검을 권고했습니다.1 Google Workspace 관리 콘솔에서 해당 앱과 유사한 서드파티 앱 승인 내역을 확인해야 합니다.
둘째, 그 계정이 어떤 내부 도구로 이어지는가. 직원 한 명의 Workspace 계정이 곧 Vercel 팀, GitHub 저장소, 배포 권한, 활동 로그 접근으로 연결돼 있다면, 계정 탈취는 곧 운영 경로 탈취입니다.
셋째, 환경변수와 토큰 중 무엇이 재사용 가능한가. 장기 유효 토큰, 수동 발급 API 키, 배포 보호 우회 토큰은 우선순위가 높습니다.1
여기서 한 가지 반론도 가능합니다. "그래도 sensitive 기능이 있었고, 영향을 받은 고객도 제한적이지 않나?" 맞는 말입니다. 현재 공개 정보만 보면 전면적 플랫폼 붕괴로 단정할 근거는 없습니다.14 하지만 이 사건의 교훈은 전체 고객 수보다 구조에 있습니다. 제한적 피해였더라도, 그 제한은 공격자의 의도가 아니라 특정 신뢰 링크와 저장 방식 덕분이었을 수 있습니다.
무작정 전부 돌리지 말고, 먼저 끊어야 할 것을 끊어라
사고 대응에서 흔한 실수는 "일단 모든 키를 교체하자"입니다. 비용은 큰데 효과는 생각보다 낮을 수 있습니다. 이번 건에서는 회전보다 먼저 철회해야 할 것이 분명합니다.
우선순위는 대체로 이렇습니다. 먼저 문제의 OAuth 앱 승인과 관련 세션을 제거하고, Google Workspace와 Vercel의 활동 로그를 확인해야 합니다.1 그다음 Vercel에서 non-sensitive로 남아 있던 환경변수, 배포 보호 토큰, 외부 서비스 연동 토큰을 돌리는 편이 맞습니다.1 최근 배포 이력과 예상 밖의 변경도 같이 봐야 합니다.1
반면 모든 비밀을 한꺼번에 재발급하는 건 꼭 정답이 아닙니다. 고객 영향 범위가 제한적일 수 있고, 현재까지 오픈소스 패키지 변조 증거도 없다고 Vercel은 밝혔습니다.12 즉, 공급망 전체가 이미 오염됐다고 가정하고 무차별 대응할 단계는 아닙니다. 확인된 공격 경로에 가까운 것부터 좁혀서 처리하는 편이 더 합리적입니다.
다음 침해는 "침해처럼" 보이지 않을 가능성이 크다
이번 사건은 취약점 익스플로잇보다 신원과 위임의 과잉 신뢰가 더 큰 리스크가 됐다는 점에서 상징적입니다. 특히 OAuth 토큰은 비밀번호를 몰라도 동작하고, 비밀번호를 바꿔도 남아 있을 수 있으며, 한 번 승인되면 오랫동안 잊히기 쉽습니다.4
그래서 앞으로의 판단 기준도 바뀌어야 합니다. 플랫폼 도입을 볼 때 "암호화하나?"만 묻지 말고, "어떤 비밀이 읽기 가능한가", "기본값이 최소권한인가", "외부 OAuth 앱을 어떻게 제한하나", "감사 로그와 토큰 수명 제어가 충분한가"를 함께 봐야 합니다.
이 사건을 특히 신경 써야 하는 팀은 Vercel 사용자만이 아닙니다. Google Workspace 기반으로 서드파티 AI 도구, 개발 플랫폼, 배포 자동화를 촘촘히 연결해 둔 조직이라면 같은 실패 모드가 어디서든 반복될 수 있습니다. 이제 점검 기준은 "우리가 해킹당할까?"가 아니라 "계정 하나나 앱 하나가 넘어가면 어디까지 조용히 이어지나?"여야 합니다.
참고
1Vercel April 2026 security incident
2Vercel confirms breach as hackers claim to be selling stolen data
3App host Vercel says it was hacked and customer data stolen
4The Vercel breach: OAuth attack exposes risk in platform environment variables
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.