跳到主要内容

​
此工作流的意义

大多数团队并非难以检测安全漏洞。他们难以跟上修复的步伐。
  • 警报堆积如山
  • 关键问题迟迟未解决
  • 修复工作因功能开发而推迟
  • 安全工作变得被动而非例行
本指南将展示团队如何使用云代理自动修复 Snyk 的高危及严重漏洞，而不会引入风险或失去控制。
适用人群：没有专门的 AppSec 或 DevOps 职能，但仍需安全交付的全栈团队。

​
核心问题

信号过载

Snyk 发现真实问题，但团队无法跟上分类和修复的步伐。

上下文切换

安全工作会打断功能交付并分散注意力。

手动繁琐

许多修复工作是重复的、低风险的，但仍需手动处理。
风险不在于漏洞的存在。风险在于已知的严重问题仍未修复。

​
为何使用代理？(对比 Snyk 的原生自动 PR)

Snyk 拥有出色的“自动修复”功能，可以打开 PR 来升级易受攻击的依赖项。然而，由于 Snyk 无法运行您应用程序的构建或测试套件，这些 PR 通常会破坏构建并需要人工清理。 Continue 的云代理位于 Snyk 之上，以完成工程工作：
功能Snyk 原生自动 PRContinue 云代理
修复方案“将 lodash 升级到 v4.17.21”“分析安全问题并创建包含修复的 PR”
上下文漏洞数据库漏洞数据库 + 安全影响分析
智能确定性（总是升级版本）推理：“分析依赖项风险”并建议更新
结果可能破坏构建的 PR一个绿色且可合并的 PR
Snyk 告诉您要升级什么。云代理完成工程工作以确保升级安全。

​
云代理有何作用？

Snyk 修复云代理负责安全问题的处理，但不是最终决定。

输入

  • Snyk 的高危及严重漏洞事件
  • 仓库上下文
  • 依赖图和版本约束

输出

  • 包含修复的草稿或就绪 PR
  • 清晰的风险和修复摘要
代理不会悄无声息地更改生产代码。它会生成可审查的安全 PR。

​
工作流如何运行

1

触发

Snyk 检测到新的高危或严重漏洞
（事件驱动）或在预定扫描期间。
2

调查

代理调查
  • 易受攻击的依赖项
  • 可用的修复路径
  • 破坏性变更风险
3

提出修复方案

代理
  • 应用最小安全更新
  • 避免不必要的重构
  • 保留现有行为
4

打开 PR

创建包含以下内容的 PR
  • 清晰的标题
  • 漏洞摘要
  • 修复说明
5

人工审查

开发人员审查并合并（或调整）修复。

​
代理配置

Continue 的 Snyk 云代理由这些核心组件构建而成

触发器

Webhook：Snyk 新漏洞事件

工具（MCP）

Snyk MCP：获取漏洞详情

规则

GitHub CLI：告诉代理如何创建 PR
修复提示
A new Snyk vulnerability has been detected. Please investigate and resolve the issue. This should include the following steps:

**Step 1: Investigate the Issue**
Make sure you understand the vulnerability, the options for resolution, and what their consequences are.

**Step 2: Implement Fix**
- Focus on fixing the immediate issue identified
- Avoid overdoing it with error handling, cleaning up other problems, etc.
- Avoid making breaking changes
- Ensure the solution is robust and follows best practices.

**Step 3: Create Draft Pull Request**
Create a draft pull request with the following structure:

--
**PR Title:** [Snyk] <brief description of issue solved>

## Issue

**Snyk Link:** [<shortId>](<permalink>)
**Issue Type:** `<issue type>`
**Priority:** <priority>
**Summary:** <Two sentence summary of what caused the issue and how it was fixed>

​
治理：如何确保安全

​
它取代了什么（以及没有取代什么）

  • 手动依赖项升级 PR
  • 重复的漏洞分类
  • 持续打断功能交付的安全工作
  • 安全设计审查
  • 架构威胁建模
  • 关于重大升级或破坏性变更的决策

​
为何选择云代理（而非仅 CI 或脚本）进行自动化安全修复

为什么不只用 CI？

CI 可以检测漏洞，
但它无法推理修复方案或提出补丁。

云代理为何有效

云代理
  • 解读 Snyk 发现
  • 选择合适的修复方案
  • 生成开发人员可以审查的 PR
CI 执行。云代理响应。

​
团队获得的安全效益

更快的修复

严重问题提前几天或几周得到修复。

更少的中断

开发人员审查 PR，而不是上下文切换进行分类。

安全即卫生

漏洞不再堆积如山，成为例行维护。

​
一个好的初始设置

  • 仅限高危及严重漏洞
  • 一个仓库或服务
  • 仅 PR（不直接合并）
  • 合并前需要 CI
  • 指定审查所有者

​
它在更大格局中的位置

此工作流通常是一个团队的第一个成功云代理，因为
  • 投资回报立竿见影
  • 风险有界
  • 输出可审查
  • 领导层已经关注这个问题
一旦此方案奏效，团队通常会扩展到
  • 错误修复
  • 依赖项维护
  • 操作清理

​
下一步

Snyk 集成文档

更多关于 Continue Snyk 集成以及如何立即开始的信息。

添加 Snyk 集成

通过将 Snyk 集成添加到您的项目来开始。

​
值得记住的一句话

云代理将安全修复从中断变为例行维护。