Ruotare, Ridistribuire, Revocare: la risposta di webvise alla violazione Vercel

Il 19 aprile 2026, Vercel ha reso pubblico un incidente di sicurezza riconducibile a un'applicazione OAuth di terze parti compromessa all'interno del Google Workspace aziendale. La risposta è stata avviata su ogni progetto Vercel gestito da webvise prima della fine del weekend, e i log di audit sia su Vercel sia sui Google Workspace amministrati sono risultati puliti. Non si trattava di una vulnerabilità nel codice proprietario di Vercel. È stata una compromissione della catena di fiducia SaaS-to-SaaS attraverso un confine OAuth, e la natura dell'attacco cambia l'aspetto di una risposta adeguata.

Ruotare i segreti nella dashboard di Vercel copre forse metà della risposta. L'altra metà si trova in Google Workspace, e la maggior parte degli articoli sull'argomento non la affronta.

Dopo aver letto la comunicazione e aver cambiato ogni chiave disponibile, il primo passo era corretto. Questo articolo descrive cosa è stato eseguito concretamente dall'inizio alla fine, il dettaglio tecnico che rende la rotazione rilevante per le funzioni in esecuzione, e perché la natura di questa violazione deve cambiare l'aspetto del piano di risposta per il futuro.

• La rotazione delle variabili d'ambiente in Vercel aggiorna la configurazione, non le istanze delle funzioni in esecuzione: è necessario un nuovo deploy per propagare i valori. I valori diventano effettivi solo alla distribuzione successiva.
• L'audit OAuth in Google Workspace è la metà che viene quasi sempre ignorata. È la catena di fiducia SaaS-to-SaaS che l'attaccante ha sfruttato per raggiungere Vercel.
• Non si trattava di una vulnerabilità in Vercel. È stata una compromissione SaaS-to-SaaS tramite un'autorizzazione OAuth, e una risposta standard da CVE non chiude il cerchio.
• Sul lungo periodo, portare i segreti fuori dalle variabili d'ambiente e in un secret manager a runtime. Richiedere MFA resistente al phishing per chiunque possa installare applicazioni OAuth.
• Audit mensili delle autorizzazioni OAuth nel proprio identity provider diventano ora parte della baseline, non un upgrade di maturità.

Cosa ha effettivamente comunicato Vercel

In sintesi: un'applicazione SaaS di terze parti con accesso OAuth all'interno del Google Workspace di Vercel è stata compromessa, e l'attaccante ha sfruttato quel confine di fiducia per raggiungere i valori delle variabili d'ambiente in un sottoinsieme di progetti cliente. Vercel ha pubblicato un OAuth client ID come indicatore di compromissione e ha chiesto a ogni cliente di ruotare qualsiasi segreto memorizzato come variabile d'ambiente. Nulla di tutto ciò ha riguardato una vulnerabilità nel codice proprietario di Vercel. La superficie d'attacco era il grafo di fiducia identitaria tra due strumenti SaaS.

Questo è rilevante per la risposta. Se la vulnerabilità è nel codice della piattaforma, si applica la patch, si ruota ciò che è trapelato e si va avanti. Se la vulnerabilità è nella catena di fiducia tra piattaforme, la rotazione è necessaria ma non chiude il buco. Occorre anche revocare l'autorizzazione su cui l'attaccante ha fatto leva, altrimenti la successiva compromissione dello stesso strumento ripete lo stesso raggio d'azione.

Per una seconda revisione della configurazione Vercel prima del prossimo incidente, webvise esegue security review su team Vercel, Google Workspace e autorizzazioni SaaS-to-SaaS.

Primo passo: ruotare i segreti che contano davvero

Ogni variabile d'ambiente in grado di concedere accesso a qualcosa è stata trattata come compromessa per definizione. È l'assunzione che la comunicazione richiede. Di seguito le categorie di segreti riemessi sui progetti gestiti.

• Credenziali del database. Stringhe di connessione, password per le repliche in sola lettura e chiavi di ruolo admin-tier su ogni progetto con un backend di database.
• Chiavi API Resend per le email transazionali su ogni progetto che invia messaggi di verifica, notifica o registrazione.
• Credenziali Google API per le integrazioni con Workspace, Calendar, Drive e Analytics eseguite lato server.
• Chiavi AI Gateway, inclusi token di accesso ai modelli, credenziali dei provider e token di rate-limit per tutto ciò che transita attraverso il gateway.
• Credenziali di integrazione ingest per endpoint webhook, pipeline di eventi e qualsiasi elemento che importa dati nel progetto dall'esterno.

Due categorie meritano un controllo aggiuntivo: le variabili che terminano in `_URL` e incorporano credenziali nelle stringhe di connessione, e quelle etichettate `_TEST` o `_DEV` che in realtà puntano alla produzione. Vanno ruotate insieme alle altre. Un attaccante che legge le variabili d'ambiente non si preoccupa del flag scelto né di ciò che il nome della variabile suggerisce.

Secondo passo: ridistribuire (il dettaglio tecnico che rende reale la rotazione)

Questo è il passaggio che la maggior parte delle checklist di risposta tratta in modo insufficiente. Vercel applica le modifiche alle variabili d'ambiente al momento della build e del deploy, non a runtime. Un progetto aggiornato e lasciato in esecuzione continua a girare sulla build distribuita il giorno prima, con il vecchio segreto ancora incorporato nel suo runtime. Si è ruotata la dashboard, non il sistema.

Un esempio concreto: si ruota la chiave API Resend alle 10:14 e si apre un nuovo tab per verificare qualcos'altro. Una funzione tenta di inviare un'email di verifica alle 10:17, chiama Resend con la vecchia chiave ancora incorporata nel deploy in esecuzione, e Resend rifiuta la richiesta. L'utente non riceve la sua email. Questo scenario si moltiplica per ogni funzione, ogni cron e ogni webhook handler che esegue la build precedente.

Per verificare la risposta, aprire il tab Deployments su ogni progetto e trovare un deployment con timestamp successivo alla rotazione. Se la riga in cima mostra un timestamp precedente al momento della rotazione, questa non è entrata in alcun processo in esecuzione. Il secondo passo esplicito della risposta è stato un redeploy forzato in produzione su ogni progetto gestito dopo la rotazione, prima di procedere.

Terzo passo: revocare l'autorizzazione OAuth in Google Workspace

Questa è la metà della risposta che ha ricevuto pochissima attenzione nei thread del weekend. L'incidente ha avuto origine in Google Workspace. L'attaccante è entrato tramite un'applicazione OAuth di terze parti con un ambito autorizzato all'interno di Workspace, per poi spostarsi su Vercel attraverso una catena di fiducia SaaS-to-SaaS. Chi ha ruotato solo sul lato Vercel lascia la stessa applicazione OAuth in posizione, con lo stesso ambito, pronta a essere sfruttata la prossima volta che viene compromessa.

Il percorso nella console di amministrazione: admin.google.com, sicurezza, controlli API, controllo accesso alle app, app di terze parti. Cercare l'OAuth client ID pubblicato da Vercel come indicatore di compromissione. Se presente, revocarlo. Poi fare la cosa più difficile: esaminare ogni altra autorizzazione OAuth nell'elenco, confermare che ogni ambito fosse intenzionale e revocare tutto ciò per cui non esiste una ragione attiva di mantenimento.

Questo audit è stato eseguito su ogni Workspace amministrato. L'indicatore non era presente, e la maggior parte delle autorizzazioni aveva una finalità aziendale legittima. Alcune non ce l'avevano, e sono state revocate. Da allora si è adottata una cadenza mensile: audit delle autorizzazioni OAuth all'inizio di ogni mese, revoca di tutto ciò che non è stato usato negli ultimi 30 giorni.

Quarto passo: le misure a lungo termine

La rotazione e la revoca hanno gestito l'esposizione immediata. Le misure più durature sono quelle che impediscono al prossimo incidente di diventare un'emergenza da weekend. Vengono introdotte sui progetti gestiti nelle prossime settimane, e sono ciò che si raccomanda a qualsiasi team che gestisce uno stack con molti strumenti SaaS.

• Prelevare i segreti a runtime da un secret manager invece di incorporarli nelle variabili d'ambiente. La rotazione diventa un'operazione di push, non di redeploy.
• Credenziali a breve durata per database e API ovunque il provider le supporti. Validità di minuti, non di mesi.
• Rotazione programmata per le credenziali che non possono essere rese a breve durata. Guidata dal calendario, non dagli incidenti.
• MFA resistente al phishing su ogni account admin che può installare applicazioni OAuth nel proprio identity provider. Passkey o token hardware, niente SMS.
• Audit mensili delle autorizzazioni OAuth in Workspace, Microsoft 365 o qualsiasi identity provider in uso. La catena di fiducia OAuth è stata il vettore d'attacco questa volta; lo sarà anche la prossima.

Molti team non hanno un responsabile nominato per queste attività; questa lacuna si ripresenta regolarmente nei post-mortem degli incidenti. Si prenda contatto per scoprire come webvise integra queste attività nel supporto di manutenzione per i progetti gestiti.

Perché questa violazione è diversa

Il modello difensivo deve corrispondere al modello d'attacco. Ciò significa trattare le autorizzazioni OAuth come dipendenze di produzione, sottoporle ad audit periodico e spostare i segreti fuori dalle variabili d'ambiente, dove un attaccante con quell'autorizzazione può leggerli. I log di audit di questo weekend sono risultati puliti: un risultato concreto di questo incidente, mentre il modello di risposta richiede comunque revisioni pianificate.

Un attaccante compromette uno strumento SaaS autorizzato dal team, poi sfrutta la relazione di fiducia tra quello strumento e gli altri strumenti SaaS per raggiungere dati che nessuno dei due avrebbe condiviso con uno sconosciuto. L'account Vercel non è stato violato direttamente, né il Google Workspace. Uno strumento di terze parti collegato mesi prima è stato compromesso, e gli ambiti concessi a quello strumento hanno propagato la violazione a valle.

Va trattato come un ritmo operativo, non come una pulizia una tantum.

Le security review su team Vercel, Google Workspace e grafi di identità SaaS-to-SaaS fanno parte di ogni ingaggio gestito da webvise. Per una seconda revisione della configurazione Vercel prima del prossimo incidente, si prenda contatto.