01 AI资产风险发现：从资产识别到风险研判
随着 AI 应用在生产环境中的广泛部署，其安全风险逐渐呈现出资产识别困难、漏洞影响难以判定、依赖风险复杂以及风险状态动态变化等特征。 一个暴露在公网或部署在企业内部的 AI 服务，可能缺少准确的产品和版本信息；公开披露的 CVE 未必影响当前资产；项目自身没有漏洞，也可能因为依赖组件引入新的风险。同时，产品版本、组件依赖和外部安全事件都在持续变化，单次扫描越来越难完整反映一个 AI 资产的实际风险。
因此，在 AI 应用落地之后，安全人员往往需要进一步回答下面这些问题：
这些问题共同构成了我们对 AI资产风险发现 的理解：它不只是一次漏洞扫描，而是围绕资产识别、风险关联、影响研判和持续监测建立一套完整的分析过程。
围绕这一目标，我们目前主要建设了以下几类能力：
在这些能力之上，我们重点关注两个方向：覆盖范围能否持续扩大，以及风险分析能否持续深入。
看得更广：让资产识别持续扩展
AI 产品出现和迭代的速度很快，仅依靠人工维护固定指纹库，很难及时覆盖新的产品形态。我们面向 FOFA、Quake、ZoomEye 等测绘平台的十万级 App / Product 标签池持续开展指纹生成和验证，并同时提取 Title、Footer 等显式特征，以及 JS 变量、CSS 类名、资源路径等隐式特征，提高对二次开发、页面修改和伪装场景的适应能力。
通过持续运营，指纹库可以随着新产品和新特征不断扩展。截至 2026 年 9 月，平台已沉淀 4K+ 通用指纹和 150+ AI 应用专项指纹。
查得更深：把静态漏洞信息转成具体资产风险
在完成资产识别之后，分析不会停留在 CVE 列表。我们进一步结合 POC、应用漏洞、供应链关系、漏洞可达性和威胁情报，对风险进行逐层补充和验证，整体链路包含：
也就是说，风险分析会从产品本身逐步延伸到依赖组件、真实影响范围以及外部安全动态，最终回到具体资产和版本上。
后文将重点介绍两项代表性技术——智能资产识别与供应链风险溯源，并在最后展示这些能力如何汇聚到AI资产多维风险研判中。
02 智能资产识别
资产识别是风险分析的入口，识别范围和准确度直接影响后续漏洞关联与风险研判。 现有方式各有局限：人工提取成本高，开源规则覆盖有限，单纯依赖 LLM 又难以稳定保证质量。
为此，我们以测绘平台已标注的真实资产为参照，由 LLM 生成候选指纹，并结合实际资产分布进行验证和筛选，形成可持续运营的指纹生成流程。现阶段主要面向 FOFA、ZoomEye、Quake 等测绘数据源开展指纹生成与验证。
不止看表面：显式与隐式特征一起识别
在指纹生成阶段，我们使用绿盟风云卫大模型，对页面特征进行细粒度的提取。除了 Title、Footer、Copyright 等显式信息外，还会进一步关注 JS 变量、CSS 类名、相对路径等隐式特征。相比只依赖明显页面元素，这种方式能够保留更多具有区分度的细节，对二次开发、页面修改和一定程度的伪装场景更友好。下表列举了部分常见的指纹特征。
指纹好不好，用真实资产说话
在验证方式上，我们更关注指纹在真实资产上的整体表现。为此，我们建立了可量化的质量指标，对生成指纹进行持续评估，并据此完成筛选、入库和迭代。相比只判断规则是否命中，这种方式更适合衡量指纹在真实场景中的准确性和覆盖能力，也为后续自动化运营提供了统一标准。
其中，f 可以理解为我们拿来对比的“标签”，比如网站指纹、网站标题；tf 和 of 分别表示官方查询和生成指纹查询下，这个标签对应的资产数量。实际查询时，平台通常会返回一组 Top-N 标签和对应数量，所以我们不是只看某一个标签有没有命中，而是把两边的整体分布放在一起比较，最后计算 Precision、Recall 和 F1，判断两次查询结果到底有多接近。更直观地说，我们可以直接在测绘平台上分别查询官方标签和生成指纹，看它们命中的主要标签和资产数量是不是相近。部分指纹和验证结果如下。
指纹是如何运营的？
为此，我们搭建了一套离线运营平台。以下图中的 drawDB 为例，平台先从 ZoomEye 获取目标资产数据，再由风云卫大模型从页面文本、CSS、资源路径等位置提取显式与隐式特征，生成候选指纹，后进入验证环节。红框部分为指纹 “drawDB | Online database diagram editor and SQL generator” 的验证结果，其中准确率为 100%，召回率为 93.3%，F1 为 0.96。达到设定阈值的指纹会自动进入指纹库，完成从资产采集、指纹生成到验证入库的完整闭环。
依托这套运营平台，我们在三个月内累计沉淀了 4K+ 条指纹。下一步，我们将重点研究无监督场景下的指纹质量评价方法，希望对不同来源、不同生成方式的指纹建立更统一的有效性评价标准。
03 供应链风险溯源
传统开源组件平台已经能查组件、版本和漏洞，为什么 AI 项目的供应链还需要单独研究？
一个重要背景是，AI 项目迭代速度快、版本分支多、依赖复杂，而且正在被越来越多企业以不同版本、不同部署形态广泛使用。对于企业侧的大规模资产管理来说，不可能对每个项目、每个版本都逐一开展源码审计，也很难依靠人工把项目依赖逐项映射到开源组件平台中完成风险核对。
因此，更现实的需求是：自动识别项目依赖、理解版本关系，并将具体项目版本持续关联到组件、漏洞和风险传播路径中。 这也是我们开展供应链风险溯源技术的出发点。
首先，我们使用的开源组件数据底座本身就不是简单的组件集合。 相比 OSI、libraries 等以组件收录和基础关联查询为主的平台，我们采用知识图谱组织组件、版本、依赖和漏洞之间的关系，更关注复杂的上下游依赖链路。下图展示了绿盟开源组件供应链知识图谱。以 PyPI 生态中的 tensorflow-gpu 2.7.4 为例，可以沿图谱继续追踪其上下游组件、关联漏洞及风险传播路径，从而为后续的风险溯源、影响范围分析和传播面管理提供基础。
有了开源组件知识图谱，下一步的问题是：怎样把一个具体的 AI 项目真正接进来？
为此，我们进一步解析 AI 应用自身的组件依赖，并将这些依赖关系接入现有的千万级开源组件知识图谱。整个过程被封装成一套自动化流水线：① 拉取项目仓库中的依赖声明文件；② 解析项目、组件与版本之间的依赖关系，并转换为图数据；③ 将依赖组件关联到千万级开源组件知识图谱；④ 最终汇入 AI 资产风险子图谱。
不止供应链：把应用自身漏洞也纳入图谱
除了供应链漏洞，应用自身漏洞也需要纳入图谱。问题在于，漏洞公告给出的是“0.3.14 及以下”“fixed in 0.3.15”这类自然语言版本范围，而代码仓库提供的是实际 Tags 列表，两者往往无法直接对齐，甚至边界版本并不存在于 Tags 中。
为此，我们引入步骤⑤：结合漏洞公告中的版本描述与仓库 Tags，确定实际受影响的版本区间，例如 [“v0.0.1”, “v0.3.14”]，从而实现漏洞与产品版本的准确关联。
不止漏洞：把威胁情报也接进来
我们还在步骤⑥中加入了 NTI （绿盟威胁情报），除了漏洞本身，用户可以进一步查看AI 应用相关的安全事件、热点新闻等信息，对产品风险补充背景理解。
报告对威胁情报的新闻、事件等内容进行展示
发现了吗？项目和组件可能是同一个产品
步骤⑦解决的是同一产品以不同形态发布时的重复识别问题。例如 OpenClaw 既有源码仓库，也以 NPM 包形式发布，如果两者分别进入图谱，就容易被当成两个独立对象。为此，我们引入 Derive 关系，将项目仓库中的 Git Tag 与对应的组件版本进行映射，把“项目”和“组件”重新关联到同一个产品及版本体系中。
九个步骤很复杂？平台替你持续跑
前面的九个步骤涉及依赖解析、版本映射、漏洞关联、情报融合和图谱更新，如果依靠人工处理，运营成本较高。为此，我们将整套流程统一封装到运营平台中，由平台持续跟踪项目变化并自动完成更新。目前已覆盖 MaxKB、XInference、FastGPT、Ollama 等 94 个 AI开源项目，累计持续运营 18,557 个版本。
风险报告：供应链风险
下面展示 AI 资产风险发现报告中的供应链风险模块，该模块将前述供应链图谱能力落到具体资产和版本上，集中呈现应用漏洞、供应链漏洞及其关联关系。以 OpenClaw v2026.3.28.beta.1 为例，该版本共关联 35 个应用漏洞。这里的“应用漏洞”是指项目自身在该版本上直接受影响的 CVE，在图谱中通过 Repo → Project → CVE 的关系路径进行展示。
另一部分是供应链漏洞。同样以 OpenClaw v2026.3.28.beta.1 为例，该版本共关联 13 个供应链漏洞，这些风险并非来自项目自身，而是由其依赖组件传递而来，在图谱中通过 Repo → Project → Component → CVE 的路径进行展示。
在实际报告中，用户可以按“应用漏洞”或“供应链漏洞”进行高亮查看，快速区分两类风险来源。
04 AI资产多维风险研判
前面已经介绍了指纹识别、供应链漏洞和威胁情报等核心模块，本节集中AI 资产风险报告中的整体呈现。对于一次扫描任务，报告首页会汇总识别到的应用类型及其风险情况，并通过统一评分对不同应用的风险程度进行排序和展示。
风险报告：资产识别与风险排名
当前评分由四部分组成：POC：30/条 · 应用漏洞：5/条（上限40） · 供应链漏洞：1.5/CVE（上限30） · NTI：2/条（上限25）。分值越高，表示该应用当前聚合到的风险越多。
风险报告：POC 验证
报告可直接展示资产指纹识别结果，并对已验证的 RCE 漏洞给出对应的 POC 结果和触发流量快照。
风险报告：应用漏洞
从 AI 资产到静态漏洞的关联主要依赖指纹识别结果，是否能够识别具体版本，会直接影响漏洞关联的范围。如下两图所示：对于未识别出具体版本的 OpenClaw，报告会展示其已收录的 148 个版本相关漏洞；而对于能够识别到 MaxKB v0.9.1 的资产，则可以直接关联并展示该版本对应的风险。
报告对OpenClaw全版本的应用漏洞进行展示
报告对MaxKB v0.9.1的应用漏洞进行展示
风险报告：许可信息
05 Q&A
Q:这个AI资产风险发现与传统扫描器有什么区别啊？
传统扫描器解决“这是什么、有没有漏洞”。
我们重点解决AI资产识别得更全，以及识别之后还能继续看到它背后的供应链和情报风险。
重点体现在三个核心工作，
①AI指纹识别的更多了，能够覆盖FOFA、Zoomeye、Quake等长期运营的测绘平台产品类型。
②从应用漏洞扩展到供应链漏洞，核心价值不是“我们有很多漏洞”，而是我们补上了 AI 应用和已有千万级组件漏洞库之间的关系。
③从漏洞结果扩展成风险信息，一个 AI 资产识别出来之后，不只告诉用户 CVE或已验证漏洞，还能看到：应用漏洞、供应链漏洞、NTI威胁情报、License 信息。
Q:这个AI资产风险发现 和 前面的AI Agent 安全治理有什么区别？
AI资产风险发现，主要看 Web 侧暴露出来的 AI 资产。
AI Agent 安全治理，主要看企业内部正在运行的 Agent。
前者回答的是：外部暴露了哪些 AI 应用、平台或服务，这些资产本身有什么漏洞、供应链风险和情报风险。
后者回答的是：企业到底有多少 Agent，这些 Agent 在运行过程中做了什么，调用了哪些模型、工具和数据，是否出现异常行为或异常轨迹。
两部分都可以归到更大的AI安全治理体系，从两个不同视角分别解决AI应用资产 和 智能体内部的风险。
本文围绕 AI 资产风险发现，重点介绍了指纹能力提升和供应链风险管理两项工作，并展示了相关数据在风险报告中的实际应用。当前已经基本打通了从资产识别、漏洞关联到供应链分析和报告呈现的完整链路。
后续我们将继续完善指纹质量评价、供应链数据覆盖和自动化运营能力，让 AI 资产风险发现更加准确、持续和可用。