---
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="/docs/cursor/official/04-cloud-agents/57-automations" />
  <Card title="Bugbot" description="回看自动 PR review、rules 和 autofix。" href="/docs/cursor/official/04-cloud-agents/55-bugbot" />
</Cards>
