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

(trendmicro.com)

1P by GN⁺ 5시간전 | ★ favorite | 댓글 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영업일 공시 의무
- 기사에서는 실제 무단 접근 사용 여부를 아직 모를 수 있어도, 다수 규제 프레임워크는 악용 확인이 아니라 노출 자체를 기준으로 작동할 수 있다고 지적

침해 지표

확인된 IoC
- OAuth Client ID
  - 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
  - 손상된 Context.ai OAuth 애플리케이션과 연결된 값

▲

GN⁺ 5시간전 [-]

Hacker News 의견들

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일 가능성이 높음

답변달기

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

핵심 함의

사고 타임라인

공격 체인

1단계: 제3자 OAuth 침해

2단계: Workspace 계정 탈취

3단계: 내부 시스템 접근

4단계: 환경 변수 열거

5단계: 하류 서비스 악용 가능성

공개 시점의 9일 공백

이 9일 공백이 의미하는 것과 의미하지 않는 것

이해관계자별 시사점

AI 가속형 공격 행위

포렌식 증거에서 기대될 수 있는 징후

Vercel 사건을 넘어서는 중요성

탐지 엔지니어링 함의

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

당시 Vercel 환경 변수 동작 방식

결정적 설계 선택

Vercel 대응

업계 비교

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

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

OAuth 거버넌스는 벤더 리스크 기능

위협 행위자 주장과 귀속

ShinyHunters 연계 주장

귀속을 어렵게 하는 요소

공급망 릴리스 경로에 대한 Vercel 입장

MITRE ATT&CK 매핑

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

2026년 3월 24일: LiteLLM PyPI 공급망 침해

2026년 3월 31일: Axios npm 공급망 침해

수렴 패턴

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

Codecov Bash Uploader 침해, 2021년 1월~4월

CircleCI 보안 사고, 2023년 1월

Snowflake 고객 자격 증명 공격, 2024년 5~6월

Okta 지원 시스템 침해, 2023년 10월

패턴 요약

아직 공개되지 않은 사항

탐지 및 헌팅 가이드

Vercel 고객용 즉시 조치

노출 자격 증명의 비인가 사용 탐색

회전과 재배포 동시 필요

보안팀용 사전 대응

SIEM 탐지 로직

OAuth 애플리케이션 이상 징후, 1~2단계

내부 시스템 접근과 측면 이동, 3단계

환경 변수 열거, 4단계

하류 자격 증명 남용, 5단계

제3자 자격 증명 유출 알림

위협 헌팅 수동 절차

Google Workspace Admin Console 수동 검색

광범위 스코프 제3자 OAuth 앱 점검

방어 권고

즉시 조치, 0~48시간

단기 강화, 1~4주

구조적 변경, 1~6개월

권장 모니터링

규제 및 컴플라이언스 영향

GDPR

CCPA/CPRA

PCI DSS

SOC 2

SEC Cybersecurity Rules 8-K

침해 지표

확인된 IoC

함께 보면 좋은 글 β

Hacker News 의견들