HNでこの投稿が伸びた理由は、単にVercelがbreachを確認したからではない。議論の中心はaccess pathの形だった。Vercelのofficial bulletinは、certain internal Vercel systemsへのunauthorized accessを確認し、incident response expertsを入れ、law enforcementにも通知したと説明している。影響を受けたcustomerはlimited subsetで、個別に連絡しているという。

流れを変えたのはIOCの追記だ。Vercelは、incidentがsmall, third-party AI toolのGoogle Workspace OAuth app compromiseに由来し、そのappが複数組織の数百ユーザーに影響した可能性があるとした。公開されたOAuth App client IDは110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.comである。

そのためHNの関心は「Vercelだけの事故か」から「production infrastructureがAI toolingをOAuth consentでどれだけ信頼しているのか」へ移った。Vercelはaccountとenvironmentのactivity log確認、recent deploymentsの調査、Deployment Protection tokensのrotation、そしてsensitive指定されていないenvironment variablesにAPI keys、tokens、database credentials、signing keysが入っていた場合の優先的なrotationを勧めている。sensitive environment variablesについては、読めない形で保存されており、現時点でaccessされたevidenceはないとしている。

community discussion noted that 初期のcommunicationは、operatorsがimpactを判断するには曖昧すぎるという不満を呼んだ。一方で、AI coding tools、deployment platforms、OAuth scopes、default provider choicesが作る集中度にも話が広がった。AI toolがrepoやdeploy pipelineへ近づくほど、便利さだけでなくcredentialとOAuth scopeのblast radiusも大きくなる、という読み方だ。

詳細はHN discussion、BleepingComputer report、Vercel bulletinで確認できる。

#incident

Vercel breachでHNが見た本丸は、AI tool OAuthのblast radiusだった