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

过去的一年，常常会听到关于纯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

本文是是根据《从Top20开源组件漏洞浅谈开源安全治理困境》中，我们梳理的最常见组件漏洞制作的漏洞分析系列。 本篇是该系列的第二篇分析报告。 一、漏洞概述1.1 漏洞基本信息漏洞编号：CVE-2017-3523 漏洞类型：CWE-502不受信任数据的反序列化 CVSS评分：8.5（CVSS 3.1） 危害等级：高危 影响组件：mysql-connector-java 影响版本：<=

本文是是根据《从Top20开源组件漏洞浅谈开源安全治理困境》中，我们梳理的最常见组件漏洞制作的漏洞分析系列。 本篇是该系列的第一篇分析报告。 一、漏洞概述1.1 漏洞基本信息漏洞编号：CVE-2018-17297 漏洞类型：CWE-22路径遍历 CVSS评分：7.5（CVSS v3.1） 危害等级：高危 影响组件：Hutool Java工具库 影响版本：Hutool < 4.1.12 发现时

在最近几年的客户交流中，常常有客户提及开源治理，或者开源软件安全治理，但又不清楚到底应该从何处着手，或者说开源治理到底应该做到什么样的程度。于是最终的诉求往往会变成： 企业在做开源治理时，是不是应该有一套产品能够解决所有问题？ 这个问题乍一听有点“架空”，但其实暗含了很多有价值的观察和经验判断。说到底，这不是一个工具或流程上的问题，而是对“开源安全治理是什么”的重新思考。 过去这几年，我们团队在协

随着大型语言模型（LLM）在各行业的广泛应用，如何高效、安全地将LLM与外部数据源和工具集成成为了关键问题。为此，Anthropic于2024年11月推出了模型上下文协议（Model Context Protocol，简称MCP），旨在为LLM提供一个标准化的接口，以便与外部系统进行交互。 什么是上下文（Context）上下文是指在与LLM交互过程中，提供给模型且能够用于指导LLM理解、推理和生成