Vercels Security Dashboard är GA: gör fynd, fix och omkontroll till en verifierbar kedja

GA ger en gemensam vy – inte ett färdigt revisionsbevis

Den 26 augusti 2026 meddelade Vercel att Security Dashboard är generellt tillgänglig. Vid kontrollen den 1 september angav lanseringsposten att dashboarden ingår för alla planer. Vercel lyfter bland annat krav på tvåfaktorsautentisering för teamet, långlivade uppgifter som kan ersättas med OIDC, offentliga preview-driftsättningar och gamla miljövariabler. Det är exempel, inte en komplett katalog över vad produkten kan hitta.

En gemensam vy löser inventeringen, men inte hela ansvarsfrågan. Om en agent ändrar en inställning och fyndet sedan försvinner vet du fortfarande inte om agenten höll sig till rätt projekt, om en annan skyddsmekanism försvagades eller om applikationens funktion ändrades. Monkeybases metod är därför att frysa före- och efterläget och lägga en mänskligt godkänd diff och egna tester mellan dem.

1. Frys ett maskinläsbart föreläge

Välj först rätt Vercel-team eller scope och avgränsa till ett projekt när fyndet gäller ett projekt. Vercels dokumentation för Security Dashboard beskriver vercel security check, flaggan --project och detaljvisning av enskilda fynd med --findings. Flaggan tar inget fynd-id som argument. I en icke-interaktiv körning skrivs resultatet som JSON till standardutmatningen. Spara också den installerade CLI-versionens hjälptext, eftersom kommandon och utdataformat kan förändras.

vercel --version
vercel security check --project acme-web --findings \
  > evidence/vercel-security-before.json

Lägg en liten körningsnotering bredvid råfilen: UTC-tid, använd scope, projektidentifierare, exakt kommando och vem som körde det. Beräkna sedan en SHA-256-checksumma av JSON-filen. Checksumma bevisar inte att Vercels fynd är korrekt, men den gör det möjligt att upptäcka om föreläget redigeras i efterhand. Behåll råfilen orörd; skapa en separat arbetskopia om teamet vill sortera eller kommentera innehållet.

JSON-exemplet ska inte hårdkoda ett påstått evigt schema. Det viktiga är att din lokala logg kan peka på det verkliga fynd-id som finns i den sparade körningen. Skriv minst project, finding_id, sökvägen till råfilen och dess checksumma i protokollet. Då går det att skilja ett nytt fynd med liknande rubrik från det fynd som faktiskt triagerades.

2. Ge agenten en ändringsyta och en stoppregel

Välj ett fynd, inte ”förbättra säkerheten”. Skriv vilka filer eller inställningar som får ändras, vilka som uttryckligen ligger utanför uppdraget och vilket beteende som måste vara oförändrat. För en offentlig preview kan gränsen exempelvis vara Vercels åtkomstinställning för just projektet; för en gammal miljövariabel kan den vara ett namn i en bestämd miljö och den kodväg som läser värdet. Låt inte agenten samtidigt uppgradera beroenden, byta autentiseringslösning eller städa närliggande konfiguration.

Vercels lanseringspost beskriver att kodagenter kan arbeta med identifierade fynd. Det betyder inte att varje fynd lämpar sig för en automatisk fix. Agenten ska lämna ett förslag; en människa granskar diffen eller inställningsändringen och godkänner den innan merge eller genomförande. Den kontrollen kompletterar stoppregler i CI före merge: CI kan mäta kodens tester och bygge, medan granskningsprotokollet här binder resultatet till ett bestämt Vercel-fynd.

3. Testa det som dashboarden inte mäter

Kör tester som motsvarar den faktiska ändringen. Ett nytt previewskydd behöver åtminstone ett nekande prov utan behörighet och ett tillåtande prov med rätt behörighet. Ett byte från långlivade uppgifter till OIDC behöver visa att den avsedda arbetslasten fortfarande får åtkomst och att en oavsedd identitet nekas. En borttagen miljövariabel behöver bygge eller funktionsprov som aktiverar den berörda kodvägen. Lägg gärna dessa kontroller bredvid råresultaten i stället för att skriva ”testat manuellt”.

Vercel-kontrollen är en säkerhetssignal för plattformens fynd, inte en fullständig säkerhetsrevision eller regressionstest av applikationen. Använd därför även den bredare inventeringen i Monkeybases guide om säkerhet och dataskydd när ändringen berör hemligheter, kunddata eller agentens åtkomst. Den här nyhetens uppgift är smalare: att göra ett Vercel-fynd reproducerbart från triage till efterkontroll.

4. Kör om samma kontroll – spara efterläget separat

Kör om vercel security check med samma scope, projekt och detaljläge. Behåll förefilen och spara efterkontrollen som vercel-security-after.json tillsammans med ny UTC-tid, den CLI-version som faktiskt användes och en ny checksumma. Om CLI-versionen eller kommandot skiljer sig ska avvikelsen stå i protokollet; annars ser två olika mätningar ut som samma kontroll.

Jämför sedan identitet och status, inte bara antalet träffar. Rätt fynd ska ha försvunnit eller ändrat status enligt den godkända avsikten, och inga nya högriskfynd ska ha introducerats i samma avgränsade kontroll. De egna testerna ska fortfarande vara gröna. Först när dessa villkor håller kan loggen markera resultatet som fixed.

Dashboarden låter behöriga användare tysta fynd och dokumentationen beskriver även CSV-export. CSV är användbart för granskning, men den reproducerbara kedjan här använder rå JSON från CLI. Ett tystat fynd ska loggas som muted/accepted, med beslutsfattare, motivering och datum för ny prövning. Det är ett accepterat riskbeslut, inte en teknisk fix. Om efterkontrollen eller testerna inte håller är statusen unresolved.

Samma princip gäller när en Cursor- eller annan kodagent är del av Vercel-flödet: en fungerande produktfunktion eller publicering ersätter inte ett bevis för vad som ändrades. Den tekniska grinden före Vercel-produktion äger publiceringsbeslutet; kedjan här börjar med plattformens säkerhetsfynd och slutar först när före- och efterbeviset går att granska oberoende.