内容归档
按栏目浏览往期内容，用关键词、分类和日期找到需要的信息。
Snyk 在旧金山举办了首届客户峰会 UNFILTERED，邀请一批安全负责人闭门坦诚讨论。大家集中聊了五个话题：AI 代写的代码出了问题该由谁负责；企业开始追问 AI 的投入回报和预算上限，不再只看成本；找出漏洞不再是难点，难点是修得快、少靠人；AI 让每个人都能写代码，风险来源也变多了；人能审核的数量有限，愿意信任自动代理，但前提是代理绕不过控制。这次峰会是闭门讨论，不发布产品；次日 Snyk 才推出 Evo Agentic AppSec 并举办 AI 安全峰会。
提供的材料未提及具体可用工具。
安全公司 Snyk 回顾了 PHP 引擎两个严重漏洞（PHP2Shell）的应对过程。问题出在代码之下：漏洞位于 PHP 引擎处理请求的环节，应用代码还没开始运行就可能被利用，所以即使代码写得干净也挡不住。攻击者只需发一个无需登录的请求，而很多团队根本说不清 PHP 到底跑在哪些对外地址上。Snyk 的做法是先盘点外部可见资产、标出用 PHP 的主机，再上线针对性检测，打补丁后重测确认修复生效。对普通读者的意义是：漏洞从公开到被大规模利用只有几天，提前摸清自己对外暴露了什么，比事后临时找要快得多。文中提到 VirusTotal 指纹识别约 510 万个运行 PHP 的 IP，其中只有约 110 万主动暴露版本号。
Snyk 推出了 Evo Remediation Agent 的开放预览版，它能自动处理开源依赖漏洞：按团队设定的仓库范围和严重级别，智能体在托管沙箱里制定升级方案、修改代码，并用构建、测试和重新扫描验证结果，然后给开发者开拉取请求，由开发者决定是否合并。这解决的是漏洞修不完、和开发日常工作抢时间的问题。官方在 307 个依赖升级任务上测试，该工具四项检查全部通过的比率为 90.2%，而配合 Snyk 发现结果的 Claude Code 为 77.5%，单用 Claude Code 为 59.6%。目前只是开放预览，需申请租户权限，有每日修复额度限制，且仅支持开源漏洞，智能体不会自动合并。
PHP 项目在 2026 年 10 月 21 日发布了 8.5.12、8.4.27、8.3.36、8.2.35 四个版本，修复两个严重漏洞：攻击者不需要登录、也不用任何账号，只要发送恶意网页请求，就可能直接在服务器上运行自己的代码，危害极大。问题出在 PHP 引擎处理请求的流程里，而不是某个第三方包，所以升级 PHP 本身才是解决之道。官方说没有完全规避的办法，唯一安全的选择就是升级；如果仍用 8.1 或更早版本，需要找系统发行版或长期支持厂商拿回补丁，或者直接升级。另外 10 月 23 日补充了一个编号 CVE-2026-115560 的变体绕过问题，只有应用在运行时动态切换 session 序列化方式才可能受影响，普通部署可以暂时不用紧张。读者应尽快确认每台机器实际运行的 PHP 版本，不要只看扫描结果。
提供的材料未提及具体可用工具。
安全公司 Snyk 在旧金山 AISS 大会前一天办了一场圆桌讨论，请来 OpenAI、Google 威胁情报团队、风投机构和 Snyk 的四位安全负责人聊 AI 安全。原来大家早就积累了不少安全隐患，只是以前攻击成本高、没被利用；现在 AI 让攻击变得又便宜又快，等于把这些旧账一次性催收。讨论指出，找漏洞越来越容易，真正卡住人的是修复速度，所以防守方需要让机器承担大部分修复工作，并配合身份、权限和意图管控。文章还提到一个案例：有人用开源 AI 渗透测试工具攻击了至少九家韩国银行；另有研究发现，扫描的 3,984 个智能体技能中至少 36.82% 存在安全缺陷。这些是会上讨论的观点和案例，不代表已有现成方案落地。
安全公司 Snyk 扫描了上千个企业环境中的 AI 模型，发现近一半环境引用了可能在某种攻击下得分达到严重级别的模型。但作者强调，光看模型分数不够：同一个模型，如果只用来总结会议记录，和用来查询客户数据、触发业务流程，出事的后果完全不同。所以团队应先确认模型是否真的在运行、它能访问哪些数据和工具，再针对具体风险选择换模型或加访问限制、人工审批等控制措施。这项研究来自 Snyk 报告，其中模型分数基于模拟攻击测试，并不代表真实入侵已经发生。
提供的材料未提及具体可用工具。
Snyk 发布了一个叫 VulnBump 的新测试基准，用来考察 AI 智能体能不能把项目里有漏洞的第三方依赖升级到安全版本。以前升级依赖很难：多数有漏洞的包是被间接引入的，约四分之一修复需要跨大版本，连小版本升级也常导致构建失败，所以虽然 94% 的漏洞都有已知修复版本，实际只有约 10% 被解决。VulnBump 用 307 个真实升级任务来考智能体，只有漏洞消失、项目仍能安装、构建并通过测试才算通过。结果显示：同一个 Claude Sonnet 5.5 模型，配上 Snyk 数据后通过率能提高约 18 个百分点，而 Snyk 专用智能体通过率达到 90.2%。对开发者的用处是：想安全修漏洞，光靠通用 AI 不够，还要有准确的升级建议和扫描验证。
Snyk 发布了一套叫 Evo Agentic AppSec 的“安全智能体”工具，用一组 AI 代理自动完成应用安全工作的各个环节。过去，安全团队面对 AI 大量生成的代码早已不堪重负，Snyk 的数据显示每修复一个漏洞、同时会新增约八个，其中不少是传统扫描器看不清的业务逻辑和权限问题，恶意依赖包还可能在扫描前就偷走凭证。这套工具覆盖从代码开发、CI 检查到定期深度分析三个环节，把威胁评估、漏洞发现、修复和验证串起来，人只负责定策略和审批；据其 VulnBump 测试，修复代理生成的修复有 90% 可直接合并，而无上下文时只有 59.6%。对读者的意义是：这类方案试图让安全审查跟上 AI 写代码的速度，而不是靠人工事后补漏。目前原文只说了这是将进入 Evo 平台的新方案，未说明开放时间或价格。
Snyk 首席创新官 Manoj Nair 与 Anthropic 应用 AI 负责人 Alon Krifcher 在一场线上活动中讨论：攻击者已经开始用 AI 智能体自动发起攻击，防御窗口从几个月缩短到几分钟甚至 27 秒。Snyk 提出用「发现 → 修复 → 验证 → 预防」四步并行应对，并称其产品 Evo 和 Snyk Studio 已在实际企业中使用，例如有客户靠它发现了人工渗透测试漏掉的问题。对读者的意义是：可以关注一个简单指标——新发现的问题与已关闭问题的比例，它比开了多少工单更能说明安全状况是否真的在改善。
有人拿同一个漏洞百出的网站做测试，一边用 Evo COS 这种直接去打活网址的工具，一边用 Claude Security 这种只读代码找漏洞的工具。结果 Evo COS 能证明 15 条攻击链里的 10 条确实能打通，比如先利用一个漏洞拿到签名密钥，再用它伪造管理员身份接管后台；而只读代码的模型虽然也能发现同样的两个漏洞，却无法证明它们能被串起来真正攻破系统。这说明看代码和打活系统是互补的两件事，想真正评估风险，两边的活都得干。
AI 编程智能体在写接口时，常常只检查“用户登录了吗”，却不检查“这条数据是不是他的”。比如让它写一个按编号查发票的接口，它会验证登录、查不到就返回 404，看起来都对，但任何人只要改一下 URL 里的编号，就能看到别家公司的发票。问题在于“发票属于某个组织、用户只能看自己组织的发票”这条规则存在于产品设计里，代码和提示词里都没写，所以智能体不知道要加。这类问题叫越权访问（BOLA/IDOR），在 OWASP Top 10 中排第一，传统扫描工具因为没有固定特征可匹配，很难自动发现，目前仍主要靠懂产品的人人工审查，或在查询条件里补上组织范围来修复。
提供的材料未提及具体可用工具。