Vercel 在 2026 年 11 月 2 日宣布 Security Review 公開測試，11 月 3 日再於 changelog 補充觸發、CLI 與計費資訊。這項功能屬於 Vercel Agent，開放給 Pro 與 Enterprise team；啟用後，連結 GitHub 的指定專案每次收到 push 都會檢查變更程式碼，不只涵蓋 pull request，也包含直接推到 production branch 的 commit。

它不是網站滲透測試，也不能取代人工資安稽核。官方文件明確說明，Security Review 分析的是 source code，不會測試正在執行的應用、網路設定或實際權限。導入時應把它定位成持續程式碼審查的一層，而不是「開啟後就能證明網站安全」。

每次 push 的檢查，與傳統 SAST 有什麼差別

Security Review 會以目前變更和基準版本比較，再讀取周邊程式碼，尋找注入、缺少授權檢查或憑證曝露等問題。部署型 review 以分支前一次 deployment 為基準；monorepo 則依 Vercel project 的 root directory 分開處理。第一次沒有基準時，才可能讀取完整 source。

這種 change-based 模式適合在開發流程中快速找出新引入的風險，也能透過 team 或 project 的自然語言 security policy 加入業務規則，例如「回傳訂單前必須驗證使用者屬於同一組織」。但它仍可能漏掉只在跨服務、執行環境或特殊資料狀態下發生的問題，也可能把預期行為判成弱點。傳統依規則與資料流分析的 SAST、dependency scanning、secret scanning、人工威脅建模與 runtime 測試，仍處理不同風險面。

先看觸發範圍、資料可見性與費用

Vercel 文件指出，review 依 Git push event 觸發，成本會隨 push 頻率與程式碼變更量增加。以 2026 年 11 月 4 日查核的公開測試資訊，模型推論依 provider token rate 計費，另加每百萬 token 0.25 美元的 Vercel Token Rate；security review 免費期只到 11 月 10 日，使用 Vercel Agent 修復則另依 Agent rate 計費。正式導入前要重新查價，不能把測試期免費當成長期方案。

隱私面也不能略過。finding 會包含 source snippet，可能帶有機密、個資或敏感商業邏輯。Vulnerabilities dashboard 中不同 team role 的可見範圍不同；私有或 internal repository 的 finding 也可能出現在 PR comment，能讀取該 repository 的人就可能看到。公開 repository 只會顯示 check 與 dashboard 連結，官方說明 finding 細節留在 dashboard，避免直接公開尚未修補的弱點。

因此，不應第一天就對所有專案開啟。先列出 repository、Vercel project、資料敏感度、推送頻率、目前 scanner 與 incident owner，再挑一個低風險、測試完整的專案試行。monorepo 還要確認 root directory 是否真的形成安全邊界，避免團隊以為某專案只掃自己的程式，實際上共用套件又落在其他範圍。

一個可驗收的兩週試行方式

第一步，保留現有 branch protection、dependency scanner、secret scanner 與人工 review，不因啟用新工具而移除。把 Security Review 限定到一至三個 project，記錄啟用時間、Vercel CLI 版本、policy 內容與負責人。若要從終端取得 finding，官方 changelog 指定需使用 Vercel CLI 65.10.0 或更新版本。

第二步，準備可安全提交的測試變更，例如測試用 endpoint 少一層 ownership check、將假 token 放入 fixture，或在測試環境製造一個可辨識的輸入驗證缺口。不要把真實密鑰提交進 repository。記錄工具是否發現、嚴重度是否合理、建議修法是否保留既有授權邏輯，以及從 push 到 finding 出現所需時間。

第三步，建立 triage 規則。每個 finding 至少要有狀態、owner、受影響環境、驗證證據與處置期限。dismiss 不能只寫「誤判」，應留下無法被利用的原因與可重現測試；接受 Agent 產生的修補，也必須走既有 PR review、測試與部署流程。官方說明是修補不會自動 merge，但「需要人批准」不等於批准者可以跳過差異檢查。

第四步，計算兩週內的 push 數、finding 數、有效問題、誤判、重複問題、人工處理時間與 token 費用。若開發者習慣把每個小修改都 push，計費和噪音可能高於以 pull request 為單位的工具。可以比較三種方案：全面每 push 掃描、只對高風險 project 啟用，或保留既有 scanner 並在 release 前安排人工安全 review。

怎麼做選擇

已經使用 Vercel、repository 連結完整，且缺少持續安全審查的小型團隊，可以把公開測試當成補上授權邏輯檢查的機會；先從少量 project 開始，最容易看清工具價值。受高度監管、source code 可見性要求嚴格，或已有成熟 SAST 與 AppSec 流程的組織，則應先完成資料處理、角色權限、audit log 與供應商審查，再決定是否導入。

真正的驗收標準不是 dashboard 多了一個綠色 check，而是有效弱點能否被發現、修補能否通過測試、誤判是否可管理，以及停用工具後原本的安全控制仍然成立。Security Review 可以縮短回饋時間，但安全責任、風險接受與上線決策仍必須由團隊明確擁有。