资讯动态

RSAC 2026创新沙盒十强深度拆解:AI原生安全、开发安全左移与供应链安全趋势

发布时间:2026/10/17 4:38:29 来源:尧图企业网站定制
1. 创新沙盒为什么值得每年蹲守RSAC 创新沙盒Innovation Sandbox是我每年必追的一个环节原因很简单它不像主会场那些大厂 keynote 一样讲宏大叙事而是把十家早期公司拉到同一个擂台上每家只有几分钟时间讲清楚自己到底解决了什么问题。能进十强的团队通常已经在某个细分方向上憋了两三年产品有雏形、有早期客户、有真实场景验证只是还没到大规模铺开的阶段。换句话说这里是观察未来两三年安全行业风向最密集的窗口。2026 这一届的十强名单出来之后我花了一个周末把每家的公开材料、技术博客、演示视频和能扒到的专利信息过了一遍。整体感受是AI 原生安全不再是口号而是真正渗透到了产品架构的底层开发安全左移从建议变成了默认动作供应链安全则从依赖扫描扩展到了构建过程本身的完整性验证。这三个热搜词基本勾勒出了今年十强的技术底色。这篇文章适合两类人看一类是安全从业者想快速判断哪些方向值得投入学习另一类是技术决策者需要在预算有限的情况下判断哪些能力应该自建、哪些可以采购。我会逐家拆解产品逻辑、核心技术点、适用场景并补充一些基于常见实践的判断帮你把这份名单转化成可落地的参考。2. 十强企业产品逐家拆解2.1 AI 原生安全方向三家把模型当第一公民今年十强里有三家明确以 AI 原生安全为核心定位但切入角度完全不同值得分开说。第一家做的是模型运行时防护。传统安全产品保护的是进程、网络、文件而这家把防护层直接嵌进了模型推理链路。它的核心思路是在模型输入输出之间加一层策略引擎对 prompt 注入、越权工具调用、敏感数据外泄做实时拦截。技术上看它没有用简单的关键词匹配而是训练了一个轻量级的意图分类模型对每次调用做语义级判断。实测数据里提到误报率控制在 2% 以下这个数字如果真实在同类产品里算相当能打。适用场景很明确已经在生产环境跑 LLM 应用、但又不敢完全信任模型输出的团队。第二家走的是AI 资产发现与治理路线。现在很多企业里 AI 应用是业务部门自己偷偷上的安全团队根本不知道有多少模型在跑、调用了哪些外部 API、训练数据从哪来。这家产品通过流量镜像加 API 指纹识别自动盘点企业内所有 AI 服务然后给每个服务打上风险标签。这个思路其实借鉴了当年 CASB 做影子 IT 发现的路子但针对 AI 场景做了适配。我觉得它的价值不在于技术多新而在于解决了安全团队看不见的痛点。第三家比较特别做的是AI 驱动的攻击面管理。注意这里 AI 是手段不是对象。它用模型来自动化地做资产测绘、漏洞关联和攻击路径推演把原来需要分析师手工串联的信息自动生成攻击链视图。演示里它把一个包含几十个资产的网络在几分钟内画出了从入口到核心数据的完整路径并标注了每一步的利用难度。这个方向竞争激烈但它胜在把 AI 推理和传统 ASM 数据结合得比较自然不是硬套。2.2 开发安全左移方向两家把检查点前移到了编码阶段开发安全左移喊了很多年但真正落地的难点在于安全工具如果影响开发效率开发者就会绕过它。今年这两家入围企业思路都是让安全检查变得无感。第一家做的是IDE 内实时安全建议。它不是等代码提交后再扫而是在开发者敲代码的过程中基于本地轻量模型对当前函数做上下文分析发现潜在注入、硬编码密钥等问题时直接在编辑器里提示。关键技术点在于它把规则引擎和模型推理做了分层高频简单问题走规则复杂逻辑走模型保证响应速度在毫秒级。我试过类似产品最大的感受是不打断心流比查得全更重要这家在这一点上做得比较克制。第二家做的是依赖组件的可信度评分。传统 SCA 工具只告诉你某个依赖有没有已知漏洞但不管这个包本身可不可信。这家产品引入了维护者活跃度、发布频率异常、代码变更模式等信号给每个依赖打一个动态可信分。比如一个包突然换了维护者、或者新版本引入了大量混淆代码分数就会骤降。这个思路其实是在补供应链安全的人的维度因为很多攻击是从维护者账号被盗开始的。2.3 供应链安全方向两家把验证做到了构建层供应链安全今年有两家入围都不约而同地把重点放在了构建过程的完整性上而不是只扫最终产物。第一家做的是构建环境证明与溯源。它的核心是给每次构建生成一份不可篡改的证明记录用了哪些源码、哪些依赖、在什么环境下编译。这样即使攻击者往产物里塞了东西也能通过比对证明发现异常。技术实现上它用了类似透明日志的结构保证证明本身不能被悄悄篡改。这个方向对金融、关基行业特别有吸引力因为合规审计需要这种可追溯性。第二家做的是制品仓库的实时防护。它部署在制品仓库前面对每次上传的包做动态分析发现恶意行为就阻断。和传统扫描不同的是它会实际在沙箱里跑一遍安装和初始化过程观察有没有异常网络请求、文件写入或进程创建。这个动起来看的思路比静态特征匹配有效得多尤其对新型供应链攻击。2.4 其余四家数据安全、身份、云原生各有一家剩下四家分布在数据安全、身份安全和云原生安全三个方向。数据安全这家做的是动态数据脱敏与访问控制特点是策略跟着数据走而不是跟着网络走。数据被复制到哪策略就跟到哪解决了传统边界防护在数据流动场景下失效的问题。身份安全这家做的是机器身份生命周期管理。现在微服务、CI/CD、自动化脚本产生了大量非人类身份这些身份的权限往往过大且长期不轮换。这家产品自动发现机器身份、分析实际使用权限、建议最小化配置并支持自动轮换。这个方向我认为被低估了因为机器身份泄露往往比用户账号泄露影响更大。云原生安全有两家一家做容器运行时行为基线通过机器学习建立每个容器的正常行为轮廓偏离就告警另一家做云配置漂移检测与自动修复重点在自动修复而不是只告警。两家都强调和现有 CI/CD 流程集成而不是另起一套。3. 核心技术点横向对比与选型参考3.1 三个方向的成熟度与落地难度把十家放在一起看能明显感觉到三个方向的成熟度差异。AI 原生安全方向产品最热但落地难度也最高因为企业首先得有 AI 应用在生产跑其次要愿意接受模型判断带来的不确定性。开发安全左移方向落地阻力最小因为开发者工具接受度高但效果依赖开发者是否真的看提示。供应链安全方向合规驱动最强金融和关基行业有硬需求但实施周期长需要改造构建流程。方向技术成熟度落地难度主要驱动力适合优先考虑的企业AI 原生安全中高业务创新已有 LLM 生产应用开发安全左移中高低效率与质量研发团队规模大供应链安全中中高合规与风控金融、关基、软件供应商3.2 选型时容易忽略的三个判断维度看创新沙盒名单容易陷入技术越新越好的误区但实际选型时我建议多问三个问题。第一这个产品解决的是有没有还是好不好的问题。比如 AI 资产发现很多企业现在连有没有都没解决那这类产品价值就很高但如果企业已经有基本盘点了那就要看它比现有方案好在哪。第二它和现有工具链的集成成本有多高。创新沙盒里的产品往往技术很专但如果需要企业改流程、换平台才能用落地就会很慢。我倾向于选那些能嵌入现有工作流的产品而不是要求你围着它转的。第三团队是否真的理解目标客户的日常。有些产品演示很漂亮但一问细节就发现团队没在真实企业环境里待过。比如做开发安全左移的如果团队里没有真正写过生产代码的人做出来的提示大概率会被开发者关掉。3.3 一个实用的评估清单如果你正在评估这类产品可以拿下面这个清单过一遍每项按 1-5 分打分总分低于 18 分的建议再观察观察。是否解决了明确的、可量化的痛点而不是提升安全性这种模糊目标部署后对现有流程的改动是否可控误报率是否有真实客户数据支撑是否支持渐进式启用先观察模式再阻断模式团队是否有该领域的实际从业背景是否有清晰的定价模型而不是联系我们4. 实操视角如何把这份名单用起来4.1 从名单到内部提案的转化方法很多人看完创新沙盒就完了其实这份名单最大的价值是帮你做内部技术提案。我的做法是先挑出和当前痛点最匹配的两到三家然后针对每家写一页纸的评估内容包括它解决什么问题、我们现在的做法是什么、差距在哪、试点需要多少资源。这一页纸比任何产品白皮书都有说服力因为它是从你的实际场景出发的。具体操作上我会先做一次内部调研问三个问题过去半年有没有因为这类问题出过事现在处理这类问题平均花多少时间如果有个工具能减少一半时间值不值得试这三个问题的答案基本能决定提案能不能过。4.2 试点阶段的关键动作如果决定试点有几个动作我建议一定要做。第一先跑观察模式至少两周收集真实数据再决定是否开启阻断。第二找最愿意配合的团队做试点不要一上来就推给最抵触的团队。第三设定明确的成功标准比如发现 X 个之前没发现的问题或处理时间从 Y 降到 Z否则试点结束没法评估。注意试点阶段最忌讳的是把工具当万能药。任何安全工具都有盲区试点时要同时记录它漏掉了什么这比记录它发现了什么更有价值。4.3 长期跟踪这些公司的信号创新沙盒十强不一定会都成功但跟踪它们后续的发展能帮你判断方向。我一般会关注几个信号有没有拿到新一轮融资、有没有公开的标杆客户案例、产品更新频率如何、团队核心成员有没有变动。这些信号比产品功能更能说明问题。如果一家公司半年内没更新、也没新客户那大概率是遇到瓶颈了。5. 常见问题与避坑经验5.1 关于 AI 原生安全的三个常见误解第一个误解是上了 AI 安全产品就能放心用大模型了。实际上模型安全只是整个 AI 应用安全的一部分数据安全、权限管理、审计日志一样不能少。第二个误解是误报率低就等于好用有些产品误报率低是因为它只报最确定的问题漏报可能很严重。第三个误解是AI 安全产品必须用 AI 来做其实很多场景规则引擎更可靠关键是看问题性质。5.2 开发安全左移落地时最容易踩的坑我见过最常见的坑是工具装了但没人用。原因通常是提示太多、太吵开发者直接关掉。解决办法是初期只开最高置信度的规则让开发者先建立信任再逐步放开。另一个坑是只考核发现数量不考核修复率导致安全团队和开发团队对立。正确的做法是把修复率作为核心指标发现数量只是过程数据。5.3 供应链安全实施中的现实约束供应链安全最大的现实约束是你没法控制上游。很多企业想要求所有供应商都提供构建证明但供应商可能自己都没搞明白。我的建议是分阶段来先对自己核心产品的构建过程做完整性验证再逐步要求关键供应商最后才扩展到全量。一步到位基本不可能。常见问题典型表现建议处理方式工具误报太多开发者关闭提示先开高置信规则逐步放开试点无法推广只有试点团队在用找业务痛点最匹配的团队第二批推广供应链要求推不动供应商不配合先内部后外部分阶段推进AI 安全效果不明显没发现新问题检查是否只跑了观察模式数据是否足够5.4 一个容易被忽略的组织问题最后说一个组织层面的坑很多安全产品失败不是因为技术不行而是因为没有明确谁负责运营。工具装上了但没人看告警、没人调策略、没人跟修复那再好的产品也是摆设。所以在选型阶段就要想清楚上线后谁来日常运营这个人有没有足够时间如果没有那要么先别上要么选那种自动化程度高、运营负担低的产品。我个人在实际操作中的体会是创新沙盒名单最大的价值不是告诉你该买什么而是帮你建立对技术方向的判断力。每年花几个小时认真看一遍比读十份行业报告都管用。今年这十家里我最看好的是机器身份管理和构建环境证明这两个方向因为它们解决的是基础设施层面的问题影响面更广、更持久。至于 AI 原生安全方向肯定对但具体哪家能跑出来还得看接下来一年的落地情况。

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑