洞源实验室 | 网络安全实践与AI安全探索

大模型安全、Agent安全，到Prompt Injection、AI红队等AI for Security的话题，都是围绕AI讨论涉及技术、产品和安全工作的变化。这当然是当下安全工作热门的话题和关注的对象，但在这些话题之外，笔者想聊聊安全BP（Security Business Partner），技术的发展带来了新的风险和工具，企业内部的协作却面临着一个基础问题：安全部门与业务部门之间，应该建立什么

本文综合整理自 Depi 创始人 Roni 与资深安全研究员 JS0N Haddix 的发布在X平台的文章。 今年八月份的 DEF CON 大会刚结束不久，随着 AI 发展弥漫的职业焦虑就溢出了会场之外，AI 出现在了此次大会的演讲、CTF、工具、Village 和厂商展台的每个角落。于是，一种价值判断开始在会场内外私下讨论： 安全研究快没有价值了，下一届 DEFCON 可能不再属于人类，网络安全

过去一年，AI 自动化渗透测试系统越来越复杂。协调 Agent 负责规划，执行 Agent 调用工具，验证 Agent 检查结果，再加上长期记忆、知识检索、攻击树搜索和浏览器自动化，AI 框架越来越复杂，功能也越来越多，整个系统活脱脱被建设成了一个小型安全团队，系统能力测评的 Benchmark 成绩也随之不断提高。但问题是：这个成绩究竟是来自复杂架构（如Harness之类），还是来自底层模型本身

最近 Cloudflare 发布了一篇关于 Project Glasswing 和 Mythos Preview 的文章。表面上看，这是一篇关于“AI 模型帮助发现漏洞”的技术博客，但如果放到企业安全工作的实际场景中，它讨论的其实是一个更大的变化： 当模型已经可以发现漏洞、构造利用链、生成 PoC，并在一定程度上自我验证时，安全团队原有的漏洞管理流程还能不能承受这种能力。 这里需要先把几个概念说清

过去的一年，常常会听到关于纯AI化的代码安全审计产品，也就是所谓的AI-Native（AI原生） SAST（Static Application Security Test），这摒弃了过往传统的SAST产品通过堆积大量规则进行代码检测的思路，且听起来很“动人”。这样的产品只要把代码仓库交给一个 AI大模型，它就像资深安全工程师一样从几十万行代码里找出安全漏洞，并生成代码级的修复建议。 如果只看相关

这是一篇迟到的文章，至少相比现在AI发展的速度，但其思路依然适用于当前的CVE漏洞分析，甚至会因为目前更强的模型而变得更强。在 AI 技术快速变革的当下，除了模型能力之外，我们更应当多思考如何基于 AI 构建和形成有效的工作流，因为这是我们绝大多数人唯一可控且能够产生价值的工作。 2025 年 8 月 21 日，Efi Weiss 和 Nahman Khayet 在 Substack 发布了一篇文

自大语言模型（LLM）震惊世界后，多年以来网络安全领域的从业者们也一直在探索将LLM应用到自动化漏洞挖掘或自动化渗透测试，终于在2025年，来自美国的XBOW公司的XBOW以自动化渗透测试能力登顶了漏洞悬赏平台HackerOne的榜单第一。 传统的漏洞扫描工具主要依赖于预定义的规则、签名或简单的启发式算法，其局限性在于无法理解复杂的业务逻辑，且容易产生大量的误报（False Positives）

最近，成都发生了一起小米汽车碰撞事故，车辆起火燃烧后，汽车门打不开，延误了救人的宝贵时间，最终造成车内乘员死亡的惨剧…… 这个事件引起许多人对于汽车安全的关注，更多人则和小米汽车在宣发时候强调的安全性做对比，却发现宣传时候的安全性在这起事故中并没有起到作用，最关键的是事故后车门打不开。 这不难让人起疑，厂家不是说各项安全测试均通过，甚至超过20倍以上么？为什么在真正考验安全的时候，安全却不起作用了

过去一段时间，笔者频繁尝试用ChatGPT、Copilot以及它们的Agent模式来开发软件、编写代码。目的是想看看AI开发的极限在哪里，或者它的最大问题和最大的帮助在哪里？随着使用的深入，笔者逐渐摸索出一条新的开发路径： 把AI当作团队里的“初级开发人员”，而笔者自己则承担架构师、产品经理和代码审查员的多重角色。 这种方式并不是让AI替代程序员，而是让它成为开发协作的一部分。AI的速度和创造力，

一、漏洞概述1.1 漏洞基本信息漏洞编号：CVE-2025-9074 漏洞类型：CWE-668（将资源暴露给错误范围 ） CVSS评分：9.3（CVSS v4.0） 危害等级：严重 影响范围：Docker Desktop（Windows和macOS系统） 影响版本：>4.25，<4.44.3 发现时间：2025年 修复状态：已修复（4.44.3以后版本） 1.2 背景介绍Docker