Vercel이 환경 변수 UI를 처음 내놨을 때는 sensitive 옵션 자체가 없었던 걸 떠올리게 됨. 그 기능이 들어오기까지 거의 2년 넘게 걸렸음. 관련 논의는 GitHub discussion과 Vercel changelog에 남아 있음
UI에 sensitive 플래그를 붙여도 런타임이 바뀌는 건 아니라는 생각임. 빌드 시점에 process.env에 들어간 순간, 훑어보려는 의존성이 있으면 읽을 수 있음. 진짜 문제는 모든 비밀값을 하나의 env 주머니에 몰아 넣고 빌드 도구에 통째로 넘기는 구조라고 봄. Cloudflare의 scoped bindings나 Fly는 이미 분리하고 있고, 다른 플랫폼이 느린 편이라는 판단임
sensitive는 읽기 불가를 뜻하는 게 아니라 UI 비노출 정도의 의미일 뿐이라고 봄. action 함수나 route에서 props를 조금만 과하게 반환해도 쉽게 새어 나갈 수 있음. 이런 류의 문제를 막으려면 결국 자체 키로 환경값을 암호화해야 하고, 분리 수단이 마땅치 않으니 일부 비밀은 소스에 baked-in하는 우회도 가능해 보임. 공격자는 환경값 읽기뿐 아니라 빌드 결과물을 내려받아 복호화 키까지 찾아야 하니 장벽이 조금 높아짐. 이상적이진 않지만 임시방편으로는 작동 가능해 보임
이런 식으로 걸린 게 정말 민망한 사고처럼 느껴짐. 인용된 내용대로라면 Lumma Stealer 감염이 Context.ai 직원의 Roblox exploit script 다운로드에서 시작됐다는 점이 특히 당황스러움
CEO가 공격자의 빠른 움직임을 AI 가속 공격 기법 때문이라고 공개적으로 돌렸다는 대목은, 내가 보기엔 근거가 거의 보이지 않음. 그래서 실질적으로 드러나는 정보도 별로 없다는 느낌임
요즘은 AI가 말도 안 되는 변명 시장까지 뒤흔들고 있고, 언론이 그걸 검증 없이 반복하는 것처럼 보인다는 냉소가 듦
한편으로는 vibe coded 솔루션들이 Vercel을 자주 추천하는 경향이 있었던 점을 떠올리게 됨. 예전의 Axios 추천 열풍과 비슷한 결로 보임
나는 Stage 2 설명이 잘 이해되지 않았음. ContextAI 앱이 Google mail, drive, calendar 같은 권한을 다 요청했다면 너무 과하다는 생각임. 작은 회사도 아니고 이런 걸 자체 환경 밖에서 돌리는 데 동의했다는 게 믿기 어려웠음. 다만 Context.ai의 보안 업데이트 글을 보니, Vercel 직원 한 명이 개인적으로 자기 Google Workspace 전체 접근을 허용한 선택처럼 읽힘
이번 흐름이 정확히 어떻게 작동했는지 아직도 감이 잘 안 옴. 여기서 말하는 OAuth token이 Sign in with Google 후 받는 토큰인지 궁금함. 보통 그건 특정 Google App의 client id와 client secret에 묶이는 것 아닌가 싶음. 공격자가 사용자 OAuth token과 client 정보까지 알아도 Drive 등에 접근하는 것까지는 이해되지만, 거기서 어떻게 Vercel의 control plane 로그인으로 이어졌는지는 납득이 잘 안 됨. 결국 Google Drive 안에서 자격 증명을 찾은 건지 궁금함
보고서가 그 부분을 명확히 말하지 않는다고 느낌. 그래서 오히려 뭔가 더 민망한 실수가 있었고 그걸 숨기는 것 아닌가 추측하게 됨. Drive나 Gmail 안의 비밀번호였을 수도 있고, 다른 댓글처럼 passwordless login link였을 수도 있음
OAuth 과정을 끝내고 나면 결국 session token을 받게 되고, 그걸로 API 요청을 날릴 수 있다는 설명이 핵심처럼 보임. 발급된 토큰이 피해자의 inbox 접근 권한까지 갖고 있었을 가능성이 높고, 공격자는 이메일을 읽어 일회용 비밀번호, magic link, 기타 민감한 정보를 얻었을 거라는 추정임
나 역시 헷갈림. 정말 Context.ai의 OAuth 앱이 뚫린 것인지, 그래서 Context.ai가 보던 모든 고객 워크스페이스 가시성을 공격자도 그대로 얻게 된 것인지 궁금함. 그런데 왜 특정 직원 한 명에게 책임이 집중되는지도 의문임. 결국 그 Vercel 직원이 Vercel 전체 워크스페이스를 읽도록 Context.ai에 승인한 것인지가 핵심처럼 보임
“OAuth 앱을 제3자 벤더처럼 다루고, 장기 플랫폼 비밀을 없애고, provider-side compromise를 가정해 설계해야 한다”는 말에는 공감하면서도, 공급자 측 침해를 전제로 설계하는 건 정말 어렵다고 느낌. 애초에 신뢰가 시스템의 출발점이기 때문임
우리 SaaS에서 OAuth 앱을 고민하는 입장이라 더더욱 매우 어려운 문제처럼 느껴짐. 이걸 잘 푸는 marketplace가 있는지도 궁금함. Cloudflare는 Salesloft 사고 후 모든 제3자 OAuth와 API 트래픽을 자신들을 통해 프록시하자고 제안했는데, 그건 위협 벡터를 다른 곳으로 옮기는 느낌도 듦. scope 최소화, 만료 단축, client secret rotation 같은 기본 수칙 외에 뭘 더 할 수 있을지 막막함. client별 요청 출발 IP allowlist 정도가 떠오름
이런 사례를 보면 지금까지 말해 온 zero-trust가 상당 부분 마케팅 수사였다는 생각도 듦. 진짜 security by design이라면 공급망 공격으로 상위 제공자가 완전히 뚫릴 수 있다는 전제를 처음부터 넣어야 한다는 주장임
앞으로는 이런 사건이 훨씬 더 많이 나올 거라고 봄. 대기업이든 소규모 업체든 AI 도구를 널리 실험해 온 데 따른 리스크 부채를 이제 IT 경제 전체가 뒤늦게 맞이하는 중이라는 생각임. 그래서 이걸 “AI-enabled tradecraft”라기보다, 회사 리더십이 속도를 이유로 전사에 AI 도구 설치와 시험을 압박한 결과로 읽게 됨. 이런 공격 자체는 너무 평범하고, 강제 가능한 AI 설치 allowlist가 없는 회사라면 거의 다 노출돼 있음. Context 같은 도구들이 로컬과 SaaS 전반에서 얼마나 깔려 있는지 IT 담당자에게 물어보면 꽤 많을 가능성이 큼. 문제는 이런 도구들이 사실상 모든 것에 접근하고, 이를 통제할 보안 벤더나 RBAC 생태계는 18~24개월은 더 있어야 본격화될 거라는 점임. Vercel은 탄광의 카나리아처럼 보이고, Context만 표적이었을 리 없다고 봄. 한 곳이 터지면 다른 곳도 연쇄적으로 드러날 수 있는, 잘 알려졌지만 무시되던 위협 벡터라는 판단임. 향후 6개월이 특히 어려울 수 있고, 모두가 지금 AI 설치 현황을 감사 중이거나 감사해야 하며, 공격자도 차단되기 전에 가진 접근권으로 움직일 거라고 예상함. 참고로 나는 tech 업계의 보안 책임자임
나도 몇 년 동안 기묘한 보안 사고가 뉴스에 많이 나올 거라고 말해 왔음
나 역시 같은 시각임. 꽤 흥미로운 시기가 펼쳐지는 중이라는 느낌임
“OAuth 신뢰 관계가 플랫폼 전체 노출로 번졌고, CEO는 공격 속도를 AI 탓으로 돌렸고, 탐지에서 공개까지의 지연도 의문”이라는 요약을 보며, 내 눈에 보이는 핵심 실패는 전형적이라고 느낌임. 과도한 권한을 가진 사용자 계정이 있었고, 비슷한 계정이 더 있었을 수도 있음. 2FA나 ZeroTrust가 없거나 매우 제한적이었을 가능성도 커 보임. 전반적인 보안 위생도 좋지 않았다는 판단임
앞으로는 AI 탓하기가, 사이트가 터졌을 때 무조건 DDoS 탓하는 것과 비슷한 보안 사고용 만능 핑계가 될 것 같다는 생각임
사람들이 잘 놓치는 지점이 하나 있음. Vercel에서 환경 변수를 rotate해도 예전 배포가 자동으로 무효화되지 않아서, 이전 deploy는 재배포하거나 지우기 전까지 옛 자격 증명으로 계속 돌아감. 그래서 공지 후 키를 교체했더라도 모든 배포를 다시 올리지 않았다면 유출된 값이 여전히 살아 있을 수 있음. 그리고 Google Workspace의 OAuth 승인 내역도 꼭 확인해야 한다고 봄. Admin Console > Security > API Controls > Third-party app access에 들어가 보면, 2년 전 데모 때문에 승인한 앱이 아직도 메일과 Drive 전체 권한을 들고 있을 가능성이 높음
우리는 이런 이유로 여러 Google 계정을 따로 둠. 다만 많은 조직은 Google Workspace의 사용자당 비용 부담 때문에 그렇게 못 함. 나도 예전 직장에서 이런 OAuth 승인을 주 계정이 아닌 별도 계정으로 하자고 했다가 실패한 적이 있음
보통 credential rotation이라면 이전 자격 증명 무효화까지 포함된다고 생각함. 새 것만 만들고 예전 것을 계속 살려 두는 방식은 거의 들어본 적이 없다는 반응임
보고서의 그 문장은 나도 꽤 혼란스러웠음. 오래된 배포가 옛 env var를 쓴다는 사실 자체가 그 credential의 유효성 여부를 좌우하는 건 아니기 때문임. 이건 기밀성보다는 가용성에 영향을 주는 footgun에 가깝다고 느낌. 보고서의 “Environment variable enumeration (Stage 4)” 부분도 이상하게 읽힘. 특히 “service account가 아니라 user account에서, 혹은 평소 프로젝트와 상호작용하지 않던 계정에서 환경 변수 접근이 발생하는지 보라”는 설명을 보며, 사람들이 정말 Vercel env var에서 자격 증명을 꺼내 다른 시스템에 쓰고 있는 건가 싶어 낯설었음
Preview deploy는 더 심각하다고 느낌. PR마다 같은 env var로 하나씩 생기고, 아무도 정리하지 않음. 키를 돌리고 prod를 재배포해도, 예전 값이 들어간 좀비 preview가 수백 개 남아 있을 수 있음
rotation을 할 때는 당연히 이전 변수 만료까지 해야 한다는 지적임
이 보고서에 나온 일부 세부사항, 특히 2024~2025부터 시작되는 타임라인은 다른 곳에서 널리 보도되지 않은 내용처럼 느껴졌음. 예를 들어 “2024년 말~2025년 초 공격자가 Context.ai OAuth 접근에서 Vercel 직원의 Google Workspace 계정으로 피벗했다”, “2025년 초~중반 내부 Vercel 시스템 접근과 고객 환경 변수 열거가 시작됐다” 같은 날짜가 어디서 나온 건지 궁금함
내 보기엔 그런 날짜들은 전부 지어낸 내용이고, 아마 hallucination일 가능성이 높음
Hacker News 의견들
Vercel이 환경 변수 UI를 처음 내놨을 때는 sensitive 옵션 자체가 없었던 걸 떠올리게 됨. 그 기능이 들어오기까지 거의 2년 넘게 걸렸음. 관련 논의는 GitHub discussion과 Vercel changelog에 남아 있음
process.env에 들어간 순간, 훑어보려는 의존성이 있으면 읽을 수 있음. 진짜 문제는 모든 비밀값을 하나의 env 주머니에 몰아 넣고 빌드 도구에 통째로 넘기는 구조라고 봄. Cloudflare의 scoped bindings나 Fly는 이미 분리하고 있고, 다른 플랫폼이 느린 편이라는 판단임이런 식으로 걸린 게 정말 민망한 사고처럼 느껴짐. 인용된 내용대로라면 Lumma Stealer 감염이 Context.ai 직원의 Roblox exploit script 다운로드에서 시작됐다는 점이 특히 당황스러움
CEO가 공격자의 빠른 움직임을 AI 가속 공격 기법 때문이라고 공개적으로 돌렸다는 대목은, 내가 보기엔 근거가 거의 보이지 않음. 그래서 실질적으로 드러나는 정보도 별로 없다는 느낌임
나는 Stage 2 설명이 잘 이해되지 않았음. ContextAI 앱이 Google mail, drive, calendar 같은 권한을 다 요청했다면 너무 과하다는 생각임. 작은 회사도 아니고 이런 걸 자체 환경 밖에서 돌리는 데 동의했다는 게 믿기 어려웠음. 다만 Context.ai의 보안 업데이트 글을 보니, Vercel 직원 한 명이 개인적으로 자기 Google Workspace 전체 접근을 허용한 선택처럼 읽힘
이번 흐름이 정확히 어떻게 작동했는지 아직도 감이 잘 안 옴. 여기서 말하는 OAuth token이
Sign in with Google후 받는 토큰인지 궁금함. 보통 그건 특정 Google App의 client id와 client secret에 묶이는 것 아닌가 싶음. 공격자가 사용자 OAuth token과 client 정보까지 알아도 Drive 등에 접근하는 것까지는 이해되지만, 거기서 어떻게 Vercel의 control plane 로그인으로 이어졌는지는 납득이 잘 안 됨. 결국 Google Drive 안에서 자격 증명을 찾은 건지 궁금함“OAuth 앱을 제3자 벤더처럼 다루고, 장기 플랫폼 비밀을 없애고, provider-side compromise를 가정해 설계해야 한다”는 말에는 공감하면서도, 공급자 측 침해를 전제로 설계하는 건 정말 어렵다고 느낌. 애초에 신뢰가 시스템의 출발점이기 때문임
앞으로는 이런 사건이 훨씬 더 많이 나올 거라고 봄. 대기업이든 소규모 업체든 AI 도구를 널리 실험해 온 데 따른 리스크 부채를 이제 IT 경제 전체가 뒤늦게 맞이하는 중이라는 생각임. 그래서 이걸 “AI-enabled tradecraft”라기보다, 회사 리더십이 속도를 이유로 전사에 AI 도구 설치와 시험을 압박한 결과로 읽게 됨. 이런 공격 자체는 너무 평범하고, 강제 가능한 AI 설치 allowlist가 없는 회사라면 거의 다 노출돼 있음. Context 같은 도구들이 로컬과 SaaS 전반에서 얼마나 깔려 있는지 IT 담당자에게 물어보면 꽤 많을 가능성이 큼. 문제는 이런 도구들이 사실상 모든 것에 접근하고, 이를 통제할 보안 벤더나 RBAC 생태계는 18~24개월은 더 있어야 본격화될 거라는 점임. Vercel은 탄광의 카나리아처럼 보이고, Context만 표적이었을 리 없다고 봄. 한 곳이 터지면 다른 곳도 연쇄적으로 드러날 수 있는, 잘 알려졌지만 무시되던 위협 벡터라는 판단임. 향후 6개월이 특히 어려울 수 있고, 모두가 지금 AI 설치 현황을 감사 중이거나 감사해야 하며, 공격자도 차단되기 전에 가진 접근권으로 움직일 거라고 예상함. 참고로 나는 tech 업계의 보안 책임자임
“OAuth 신뢰 관계가 플랫폼 전체 노출로 번졌고, CEO는 공격 속도를 AI 탓으로 돌렸고, 탐지에서 공개까지의 지연도 의문”이라는 요약을 보며, 내 눈에 보이는 핵심 실패는 전형적이라고 느낌임. 과도한 권한을 가진 사용자 계정이 있었고, 비슷한 계정이 더 있었을 수도 있음. 2FA나 ZeroTrust가 없거나 매우 제한적이었을 가능성도 커 보임. 전반적인 보안 위생도 좋지 않았다는 판단임
사람들이 잘 놓치는 지점이 하나 있음. Vercel에서 환경 변수를 rotate해도 예전 배포가 자동으로 무효화되지 않아서, 이전 deploy는 재배포하거나 지우기 전까지 옛 자격 증명으로 계속 돌아감. 그래서 공지 후 키를 교체했더라도 모든 배포를 다시 올리지 않았다면 유출된 값이 여전히 살아 있을 수 있음. 그리고 Google Workspace의 OAuth 승인 내역도 꼭 확인해야 한다고 봄.
Admin Console > Security > API Controls > Third-party app access에 들어가 보면, 2년 전 데모 때문에 승인한 앱이 아직도 메일과 Drive 전체 권한을 들고 있을 가능성이 높음이 보고서에 나온 일부 세부사항, 특히 2024~2025부터 시작되는 타임라인은 다른 곳에서 널리 보도되지 않은 내용처럼 느껴졌음. 예를 들어 “2024년 말~2025년 초 공격자가 Context.ai OAuth 접근에서 Vercel 직원의 Google Workspace 계정으로 피벗했다”, “2025년 초~중반 내부 Vercel 시스템 접근과 고객 환경 변수 열거가 시작됐다” 같은 날짜가 어디서 나온 건지 궁금함