---
title: "Security Review"
description: "基於 Cursor 官方 Security Review 文件解釋 PR 安全審查、Vulnerability Scanner、Automations、MCP、計費和 analytics。"
verifiedAt: "2026-05-09"
---

Security Review agents 用來掃描程式碼中的安全 bug、風險模式和漏洞。

> [!NOTE]
> **閱讀目標**：讀完本章，你應該能區分 PR 級 Security Review 和 codebase 級 Vulnerability Scanner，並能判斷它們是否適合接入團隊安全流程。

## 1. 先判斷

Security Review 不是普通程式碼風格 review。它面向安全問題，當前只面向 Teams 和 Enterprise plans。

官方定義了兩類 Cursor-managed agent：

| Agent | 觸發位置 | 用途 |
| --- | --- | --- |
| Security Review | PR / merge request 等 Git-based Automations triggers | 在程式碼合併前抓漏洞和風險模式 |
| Vulnerability Scanner | cron-based triggers | 掃描靜態 codebase，找歷史遺留漏洞和 PR review 漏掉的問題 |

兩者都執行在 Automations platform 上，並且依賴 Cloud Agents。也就是說，它們繼承 Cloud Agent 的環境、許可權、工具、MCP、計費和執行證據。

## 2. 工作方式

Security Review 的完整鏈路是：

```mermaid
flowchart TD
  Config["Security Review Dashboard"] --> Agent["Security Review / Vulnerability Scanner"]
  Agent --> Trigger["Git-based trigger or cron trigger"]
  Trigger --> Cloud["Cloud Agent run"]
  Cloud --> Checks["Built-in security checks"]
  Cloud --> Tools["Tools and MCPs"]
  Tools --> Tracker["Slack / issue tracker / connected system"]
  Cloud --> RunHistory["Dashboard run history"]
  RunHistory --> Analytics["Found / fixed / resolution rate"]
```

你不是在配置一個“提醒機器人”，而是在配置一條安全檢查流水線。它要能知道什麼時候執行、查什麼、查到後發到哪裡、誰負責修、修完後如何統計。

## 3. 配置入口

到 [Security Review Dashboard](https://cursor.com/dashboard/security-review) 建立第一個 agent。

配置時至少決定：

| 配置項 | 決策 |
| --- | --- |
| Agent type | PR 前檢查還是週期性漏洞掃描 |
| Trigger | Git-based event 或 cron schedule |
| Security checks | 哪些內建檢查開啟，哪些關閉 |
| Custom instructions | 專案安全要求、優先順序、輸出規則 |
| Tools / MCPs | 發現問題後寫入哪裡、讀取哪些上下文 |
| Environment | 使用 Cursor cloud，還是 self-hosted Cloud Agents |

Security Review agents 支援 pull request 和 merge request 等 Git-based Automations triggers。Vulnerability Scanner 支援 cron-based triggers，可以脫離 PR 活動週期性掃描。

## 4. Checks 和 instructions

內建 security checks 不是越多越好。上線時要把它們對映到團隊真實風險：

| 風險型別 | instructions 應該說明 |
| --- | --- |
| 認證授權 | 哪些路徑、角色、tenant、許可權邊界最敏感 |
| 輸入處理 | 哪些入口需要校驗、轉義、schema 或 allowlist |
| 金鑰洩露 | 哪些目錄禁止憑據、token、私鑰和 debug dump |
| 資料訪問 | 哪些模型、表、bucket、第三方 API 涉及客戶資料 |
| 供應鏈 | 哪些依賴變更需要額外審查 |

Custom instructions 要寫專案特定語境，而不是重複“請檢查安全問題”。例如：支付、登入、後臺管理、檔案上傳、webhook、AI tool calling、跨租戶資料訪問，都應該明確告訴 agent 優先看。

## 5. Tools 和 MCPs

官方要求每個 Security Review agent 至少配置一個 tool 或 MCP 才能執行。

Tools / MCPs 的價值是把安全發現接入團隊的真實工作系統：

- 傳送漏洞到 Slack 安全頻道。
- 建立或更新 issue tracker。
- 從內部系統讀取更多上下文。
- 根據 custom instructions 判斷何時使用某個 MCP。
- 在報告 finding 前補充證據。

注意：MCP 會擴大 agent 的能力邊界。只連線安全審查真正需要的 MCP，並在 instructions 裡說明什麼時候可以用、輸出到哪裡、哪些資訊不能洩露。

## 6. 環境和自託管

Security Review agents 執行在 Cloud Agents 上。你可以直接使用 Cursor cloud，也可以配置 self-hosted Cloud Agents，讓 review 在自己的基礎設施中執行。

選擇時看這幾個問題：

| 問題 | 傾向 |
| --- | --- |
| 程式碼和依賴能在 Cursor cloud VM 中測試 | Cursor cloud |
| 需要訪問內網服務、私有 registry、專用 scanner | Self-hosted Pool |
| 有嚴格網路和資料邊界要求 | Self-hosted Pool |
| 只做輕量 PR 風險檢查 | Cursor cloud 可能足夠 |

不管選擇哪種環境，都要提前配好 secrets、egress、依賴安裝和 repo 規則。安全 agent 如果跑不起來，等同於沒有安全檢查。

## 7. Billing 和身份

Security Review 按 team usage level 計費：

- usage 進入團隊 usage pool。
- agent runs 使用 shared team service account。
- 不影響某個 individual user's usage。

這對團隊治理很關鍵：它應該按團隊安全能力計費和審計，而不是落到某個成員個人額度裡。

## 8. Analytics 和 run history

Security Review tracking 三類核心指標：

| Metric | 含義 |
| --- | --- |
| Vulnerabilities found | agent 報告的安全 finding 數 |
| Issues fixed | 報告後被修復的 finding 數 |
| Resolution rate | reported findings 中被修復的比例 |

Cursor 會使用 LLMs review incremental diffs 來判斷 flagged issue 是否已被修復。

每個 agent run 都會進入 dashboard run history。開啟 run 可以看執行時間、使用了哪些 tools、最終狀態，以及底層 Cloud Agent 做了什麼。

上線後不要只看“跑了多少次”。更重要的是 false positive、平均修復時長、重複問題、未修復 finding 和哪個 repo 風險最高。

## 9. 商業級上線清單

上線前至少確認：

- Security Review 只啟用在 Teams / Enterprise 可用範圍內。
- PR 檢查和週期掃描分成兩個 agent，不混成一個模糊任務。
- 每個 agent 至少有一個 tool 或 MCP。
- Custom instructions 明確專案高風險路徑。
- findings 進入明確的 Slack / issue tracker / 安全看板。
- 自託管或雲端環境已經能 clone、install、scan 和產出結果。
- team usage pool、service account 和許可權審計清楚。
- run history 和 analytics 能被安全負責人定期覆盤。

<details>
<summary>深讀：Security Review 應該補團隊盲區，而不是替代安全流程</summary>

它適合持續掃 PR 和歷史 codebase，降低重複人工審查成本。但高風險系統仍要保留 threat modeling、依賴掃描、SAST/DAST、人工安全評審和上線審批。Cursor 的價值是把這些檢查接到 Cloud Agent 工作流裡，而不是讓一個 agent 獨自決定是否安全。
</details>

## 本章自檢

1. PR 前檢查和週期性 Vulnerability Scanner 是否分開配置？
2. 每個 agent 的 trigger、tool / MCP、custom instructions 是否明確？
3. findings 是否進入團隊真實追蹤系統？
4. analytics 是否能衡量 fixed rate，而不只是發現數量？

透過標準：你能建立一條 Security Review 自動化，並能說明它查什麼、何時查、在哪裡執行、如何報告、誰修復、如何覆盤。

## 官方來源

- [Cursor Security Review](https://cursor.com/docs/security-review.md) —— 官方 Security Review、Vulnerability Scanner、setup、triggers、tools、billing、analytics 和 runs。
- [Cursor Automations](https://cursor.com/docs/cloud-agent/automations.md) —— 官方 Automations trigger、tool、permission 和 billing。
- [Cursor Self-Hosted Pool](https://cursor.com/docs/cloud-agent/self-hosted-pool.md) —— 官方自託管 Cloud Agents。

## 接下來去哪

<Cards>
  <Card title="Automations" description="繼續學習觸發器、工具、許可權和自動化提示詞。" href="/zh-Hant/docs/cursor/official/04-cloud-agents/57-automations" />
  <Card title="Bugbot" description="回看自動 PR review、rules 和 autofix。" href="/zh-Hant/docs/cursor/official/04-cloud-agents/55-bugbot" />
</Cards>
