工具与应用01
Snyk 发布了一套叫 Evo Agentic AppSec 的“安全智能体”工具，用一组 AI 代理自动完成应用安全工作的各个环节。过去，安全团队面对 AI 大量生成的代码早已不堪重负，Snyk 的数据显示每修复一个漏洞、同时会新增约八个，其中不少是传统扫描器看不清的业务逻辑和权限问题，恶意依赖包还可能在扫描前就偷走凭证。这套工具覆盖从代码开发、CI 检查到定期深度分析三个环节，把威胁评估、漏洞发现、修复和验证串起来，人只负责定策略和审批；据其 VulnBump 测试，修复代理生成的修复有 90% 可直接合并，而无上下文时只有 59.6%。对读者的意义是：这类方案试图让安全审查跟上 AI 写代码的速度，而不是靠人工事后补漏。目前原文只说了这是将进入 Evo 平台的新方案，未说明开放时间或价格。
文中可用工具
- Evo Agentic AppSec由一组安全智能体组成，自动完成应用安全评估、修复和验证等工作
- Evo Agentic Security Review评估应用的威胁与防护措施，给出有证据支撑的发现和修复建议
- Evo Code Scanning Agent发现传统扫描器漏掉的业务逻辑和授权缺陷
- Snyk Secrets检测传统与 AI 辅助开发中暴露的密钥
- Evo Remediation Agent修复新代码和积压问题，上线时先从第三方依赖问题入手
- Evo Dependency Firewall在安装阶段拦截恶意或不符合策略的软件包
- Evo Continuous Offensive Security用对抗性测试评估应用防御和修复效果
- Snyk Code提供底层代码扫描分析并独立验证发现与修复
- Snyk Open Source提供底层依赖扫描分析并独立验证发现与修复
- EvoSnyk 平台上用于保护自研应用和所部署 AI 智能体的部分
研究与技术02
AI 编程智能体在写接口时，常常只检查“用户登录了吗”，却不检查“这条数据是不是他的”。比如让它写一个按编号查发票的接口，它会验证登录、查不到就返回 404，看起来都对，但任何人只要改一下 URL 里的编号，就能看到别家公司的发票。问题在于“发票属于某个组织、用户只能看自己组织的发票”这条规则存在于产品设计里，代码和提示词里都没写，所以智能体不知道要加。这类问题叫越权访问（BOLA/IDOR），在 OWASP Top 10 中排第一，传统扫描工具因为没有固定特征可匹配，很难自动发现，目前仍主要靠懂产品的人人工审查，或在查询条件里补上组织范围来修复。
工具与应用03
安全公司 Snyk 在 2026 年 9 月 30 日宣布，Evo Agentic Development Security（Evo ADS）里的“治理 Agent 行为”功能正式可用，首个落地场景是 MCP 治理。问题在于：AI 编程助手通过 MCP（模型上下文协议）能连上数据库、内部接口等外部系统，但连了哪些服务器、是否可信，往往没人管，可能被恶意服务器偷走凭证。MCP 治理让安全团队先列出批准使用的 MCP 服务器清单，再持续监测和记录越权使用，并在 Agent 连接的那一刻本机拦截，目前已支持 Claude Code、Cursor、Codex 和 GitHub Copilot。这样安全团队不用改架构就能给 Agent 的工具调用上锁。
文中可用工具
- Evo ADSSnyk 推出的 Agentic Development Security 平台，用于控制 AI 编程 Agent 运行时能做什么，本次随行为治理功能一同可用
- MCP GovernanceEvo ADS 下的首个治理用例，可发现、批准、监控、记录并阻止 MCP 服务器使用，已正式可用
- Claude Code支持 MCP 治理本机执行的 AI 编程 Agent 之一，原文未说明具体用途细节
- Cursor支持 MCP 治理本机执行的 AI 编程 Agent 之一，原文未说明具体用途细节
- Codex支持 MCP 治理本机执行的 AI 编程 Agent 之一，原文未说明具体用途细节
- GitHub Copilot支持 MCP 治理本机执行的 AI 编程 Agent 之一，原文未说明具体用途细节
工具与应用04
这篇文章介绍了一种叫 Agentic AppSec 的新做法：让一组 AI 安全智能体来承担整个应用安全工作。背景是 AI 写代码的速度远超人工安全审核的速度，发现的问题远多于修掉的问题——据 Snyk 2026 年 6 月的数据，每修复 1 个漏洞，大约新增 6 个漏洞。做法是把安全工作拆成六个连续循环的步骤：理解应用、建立威胁模型、找出真正重要的漏洞、决定先修哪些、生成并验证修复、再独立证明修复真的有效；每个智能体只负责一件有明确触发条件和输入输出的任务。文章强调三个前提：智能体要基于共享的应用上下文模型（Snyk 称为 application-context graph），任务要有边界，验证必须由产出结果之外的东西来做，因为 LLM 单独找漏洞的结果很不稳定。对读者的意义是：这是 Snyk 提出的方法论介绍，不是可直接使用的现成产品。
文中可用工具
- Snyk VulnBench JS 1.0文中提到的基准测试用来说明 LLM 单独找漏洞的结果不稳定，原文未说明是否开放使用
- application-context graphSnyk 提出的共享应用模型，供各个智能体在行动前读取，原文未说明是否对外可用