Building an Exposure Baseline: A Repeatable ZoomEye Method for Vulnerability Response

Building an Exposure Baseline: A Repeatable ZoomEye Method for Vulnerability Response

建立暴露基线:一种用于漏洞响应的可重复 ZoomEye 方法

Building an Exposure Baseline: A Repeatable ZoomEye Method for Vulnerability Response Exposure measurement is most useful when it is done before it is needed. An organization that runs its first internet-measurement query during an incident spends the first hours of that incident learning how to use the tool. This article describes a repeatable method, using counts collected on 2026-09-22 across a set of products that appeared in September 2026 vulnerability reporting. 建立暴露基线:一种用于漏洞响应的可重复 ZoomEye 方法。暴露测量在需要之前进行最为有效。如果一个组织在发生安全事件时才首次运行互联网测量查询,那么事件发生后的最初几个小时将浪费在学习如何使用工具上。本文介绍了一种可重复的方法,使用了 2026 年 9 月 22 日收集的统计数据,涵盖了 2026 年 9 月漏洞报告中出现的一系列产品。

A baseline measurement set All counts were collected through the ZoomEye SDK with sub_type=“all” and a page size of one. Each query was run against a specific product fingerprint rather than a vendor name. 基线测量集:所有统计数据均通过 ZoomEye SDK 收集,参数设置为 sub_type=“all” 且页面大小为 1。每个查询都是针对特定的产品指纹而非厂商名称进行的。

ProductQueryMatched assets
GitLabapp=“GitLab”1,316,021
MikroTik RouterOSapp=“RouterOS”2,856,916
Citrix NetScalerapp=“Citrix NetScaler”239,130
ConnectWise ScreenConnectapp=“ScreenConnect”93,338
LiteLLMapp=“LiteLLM”36,177
JFrog Artifactoryapp=“JFrog Artifactory”17,886
SonicWall SMA1000app=“SonicWall SMA1000”5,489
Kestraapp=“Kestra”136

What a baseline like this is for The purpose is not to produce a risk score. It is to establish, in advance, three facts that are needed during an incident. First, which query represents each product. The baseline records the exact fingerprint string that produces a meaningful result. When a vulnerability is disclosed, the analyst does not have to guess whether app=“SonicWall” or app=“SonicWall SMA1000” is the right query; the baseline already answers that, and it also records that the two differ by five orders of magnitude. 此类基线的用途:其目的不是为了生成风险评分,而是为了提前确定在事件发生期间所需的三个事实。首先,确定哪个查询代表每个产品。基线记录了能产生有效结果的精确指纹字符串。当漏洞披露时,分析师无需猜测 app=“SonicWall” 还是 app=“SonicWall SMA1000” 才是正确的查询;基线已经给出了答案,并且记录了两者之间存在五个数量级的差异。

Second, the order of magnitude for each product. Knowing that Kestra sits in the low hundreds and that RouterOS sits in the millions is useful context. A small population does not mean low risk, as the Kestra command injection demonstrates, but it does mean the population is specialized and that an organization running it is more likely to be identifiable. 其次,每个产品的数量级。了解 Kestra 处于几百的量级,而 RouterOS 处于几百万的量级,是有用的背景信息。正如 Kestra 命令注入漏洞所证明的那样,较小的用户群体并不意味着低风险,但它确实意味着该群体是专业化的,且运行该产品的组织更容易被识别。

Third, which products cannot be measured this way. The baseline should record negative results as well as positive ones. Framework-level components such as Starlette return no fingerprint, and that absence is a finding: it tells the organization that for that dependency, the inventory has to come from a software bill of materials rather than from an internet scan. 第三,确定哪些产品无法通过这种方式测量。基线不仅应记录正向结果,还应记录负向结果。像 Starlette 这样的框架级组件不会返回指纹,这种缺失本身就是一个发现:它告诉组织,对于该依赖项,资产清单必须来自软件物料清单(SBOM),而不是互联网扫描。

The method Enumerate the products the organization actually runs. Start from the asset inventory, not from the vulnerability news. A baseline built from a news cycle will miss everything the organization uses that is not currently in the headlines. 方法:列举组织实际运行的产品。从资产清单开始,而不是从漏洞新闻开始。基于新闻周期构建的基线会遗漏组织正在使用但目前未上头条的所有内容。

For each product, test candidate fingerprint strings. Run the short and long forms, and test a deliberately wrong query such as the bare vendor name to confirm that a near-zero result means the fingerprint does not exist rather than that the product is rare. 对于每个产品,测试候选指纹字符串。运行短格式和长格式,并测试一个故意错误的查询(例如仅使用厂商名称),以确认接近零的结果意味着指纹不存在,而不是该产品非常罕见。

Record the query, the scope parameter, the collection timestamp and the count together. A count without its query is not reproducible, and a count without its timestamp cannot be compared with a later measurement. 将查询、范围参数、收集时间戳和统计数量记录在一起。没有查询的统计数据是不可复现的,没有时间戳的统计数据无法与后续测量进行比较。

Note the deployment pattern where it is visible. Comparing a fingerprint with and without a port restriction, as the LiteLLM measurement shows, reveals whether the population is typically exposed directly or proxied. 注意可见的部署模式。正如 LiteLLM 测量所显示的那样,比较有无端口限制的指纹,可以揭示该群体通常是直接暴露还是通过代理暴露。

Record the negative results explicitly. A product with no usable fingerprint is a product whose exposure cannot be tracked this way, which is itself an actionable finding. 明确记录负向结果。没有可用指纹的产品意味着其暴露情况无法通过这种方式追踪,这本身就是一个可操作的发现。

Re-run the baseline on a schedule. Fingerprint coverage changes, and so does the population. 按计划重新运行基线。指纹覆盖范围会发生变化,用户群体也会随之改变。

Using the baseline during an incident When a vulnerability is disclosed, the baseline answers the scoping question in minutes rather than hours. The analyst looks up the affected product, uses the recorded query, and gets a comparable number to the baseline. The comparison is meaningful because both measurements used the same query and scope. 在事件期间使用基线:当漏洞披露时,基线可以在几分钟而非几小时内回答范围界定问题。分析师查找受影响的产品,使用记录的查询,并获得与基线可比的数字。这种比较是有意义的,因为两次测量都使用了相同的查询和范围。

The baseline does not answer the question that matters most, which is how many of the organization’s own instances are affected. That requires internal inventory and version data. What the baseline provides is the context in which that internal number can be interpreted: whether the product is common or specialized, whether the population is growing, and whether the organization’s own deployment is typical. 基线无法回答最重要的问题,即组织自身有多少实例受到影响。这需要内部资产清单和版本数据。基线提供的是解读内部数字的背景:产品是通用的还是专业的、用户群体是否在增长、以及组织自身的部署是否典型。

Where ZoomEye fits ZoomEye supports the fields needed for this method: app for product fingerprints, port and service for deployment pattern, is_ipv4 and is_ipv6 for address family scope, and vul.cve for CVE association coverage. Running the same query with different scope parameters is what makes the comparison meaningful, and recording those parameters alongside the count is what makes the baseline reproducible. The platform’s limitation is consistent across every measurement in this article: it sees what is network-visible, which excludes version information, internal-only deployments, and framework-level components. A baseline built on ZoomEye is a baseline of internet-visible exposure, and it should be labeled as such. ZoomEye 的作用:ZoomEye 支持此方法所需的字段:用于产品指纹的 app,用于部署模式的 port 和 service,用于地址族范围的 is_ipv4 和 is_ipv6,以及用于 CVE 关联覆盖的 vul.cve。使用不同的范围参数运行相同的查询使比较具有意义,而将这些参数与统计数量一起记录则使基线具有可复现性。该平台在本文的每次测量中都存在一致的局限性:它只能看到网络可见的内容,这排除了版本信息、仅限内部的部署以及框架级组件。基于 ZoomEye 构建的基线是互联网可见暴露的基线,应以此进行标注。

Limitations Counts were collected on 2026-09-22 with sub_type=“all” and pagesize=1, and they change as the platform rescans. Fingerprint coverage differs by product and is maintained by the platform. None of these queries establishes that a specific asset is vulnerable, and the counts do not represent the total install base of any product. 局限性:统计数据于 2026 年 9 月 22 日收集,参数为 sub_type=“all” 和 pagesize=1,它们会随着平台的重新扫描而变化。指纹覆盖范围因产品而异,并由平台维护。这些查询均不能确定特定资产是否存在漏洞,且统计数量也不代表任何产品的总安装基数。

References 参考资料

  • ZoomEye official search syntax reference, covering the app, port, service, is_ipv4, is_ipv6 and vul.cve fields.
  • ZoomEye 官方搜索语法参考,涵盖 app、port、service、is_ipv4、is_ipv6 和 vul.cve 字段。
  • CISA, Known Exploited Vulnerabilities Catalog, entries added September 2, 8, 11 and 12, 2026. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
  • CISA,已知被利用漏洞目录,2026 年 9 月 2 日、8 日、11 日和 12 日添加的条目。
  • iThome, “CISA warns of exploitation of known vulnerabilities in SonicWall, JFrog Artifactory, LiteLLM and other systems,” September 3, 2026. https://www.ithome.com.tw/news/178657
  • iThome,“CISA 警告 SonicWall、JFrog Artifactory、LiteLLM 等系统存在已知漏洞被利用”,2026 年 9 月 3 日。
  • A5站长网, “Three JFrog Artifactory vulnerabilities exploited in the wild, added to CISA must-patch list,” September 16, 2026. https://m.admin5.com/article/20260915/16702766.shtml
  • A5 站长网,“三个 JFrog Artifactory 漏洞在野外被利用,已加入 CISA 必须修补列表”,2026 年 9 月 16 日。