★ FEATURED ARTICLE OWASP Top 10这个榜单搞Web安全的人应该都背过几轮了。我最近在整理学习笔记的时候发现一个很有意思的情况你打开OWASP官网能看到2026年智能体应用十大风险清单ASI-01到ASI-10同时社群还在热烈讨论2025版本RC草案的走向而很多团队内部的安全基线还停留在2021版本。三套内容挤在一起难怪不少朋友越学越乱。这篇文章就把我学习过程中的核心内容整理出来重点解决几件事2025版本和2021版本相比到底动了哪些条目、为什么会有2026智能体应用Top 10这个新榜单、以及作为甲方安全工程师或者应用开发拿到这些清单之后应该怎么把它落成实际的排查动作。不是翻译官方文档是按我自己的理解重新梳理了一遍希望对正在学这块内容的人有帮助。1. 先盘清楚时间线2025版本到底发布没发布1.1 从2021到2025为什么这次周期拖了这么久先说结论OWASP Top 10:2025至今没有正式定稿版。项目组在2024年10月发布了2025候选版RC1按计划应该在2025年内走完公开征求意见、社区投票、定稿发布这个流程。但实际情况是RC1发布后收到了大量社区反馈再加上2026智能体应用Top 10的编制工作抢占了项目组的核心精力2025版本的正式发布一再调整节奏。我在学习过程中一开始也被这个状态绕晕了后来想明白一个关键点OWASP Top 10这个榜单的定位决定了它的更新节奏。它不是漏洞库不是CVE而是每三年一次的风险趋势共识。2021版本发布的时候移动端、云原生、API安全还处在各自为战的阶段到了2024年生成式AI应用、智能体Agent、供应链攻击已经成为日常老框架的十个大类明显不够用了。所以2025 RC的很多调整本质上是想把这些新变化纳入经典Web风险体系。1.2 RC1之后的变局智能体榜单为什么截胡了2025年12月OWASP官方宣布了2026年智能体应用十大风险Agentic Security InitiativeASI-01到ASI-10。这个时间点很微妙它正好卡在2025 RC征求意见的收尾阶段。我个人的理解是OWASP意识到智能体应用的威胁模型和传统Web应用差别太大硬塞进Top 10主榜单反而会把两个场景都讲不清楚所以单独开了一个新榜单让主榜单保持Web应用安全的纯粹性。这意味着对学习者来说你现在要掌握的实际上是两套清单一套是2025 RC的主榜单继承并改造2021版本另一套是2026的ASI榜单。前者管传统Web应用和API后者管带大模型、工具调用、自主决策能力的智能体应用。两套清单之间有交叉比如注入、供应链、日志监控这些问题两边都提但看问题的角度完全不同。1.3 我建议的学习路径不要等正式版再动手很多人的第一反应是既然没定稿等正式版出来再学。我不太赞同这个思路。RC1的核心条目已经非常明确正式的十类编号大概率不会大改即便后期微调你建立的风险分析框架也不会白学。更实际的做法是把2025 RC当成当前Web应用的安全排查基线把2026 ASI当成AI应用设计阶段的威胁模型参考两条线同时推进反而效率最高。2. 逐条拆解2025 RC新增的、移走的、回归的2.1 A01注入重新登顶从SQL注入到提示注入2021版本把注入降到了第三位榜首换成了访问控制失效。2025 RC的头号位置重新给了注入但这次的定义范围明显扩大了。官方描述里明确把大语言模型相关的注入形态也归入这一类比如提示注入Prompt Injection、间接提示注入。这里有个容易被忽视的细节传统注入的核心是不可信输入拼接到解释器提示注入其实是同一个本质。用户输入被拼进系统提示词改变了模型原本的执行意图本质上就是在注入指令。如果你把LLM的提示词当成一种解释器这套旧知识立刻就能迁移过去。我在给团队做培训的时候经常用这个类比大家接受度很高。实际排查的时候建议把注入检查分成三条线传统注入SQL、OS命令、XPath、LDAP等重点看参数化查询和输入编码是否到位存储型XSS与前端渲染输出编码是否统一提示注入用户输入是否可能覆盖系统提示词、外部内容网页、文档是否可能携带恶意指令。2.2 A04身份系统扩散微服务时代的新顽疾这是我整份学习笔记里最想强调的一个新条目。2025 RC把身份系统扩散从安全配置错误里拆出来单独成类编号A04。为什么单独立项因为现实中的企业应用身份认证早就是一张复杂的网内部员工走企业SSO外部客户走社交登录部分老系统还是自建账号体系微服务之间再叠加OAuth2.0、JWT、mTLS接口和接口之间的信任关系根本数不清。拆成独立条目意味着OWASP认为这不是一个配置问题而是一个架构层面的风险。多个身份系统之间的信任边界、会话管理不一致、令牌生命周期不统一这些才是真正的高危点。我在实际项目里见过一个后台系统前端用新SSO后端某个内网服务还认老系统的Cookie结果攻击者只要拿到老系统的低权限账号就能绕过前端认证直接调后端接口。学习这个条目的时候不要只盯着弱口令这种基础问题重点要分析身份系统的边界图谁在认证、谁在授权、令牌在哪里生效、跨系统调用时信任是怎么传递的。2.3 A07攻击面管理不足从漏洞扫描到资产测绘A07是另一个新面孔全称是攻击面管理不足Insufficient Attack Surface Management。这个条目的出现和当前攻防演练的现状直接相关影子IT、临时环境、测试接口、被遗忘的子域名这些攻击面靠传统漏扫根本覆盖不到。OWASP关注的不只是有没有漏洞而是你根本不知道这里有个入口。举个例子一个团队为了联调在云上开了个临时环境等联调结束没人销毁这个环境保留了老版本的代码、默认凭据、完整的业务数据然后它没有被纳入任何安全监控。这就是攻击面管理缺失的典型场景。做这一类排查建议先做资产清单再做边界收敛。资产清单要覆盖域名和子域名、IP和端口、云资源、API网关路由、第三方集成账号。边界收敛方向上测试环境与生产环境网络隔离、临时环境自动销毁、开发接口默认不对外开放。没有资产清单谈攻击面管理都是空话。2.4 其余条目的变化逻辑A02、A03、A05、A06、A08、A09、A10RC1的变化不只是新增条目还有几个值得注意的调整A02软件和数据完整性故障2021版本里它排第八这次升到第二。供应链攻击、CI/CD流水线投毒、不安全的反序列化、自动更新被劫持都归在这一类。升级的原因很现实SolarWinds事件之后行业对供应链风险的重视程度完全不一样了。A06不安全认证注意它和A04身份系统扩散的区别。A06关注的是单点认证机制本身比如弱口令、暴力破解防护缺失、会话固定A04关注的是多个身份体系之间的整合问题。一个管点一个管面。A03安全配置错误因为A04拆走了身份相关部分剩下配置错误的内容更聚焦默认凭据、多余功能开启、错误信息泄露、安全响应头缺失。A05易受攻击和过时组件老面孔但现在的关注点更多落在已知漏洞如何被利用链串联上。A08安全日志和监控故障云原生环境下这是大问题容器实例说没就没日志如果不能集中留存事后溯源基本靠猜。A09服务端请求伪造保持独立和云元数据服务比如云厂商的实例元数据接口攻击结合是当前最典型的利用路径。A10不安全设计和不安全编码区别开重点关注威胁建模缺失、架构层面的不安全默认值。为了方便自己复习我列过一张变化对比表这里也一并放出来2021版本2025 RC候选版变化说明A01 访问控制失效A01 注入注入回归首位纳入提示注入A02 加密失败A02 软件和数据完整性故障供应链与CI/CD风险权重提升A03 注入A03 安全配置错误配置错误聚焦身份问题拆分出去A04 不安全设计A04 身份系统扩散新增身份体系整合问题A05 安全配置错误A05 易受攻击和过时组件位置调整A06 易受攻击和过时组件A06 不安全认证聚焦单点认证机制A07 身份识别和认证失败A07 攻击面管理不足新增资产测绘与边界收敛A08 软件和数据完整性故障A08 安全日志和监控故障位置调整A09 安全日志和监控故障A09 服务端请求伪造位置稳定A10 服务端请求伪造A10 不安全设计位置稳定这张表能帮你看清一个趋势OWASP越来越强调架构层面的风险而不是单点漏洞。身份系统扩散、攻击面管理不足、不安全设计这三类问题都不是靠升级一个组件、打个补丁能解决的它们需要的是架构评审和制度流程。3. 2026智能体应用Top 10ASI-01到ASI-10怎么学3.1 为什么智能体安全值得单独立榜先解释一下智能体是什么意思。简单说就是不止能聊天还能调用工具、访问外部系统、自主做决策的大模型应用。比如一个客服智能体收到用户请求后查订单数据库、发退款指令、更新工单系统——整个流程里模型在扮演决策者和执行者的双重角色。传统Web安全关注的是人访问系统智能体安全关注的是程序替人做决定。这种转变带来一堆新问题提示词能不能被绕过、模型记忆里有没有敏感数据、工具调用权限是不是过大、多个智能体之间协作时怎么互相信任。OWASP成立Agentic Security Initiative专门编制了十个风险类别编号就是ASI-01到ASI-10。学习ASI清单的时候我建议不要逐个死记而是先抓三个底层思维信任边界、权限最小化、不可信输入。把这三个思维套到任何一个风险条目上都能快速理解它到底在担心什么。3.2 ASI-01到ASI-03提示注入、记忆管理、过度自主ASI-01不安全提示注入。这是智能体应用的头号风险和主榜单A01呼应。智能体接收的输入通道比传统应用多得多用户聊天、网页内容、上传文档、邮件、API回调任何一条通道都可能携带恶意指令。间接提示注入尤其隐蔽——一段看似无害的网页文字就可能诱导模型执行高权限操作。ASI-02不当的记忆管理。很多智能体会把用户偏好、历史对话、业务上下文存下来这些记忆内容可能包含隐私数据。风险点有两个一是记忆库被恶意提取二是脏数据被写入记忆后污染后续所有决策。记忆管理的本质是数据分类分级和隔离。ASI-03过度智能体Excessive Agency这个翻译成过度自主更顺。指的是给模型分配了超出任务需要的权限和工具。我在一次分享里用过这个类比你不会给实习生发万能钥匙但很多团队给AI Agent发了整个生产数据库的读写权限。治理思路就是每次只授最小权限重要操作必须有人类审批。3.3 ASI-04到ASI-08通信、沙箱、生态输入、委派与输出ASI-04不安全的智能体间通信。多个智能体协作时消息在Agent和Agent之间传递一旦中间链路被截获或篡改整个任务链都会被带偏。这个场景和微服务通信很像解决思路也能复用双向认证、消息完整性校验、敏感字段加密。ASI-05不当的沙箱机制。模型执行工具调用、运行代码、访问文件时如果逃逸出沙箱攻击者就能获得宿主环境权限。这里的沙箱既指容器隔离也指权限限制和网络策略。排查重点模型执行代码的运行时是否隔离、工具允许访问的资源范围是否可控。ASI-06不可信的生态输入。这是RAG应用最常踩的坑。RAG让模型基于外部知识库回答问题但知识库里的内容并不都是可信的。攻击者往知识库投毒、篡改文档模型就会把恶意内容当成事实输出甚至据此执行指令。关键是知识库的写入权限控制、来源验证、内容可信度分级。ASI-07不当的委派与监督。这是多智能体系统特有的风险。主智能体把子任务委派给子智能体子智能体的权限可能和主智能体不一样链路过长之后监督失效。典型问题子智能体独立处理敏感操作、没有人工复核机制、委派链路没有审计记录。ASI-08不安全的输出处理。模型输出直接进入后续系统时可能造成二次注入。比如模型生成了一段SQL查询应用直接执行或者生成了一段HTML前端直接渲染。这和传统应用的输出编码问题一模一样只不过不可信输出的来源从用户变成了模型。3.4 ASI-09与ASI-10人机混淆与供应链ASI-09智能体与用户混淆。这个风险解决的是责任归属和冒充问题。用户和智能体对话时怎么确认对面是真人还是程序智能体以某个身份对外输出内容被冒充后怎么追责实际场景智能体代替用户发表评论、下单、签协议如果没有明确的身份标识和授权记录用户完全可以否认操作。ASI-10智能体供应链破坏。智能体应用的供应链比传统软件更长基础模型权重、微调数据集、插件、工具库、提示词模板、第三方Agent服务每一环都可能被植入恶意逻辑。防范思路和传统供应链一脉相承来源锁定、完整性校验、依赖清单管理。3.5 把ASI映射回经典安全框架学习加速器学ASI的时候我发现一个技巧先把每个新风险映射到经典安全概念上理解速度会快很多。我给自己做了一张映射表ASI条目经典安全概念对应现实场景ASI-01 提示注入命令注入用户输入覆盖系统指令ASI-02 记忆管理敏感数据泄露记忆库变成数据仓库ASI-03 过度自主越权与权限过大Agent拿到万能钥匙ASI-04 Agent通信不安全中间人攻击Agent间消息被篡改ASI-05 沙箱不当隔离失效代码执行逃逸到宿主机ASI-06 生态输入不可信数据污染/投毒知识库被注入恶意内容ASI-07 委派监督不当审批流程缺失子Agent擅自做决定ASI-08 输出处理不安全二次注入/XSS模型输出执行SQL或脚本ASI-09 人机混淆身份认证与授权不一致分不清操作者是人是机器ASI-10 供应链破坏软件供应链攻击模型插件被植入后门这个映射不改变风险的本质但它让你能调用已有的知识积累不用从零学一套新概念。4. 学完之后怎么落地从清单到排查执行表4.1 用2025 RC给现有Web应用做一次健康检查知道十个类别不等于能做安全排查。我自己的实践是把RC清单翻译成一份可执行体检表拿到任何项目上都能快速过一遍。体检表长这样资产盘点域名、IP、API、云资源全部登记标出负责人和生命周期身份体系审计画出登录流程图标出所有身份源和令牌校验点找出信任边界注入类检查抓包看输入点重点看参数化、编码、白名单是否到位组件清单统计所有第三方依赖版本对照已知漏洞库建立台账错误处理检查报错页面是否泄露堆栈、SQL语句、内部路径日志覆盖检查核心业务操作是否记录操作人、时间、来源IP、操作内容供应链与CI/CD检查构建依赖是否锁定版本、发布流程是否双人复核、制品库是否有完整性校验。这套体检表不追求一次做完可以拆成多个迭代。第一轮先做资产盘点和身份审计因为这两项是一切排查的基础第二轮再做注入和组件第三轮补日志与监控。我自己在一个中小型项目里按这个节奏跑过一轮差不多三周能把主线摸完。4.2 给AI智能体应用建立差异化的威胁模型如果你手上有智能体项目光套用RC清单是不够的必须叠加ASI的维度。建威胁模型的时候我建议按输入-记忆-工具-输出-委派这五段来拆输入段用户输入、外部文档、API回调都可能带指令逐一标出注入可能性记忆段确认记忆内容里有哪些敏感字段落库是否加密是否有数据导出接口工具段列出模型能调用的所有工具和权限范围逐项评审是否最小化输出段模型输出会被谁消费是否可能触发代码执行、数据库操作、页面渲染委派段子智能体的权限边界人工审批点在哪个环节审计日志是否完整。这里容易踩的坑是只做大模型本身的防护比如只看提示词模板、只做内容审核而忽视了整个应用链路的经典安全问题。实际上一个AI客服如果调用订单接口时没有做好接口鉴权和限流照样能被刷爆。AI应用也是Web应用传统安全基线不能丢。4.3 团队推进时的三个常见误区第一把对照清单找漏洞当成唯一目标。Top 10的真正价值是帮你建立分类思维而不是一份穷举清单。排查任何一个问题时都要追问它在哪一层、攻击路径是什么、修复后能否覆盖同类问题。第二把ASI风险当成算法问题丢给算法团队。ASI-04到ASI-08里的很多风险本质上是系统架构问题需要安全工程师、平台工程、应用开发一起参与。算法团队最多能解决模型侧的提示词工程和内容过滤权限、沙箱、通信加密、审计这些都得靠后端和基础设施团队。第三只输出报告不推动整改。安全排查的终点是风险处置闭环。每条风险至少要有负责人、处置方案和复查时间否则报告再厚也是废纸。在这么多次项目中我发现最有效的推动方式是把风险量化成业务影响比如订单系统这个越权漏洞攻击者可以按任意价格成交预计影响X条核心链路老板一听就明白优先级了。5. 一点个人学习体会把OWASP Top 10:2025和2026智能体应用Top 10放在一起看之后我最明显的感觉是安全行业的关注点从漏洞是什么转向了系统怎么被信任。2025 RC新增的身份系统扩散和攻击面管理不足都在指向同一个问题——复杂系统里你不知道的边界才是最大的风险。ASI榜单则把这个逻辑推到了AI应用当系统自己会做决定的时候信任边界到底画在哪。我自己的学习节奏是每周过两到三个条目每个条目都找一个真实的案例去验证而不是只读定义。比如学A04我就翻了手头项目的登录链路图学ASI-02就研究了一下智能体记忆存储方案的数据流动。这样学完的东西是粘在身上的而不是飘在脑门上的。相关的溯源链接我就不放了官方页面的信息本身够用。最后分享一个小技巧学这种不断更新的安全框架最重要的是给自己建一个变化日志每次都记录新增条目、删除条目和位置变化到了下一版发布的时候这个日志就是你最快上手新框架的捷径。
阅读完成 · 觉得有帮助？
