CyberStrikeAI 新增资产管理：从零散目标到可持续维护的资产基线（文末附八群二维码）

端口扫描、网络空间测绘、漏洞扫描器和应急排查都在产生目标，但当有人问“现在有多少互联网暴露资产”“哪些从未检查过”“风险落在哪项资产上”时，答案往往仍散落在表格、报告和聊天记录里。

问题不在于没有发现，而在于发现之后没有形成可持续核对的资产基线。

CyberStrikeAI 新增资产管理，不是再放一张主机清单，也不是替代传统 CMDB，而是把不同工具和任务里的目标统一识别、去重和归档，回答三个问题：有什么、查过没有、风险在哪里。

发现不是终点。只有当一个目标被持续识别、分配、检查、关联风险并再次复查时，它才真正进入安全管理。

一、为什么要在 AI 安全平台里做资产管理

1. 一次性扫描解决“这一刻”，资产管理解决“时间”

一次渗透测试解决“这个目标现在有什么问题”，持续运营还要回答：

• 这个目标第一次是什么时候出现的？
• 最近一次又是什么时候被发现的？
• 它属于生产环境还是测试环境，属于哪个业务或项目？
• 它过去是否扫描过，扫描结果是否已经过期？
• 上次扫描发现了多少漏洞，当前最高风险是什么？
• FOFA、手工录入和 Agent 重复发现的目标是否是同一资产？
• 谁可以查看、修改、扫描或删除它？

只靠一次对话或报告无法稳定回答这些问题。资产管理因此把域名、IP、端口和服务从任务参数提升为可识别、可去重、可统计、可分配的治理对象。

2. 资产管理管的是“对象”，项目管理管的是“上下文”

两者职责不同：

• 资产管理管对象：有哪些域名、IP、端口和服务，它们从哪里来，是否重复，是否扫描，当前风险如何。
• 项目管理管上下文：测试做过什么、沉淀了哪些事实、有哪些关联对话与攻击路径。

资产可以绑定项目，项目对话也可以围绕资产发起，但这种关联主要用于归属和权限。当对话绑定项目后，Agent 的资产查询范围会被服务端强制限制在该项目内；即使工具参数指定其他项目，也不能越界。

3. 从“发现漏洞”走向“管理暴露面”

漏洞是结果，资产是结果发生的载体。只看漏洞数量，会忽略：

• 大量资产可能从未进入扫描范围；
• 某些资产虽然扫过，但结果已经超过 30 天；
• 资产增长速度可能高于安全团队的检查速度；
• 某类协议或服务正在快速增加，而当前扫描策略并未覆盖；
• 漏洞已经修复，但资产仍然存在，下一次变化仍可能引入新风险。

因此，资产概览除了总量，还统计 IP、域名、端口、近 7 天发现量、7/30/90 天变化、扫描覆盖和协议分布。核心不是证明发现了多少漏洞，而是说明覆盖了多少对象、遗漏了多少对象。

二、这次新增的，不只是一份资产清单

CyberStrikeAI 的资产管理目前由三个入口组成：资产概览、资产库和信息收集。

1. 资产概览：先看覆盖缺口，再看资产数量

资产概览提供四类视角：

• 资产基线

• 资产总数；

• 去重后的 IP 数量；

• 去重后的域名数量；

• 有效端口种类；

• 近 7 天新近发现的资产数量及其占比。

• 态势变化（7/30/90 天）

• 每日新增资产；

• 每日转为停用状态的资产；

• 每日新增漏洞；

• 每日新增的高危及严重漏洞。

• 扫描覆盖

• 至少完成过一次扫描的资产；

• 近 30 天完成过扫描的资产；

• 从未扫描的资产；

• 超过 30 天未复查的资产；

• 总体覆盖率与近 30 天覆盖率。

• 协议分布：主要协议、资产数量及占比。

2. 资产库：让目标成为可维护的长期对象

一条资产记录可保存：

• 完整 URL 或 Host；
• IP、域名、端口和协议；
• 页面标题、服务或产品指纹；
• 国家/地区、省份/州、城市；
• 来源及来源查询条件；
• 活跃或停用状态；
• 标签；
• 所属项目；
• 首次发现、最近发现、创建与更新时间；
• 上次扫描时间；
• 上次扫描关联的对话、任务队列和子任务；
• 相关漏洞数量；
• 当前风险等级。

Web 端支持搜索主机、IP、域名、标题、服务或标签，并按状态、项目筛选。后端与 Agent 工具还支持来源、标签、端口、扫描状态、发现和扫描时间范围等结构化条件。例如：

查询生产标签下从未扫描的资产，或按上次扫描时间升序找出最久未复查的目标。

按上次扫描时间升序时，从未扫描的资产会排在最前。“没有扫描记录”意味着风险未知，不应被空值排序隐藏。

3. 信息收集：把 FOFA 结果真正沉淀下来

FOFA 结果现在可以单条或批量入库。系统会保存 Host、IP、端口、域名、协议、标题、Server 指纹、地区、来源和原始查询语句。相同目标再次出现时，更新最近发现时间和非空信息，而不是重复追加。FOFA 因而从一次性搜索工具变成资产发现入口。

三、怎么用：从发现到回写的完整路径

场景一：手工纳管一个已知目标

进入“资产管理 → 资产库”，点击“新增资产”。

最少只需要输入一个目标，例如：

https://example.com:8443
example.com
1.1.1.1:443
[2001:db8::1]:443

对于可以识别的输入，前端会自动拆解 URL、域名、IP、端口和协议。HTTP、HTTPS、SSH、FTP、SMTP、RDP、MySQL、PostgreSQL、Redis、MongoDB 等常见端口还可以辅助推断协议。

还可补充项目、标签、标题、服务指纹、地理位置和状态。

保存后，如果目标、端口、协议与已有记录构成同一去重键，系统不会机械地再建一条记录，而是安全合并非空字段并更新最近发现时间。

场景二：从 FOFA 发现一批互联网暴露资产

首先在配置或系统设置中填写 FOFA 邮箱和 API Key，也可以通过 FOFA_EMAIL、FOFA_API_KEY 环境变量注入。环境变量优先于配置文件，密钥由后端使用，不需要暴露到浏览器。

进入“资产管理 → 信息收集”，输入或生成 FOFA 查询语句，人工确认范围后执行查询，勾选结果并点击“入库所选”。系统会返回新增、更新和跳过数量。

不要把全部搜索结果直接视为自有资产。应先用组织域名、证书、网段或产品指纹缩小范围，确认归属后再添加标签、绑定项目并发起扫描。

场景三：对单个资产发起深度分析

在资产列表中点击“扫描”，系统会创建一个新对话，把资产目标和资产 ID 注入提示词，并将该对话与资产关联。

默认提示要求 Agent 检查暴露服务、已知漏洞、弱口令和常见 Web 风险，通过 record_vulnerability 保存确认结果，并调用 complete_asset_scan 回写扫描状态。

用户可以在发起前修改提示词，例如：

请对 {{target}} 做一次低影响复查，只验证 80/443 暴露面、
TLS 配置、组件版本与已知漏洞，不执行弱口令尝试。
确认的问题通过 record_vulnerability 保存，
完成后调用 complete_asset_scan(id={{asset_id}})。

模板支持 {{asset_id}}、{{target}}、{{host}}、{{ip}}、{{domain}}、{{port}}。资产信息由系统注入，扫描强度与授权边界仍由使用者决定。

场景四：批量创建扫描任务

当需要检查一批资产时，可以在资产库中跨页选择目标，然后点击“创建扫描任务”。

系统会为每个资产渲染独立任务，创建任务队列并建立资产—队列—子任务关联；用户可立即执行，并在任务管理中查看状态。

当前资产页创建的队列采用手动调度模式、单并发执行和 Eino 单 Agent 模式。单并发是一个偏保守的默认值：它可以降低批量安全测试对目标和本机资源的瞬时压力，也让任务与资产之间保持清晰的一一对应关系。

如果一批资产来自同一个项目，创建的对话或任务会继承该项目；如果选择的资产跨多个项目，则不会擅自绑定到某一个项目。

场景五：从漏洞回到资产

扫描完成后，资产列表会展示相关漏洞数量和当前风险等级。点击漏洞数量，可以跳转到与该资产最近一次扫描关联的任务或对话结果。

风险等级根据关联扫描中的未关闭漏洞动态计算：critical、high、medium、low、info；没有开放风险时为 normal，尚未扫描时为 unassessed。

已修复、误报或忽略的漏洞仍保留在历史数量中，但不会继续抬高当前风险等级。

资产风险因此是最近扫描事实的投影，而不是人工维护的静态标签。

四、技术实现：如何保证资产数据可用，而不只是“存得进去”

1. 数据模型：同时记录身份、来源、时间与行动关系

资产表以 UUID 作为主键，并建立唯一去重键。核心字段大致分成四组。

身份与连接信息：

host / ip / domain / port / protocol

识别与来源信息：

title / server / country / province / city
source / source_query / tags

治理信息：

project_id / status / owner_user_id
first_seen_at / last_seen_at / created_at / updated_at

行动关联信息：

last_scan_at
last_scan_conversation_id
last_scan_queue_id
last_scan_task_id

漏洞数量和风险等级没有冗余写死在资产表中，而是在查询资产时，根据最近扫描关联的对话或子任务动态聚合。这样可以避免漏洞状态已经变化、资产上的风险标签却没有同步更新。

数据库仍采用项目现有的 SQLite 存储，并启用 WAL、外键约束、写入忙等待和定期 checkpoint。资产相关的最近发现、扫描时间、IP、域名、状态、所有者和项目字段均建立了索引。旧数据库启动时会自动补充项目和扫描关联字段，不需要用户手工执行迁移脚本。

2. 规范化：把不同入口的输入变成同一种资产

同一个目标可能被写成：

Example.COM
example.com
https://example.com
https://example.com:443/

这些写法容易形成重复记录，因此前后端都会执行规范化。

当前逻辑包括：

• 去除字段首尾空白；
• IP、域名、协议统一转为小写；
• URL 型 Host 自动解析 hostname、协议和端口；
• HTTP/HTTPS 在未显式提供端口时补充 80/443；
• 国际化域名转换为 ASCII/Punycode；
• 标签去空、去重；
• 未填写状态时默认为 active；
• 未填写来源时默认为 manual。

FOFA 的可选结构化字段可能包含占位符、多个值或供应商标识。系统会丢弃无效 IP、域名或协议；只要 Host 有效，就不会因一个脏字段让整批导入失败。

这是一种有意的取舍：必需身份要严格，可选富化信息要有容错。

3. 去重策略：以“目标 + 端口 + 协议”识别服务资产

资产去重键按以下优先级选择目标：

1. 域名；
2. IP；
3. Host。

然后与端口、协议组合：

target | port | protocol

因此，example.com:443/https 和 example.com:80/http 是两条资产：同一主机上的不同服务具有不同暴露面和风险。

当重复资产再次入库时：

• 更新本次提供的非空信息；
• 保留本次没有提供的原有信息；
• 更新最近发现时间；
• 不重置首次发现时间；
• 如果调用者无权更新其他用户拥有的同一资产，则跳过，而不是越权覆盖。

当前去重键全局唯一，不是“每个项目一份同名资产”；项目归属不参与资产身份计算。

4. 校验策略：在灵活输入和数据质量之间找平衡

后端要求 Host、IP、Domain 至少有一个非空，并对结构化字段执行约束：

• 端口范围为 0—65535；Web 编辑器中显式端口要求 1—65535；
• IP 必须能被标准网络库解析；
• 域名会经过 IDNA 处理，并检查总长度、标签长度、连字符位置和合法字符；
• 协议必须符合受限格式；
• 状态只能是 active 或 inactive；
• Host 和页面标题最多 500 个字符；
• 多数结构化文本最多 255 个字符；
• 最多 30 个标签；
• 单个标签最多 64 个字符。

无法可靠拆解但非空的目标可作为“不透明 Host”保存，适配内部代号或非标准地址；系统不会为其推断不可信的 IP、域名、端口或协议。

5. 扫描关联：用 ID 建立证据链，而不是依赖目标字符串

直接比较目标字符串容易错连或漏连：

漏洞目标 == 资产域名

CyberStrikeAI 采用的是执行关系关联：

资产
  → 扫描对话，或批量任务中的子任务
  → 对话中通过 record_vulnerability 保存的漏洞
  → 资产查询时动态统计数量与最高未关闭风险

单资产对话创建后，系统先记录资产与对话 ID 的关系；批量扫描则记录资产、队列 ID 和子任务 ID 的关系。Agent 完成工作后调用 complete_asset_scan，将当前对话回写为该资产的最新扫描。

资产的“有效扫描时间”也不是简单读取一个字段。查询时会优先参考：

1. 关联子任务的完成时间；
2. 关联对话中助手消息的最近更新时间；
3. 资产记录中的回写时间。

这比任务创建时间更接近真实的扫描完成时间。

6. Agent 原生：资产能力本身就是 MCP 工具

资产管理并非只有 Web 页面。系统同时向 Agent 注册了六个内置工具：

• create_asset：新增资产或去重更新；
• get_asset：按 ID 获取完整详情；
• query_assets：分页、筛选和排序；
• update_asset：局部更新；
• delete_asset：删除；
• complete_asset_scan：扫描完成后回写。

query_assets 默认每页 20 条、最多 50 条，只返回摘要；详情由 get_asset 按需获取，超长文本和标签也会截断，避免资产查询挤占模型上下文。

7. 权限边界：页面隐藏不是安全控制，服务端才是

资产权限被拆分为三个动作：

• asset:read：查看资产和汇总；
• asset:write：创建、导入、修改和回写扫描；
• asset:delete：删除资产。

Web 界面会根据权限隐藏或禁用相关入口，但真正的访问控制发生在服务端和 MCP 工具授权层。

资产访问同时考虑：

• 资产所有者；
• 显式资源授权；
• 资产所属项目的所有者；
• 项目的显式授权；
• 当前权限的 all、assigned 或 own 范围。

批量绑定项目采用事务处理：只要所选资产中有一条不存在或超出调用者权限，整批更新都会失败，不会出现一部分成功、一部分未授权的中间状态。

扫描关联也会验证：

• 调用者是否能访问资产；
• 对话是否属于调用者可访问范围；
• 队列是否可访问；
• 子任务是否确实属于指定队列。

权限检查落在服务端，而不只依赖前端按钮是否可见。

五、适用场景

• 外部攻击面持续跟踪：定期用 FOFA 按域名、证书、网段或指纹发现资产，确认归属后入库，观察新增暴露、服务变化和长期未复查目标。
• 项目范围隔离：将资产和对话绑定同一项目，适用于多客户、多业务线及需要严格限定授权范围的测试。
• 高危漏洞应急排查：按服务指纹、协议、端口、标签或项目筛选潜在受影响资产，批量创建低影响验证任务。
• 扫描覆盖治理：使用“从未扫描”“超过 30 天未扫描”“近 30 天覆盖率”识别盲区。覆盖率不是安全率，它只说明已知资产是否被安全流程触达。
• 多人协作：通过 asset:read/write/delete 和资源授权分离查看、维护、删除职责，并继承项目访问范围。

六、当前版本的不足与后续改进方向

这一版优先打通了资产发现、入库、去重、扫描和风险回写的主链路，但离更完整的资产治理仍有距离。以下能力尚未完善，也会是后续持续演进的方向。

1. 资产字段仍偏向安全测试场景

当前模型主要记录安全测试与暴露面信息，尚未覆盖组织架构、业务负责人、部门、SLA、资产重要性、采购、成本、机房、硬件生命周期和云资源账单等字段。目前可以用项目和标签表达部分信息，但还不能替代完整的企业资产模型。

2. 数据源接入仍需扩展

当前支持手工新增、HTTP API、Agent 工具和 FOFA 结果入库，但还没有通用 CSV/Excel 导入向导，也未内置云厂商、Kubernetes、CMDB 或 EDR 同步连接器。

现阶段可通过资产导入 API、MCP 或二次开发接入；后续仍需补充更标准的数据导入和同步能力。

3. 持续发现与存活更新尚未自动化

资产概览中的“最近发现”来自创建或再次导入，当前没有后台任务持续轮询资产并判断其是否在线。

因此，active 和 inactive 目前是管理状态，不是实时存活探测结果。后续还需要完善周期发现、状态校准和变化检测。

4. 跨扫描历史分析仍需加强

资产的相关漏洞和风险等级来自最近一次关联的对话或批量子任务，不是该资产跨全部历史的完整风险仓库。

当前可以回答“最近一次评估结果如何”，但漏洞复发、修复时长、多轮扫描差异和长期风险趋势，还需要更完整的资产—扫描—漏洞历史模型。

使用提示：批量扫描仍需控制授权与影响

批量创建任务前仍应确认：

• 目标归属与书面授权；
• 允许的时间窗口；
• 可接受的请求频率和并发；
• 是否允许口令尝试、漏洞验证或写操作；
• 生产系统的稳定性要求；
• 人机协同审批策略与工具白名单。

CyberStrikeAI 的默认提示强调授权扫描，批量任务默认单并发，但最终测试边界仍应由使用者明确设定。

七、从资产发现到风险回写：攻击面如何保持可见

资产管理加入后，CyberStrikeAI 中的几类对象开始形成一条连续链路：

FOFA / 手工 / API / Agent 发现
            ↓
      规范化与去重入库
            ↓
       标签与项目归属
            ↓
   单资产对话 / 批量任务
            ↓
      Agent 调用安全工具
            ↓
 record_vulnerability 保存证据
            ↓
 complete_asset_scan 回写资产
            ↓
 风险等级、漏洞数量、覆盖率更新
            ↓
       下一轮筛选与复查

这条链路把 FOFA 结果、对话中的域名、任务里的 IP 和报告里的 URL 归一为有状态的资产。新增资产扩大已知边界，重复发现刷新最近出现时间，扫描改变风险状态，长期未复查则暴露覆盖缺口。

八、从今天开始，可以这样建立第一套资产基线

如果是第一次使用这项功能，可以从一个小范围开始：

1. 先划定一组明确授权的域名、IP 或网段；
2. 手工加入几个核心目标，验证资产识别与去重结果；
3. 配置 FOFA，从一个窄查询开始，确认结果归属后再入库；
4. 使用标签区分生产、测试、核心业务、外网等范围；
5. 先对单个低风险目标发起对话扫描，确认工具和回写流程；
6. 查看漏洞是否正确落库、风险等级是否更新；
7. 再对少量资产创建单并发批量任务；
8. 最后用“从未扫描”和“超过 30 天未扫描”建立复查清单。

不要一开始就追求全量导入。资产管理的质量取决于身份是否稳定、归属是否准确、状态是否可信；经过确认的 100 条基线，通常比来源混乱的 10 万条清单更有价值。

结语：资产不是扫描前的一行参数

在很多安全工具里，资产只是命令行里的 target。对持续安全运营而言，它应当有稳定身份、来源、状态、扫描记录和风险归属。

先知道自己拥有什么，才能知道哪里暴露、哪里漏扫，以及风险究竟落在哪里。

CyberStrikeAI 资产管理所做的，是把散落在搜索结果、任务参数和报告里的目标，还原成一张可以持续核对的攻击面。