Upwind 数据地图 / Upwind Data Map
基于
packages/console前端代码库梳理，2026-09-14。 所有"意义"与"UI 位置"均来自代码中的实际路由、枚举与产品文案，未标 ❓ 的部分可在前端找到依据。Derived from the
packages/consolefrontend codebase, 2026-09-14. Every "meaning" and "UI location" comes from actual routes, enums, or product copy in the code. Anything not marked ❓ is verifiable in the frontend.
图例 / Legend
| 标记 | 含义 | Meaning |
|---|---|---|
| 🚩 | feature flag 控制，默认不可见 | flag-gated, invisible by default |
| 🧪 | BETA | BETA |
| ❌ | 未实现 | not implemented |
| ❓ | 前端无法确认上游，需问后端 | upstream unverifiable from the frontend |
中文
主表
| 数据 | UI 在哪看 | 谁采集 | 怎么拿 / 何时拿 | 这批数据的意义 |
|---|---|---|---|---|
| 进程 / 文件 / 网络流 / syscall | Threats → Investigation → Runtime events 🚩 | Sensor | eBPF 挂内核，持续流式推 | 机器上正在发生什么 |
| 网络拓扑 | Inventory → Runtime map | Sensor | 从真实包还原通信关系，持续 | 谁真的在跟谁通信（≠ 配置上允许通） |
| 威胁检测 | Threats → Detections / Stories | Sensor | 事件流 → policy-enforcer 匹配 → detection → 聚成 story | 有人正在干坏事 |
| SSH 会话 | Threats → SSH sessions（或 Investigation 下） | Sensor | 录制终端操作，持续 | 人在机器上敲了什么，可回放 |
| API 路由 + schema | Inventory → APIs | Sensor | 从真实流量提取，持续 | 到底存在哪些接口 —— 含影子 API |
| API 事件 | Threats → Investigation → API events 🚩 | Sensor | 流量记录，持续 | 谁调了哪个接口 |
| 包是否被加载（in-use） | Vulnerabilities 的 in-use 过滤器 | Sensor | 看进程有没有 load 这个包，持续 | 漏洞包到底用没用 —— 几千条收敛到几十条 |
| — | — | — | — | — |
| 漏洞 | Vulnerabilities → Findings | Cloud Scanner | assume role → 起 EC2 ASG → 打快照拆包 → 比对漏洞库。每 N 小时 / 新实例启动 / 手动 | 运行中的资产上装了什么有漏洞的包 |
| 敏感数据分类 | Data → Data classifications 🚩 | Cloud Scanner（接口路径就是 cloud-scanner/） | 抽样读对象；连数据库读到表级（RDS 是它的扫描 scope）。每 N 小时 | 哪个桶 / 哪张表里有 PII |
| 环境里的 Secrets | Data → Secrets | Cloud Scanner | 扫磁盘快照，每 N 小时 | 躺在服务器磁盘上的密钥 |
| 恶意软件 | 并入资产 / 漏洞视图 | Cloud Scanner | 扫快照，每 N 小时 | 资产上有没有恶意文件 |
| — | — | — | — | — |
| 资产清单 | Inventory → Catalog / Graph / Orgs & accounts | assume role 后调云管理 API ❓跑在哪台机器上前端看不出 | DescribeInstances / ListBuckets 等，周期性 | 我有什么 —— 所有百分比的分母 |
| 配置 / CSPM | Configuration → Findings | 同上 ❓ | 拉配置元数据 → 每条 rule 跑一段 Rego → 落 finding。周期性 + 手动重评估 | 这个资源违反了哪条合规规则 |
| IAM / 权限结构 | Identities；Inventory → Identities | 同上 + Agentless K8s（集群 RBAC） | 拉 IAM role / SSO permission set / GCP SA / K8s ServiceAccount + RoleBinding，周期性 | 谁能对什么做什么 |
| 集群配置 / 工作负载清单 | Inventory → Catalog（K8s 分组） | Agentless K8s | 不装 Sensor，直连 EKS 控制面（公网或 SSM），周期性 | 集群里有什么，不用装 agent |
| 技术栈 / EOL / EOS | Inventory → Technologies / End of life 🚩 | 资产盘点 | 从清单推导，周期性 | 哪些东西已停止支持 —— 审计必问，不需要 CVE |
| SBOM（包清单） | Inventory → SBOM explorer | 资产盘点 ❓上游是 Sensor / agentless / 合并，看不出 | 按云账号聚合，周期性 | 哪些资源用了 log4j —— 但只覆盖已部署的 |
| — | — | — | — | — |
| 云操作审计 | Threats → Investigation → Cloud events | Integrations（出站拉） | 存厂商凭证 → 调 API 拉 CloudTrail / Azure Activity / Entra / GCP audit，周期性 | 谁用什么云凭证做了什么操作 |
| K8s 审计日志 | Threats → Investigation → Kubernetes events 🚩 | ❓上游未确认 —— 可能是 Sensor、Agentless K8s，或经 CloudWatch 走云日志集成 | 周期性 | 谁在集群里改了什么 |
| 身份提供商数据 | Identities | Integrations（出站拉：Okta / Entra / Google） | OAuth2：clientSecret，或 private_key_jwt 现签断言，周期性 | 组织里有哪些人、在哪些组 |
| Snowflake 资产 | Inventory → Catalog / Graph；Posture → Findings | Integrations 出站拉 🧪 | 周期性 | 数仓也算资产 —— database、warehouse 进清单，能被合规规则一起扫 |
| Databricks 资产 + 数据权限 | Inventory → Catalog / Graph | Integrations 出站拉 🧪 | 周期性 | workspace / catalog / compute 进清单，且每条数据权限能追回背后的云资源（更偏 CIEM，不是 DSPM） |
| — | — | — | — | — |
| IaC 配置错误 | Code → Reviews → IaC | Git App（Integrations 的 version_control 渠道） | 装 Upwind App 拿仓库读权限 → 解析 Terraform / Helm / K8s YAML。PR / push / 定时 / 手动 | 配置错误，在它变成真实资源之前 |
| 代码里的 Secrets | Code → Findings → Secrets | Git App | 扫仓库，同上时机 | 被提交进 git 历史的密钥 |
| SCA — 源码 | Code → Reviews → SCA（Source code） | Git App | 解析 lockfile，同上时机 | 依赖清单里的 CVE |
| SCA — 镜像 | Code → Reviews → SCA（Container images） | CI/CD Scanner | 拆镜像层 + lockfile。构建那一刻。授权是入站推：拿 Upwind 发的 OAuth 凭证上报 | 镜像里的 CVE，以及比上一版新增了哪些 |
| SAST | Code → Findings → SAST | ❌ 未实现，tab 是灰的 | — | （本该是：代码逻辑本身的缺陷） |
| 准入拦截事件 | Threats focus → Admission controller | Admission Webhook | 装在客户集群里，同步阻塞拦截。kubectl apply 那一瞬间 | 谁想往集群里放什么、拦没拦住 |
| — | — | — | — | — |
| 外部暴露验证 | Attack surface → Findings | ASM Engine | 不观测，主动打。Playbook 有 READ / WRITE / EXECUTE 三档。按需触发，可从一条 posture finding 直接发起 | 从公网到底能不能打进来 —— not_vulnerable 能正式关掉一批理论告警 |
| API 漏洞测试 | APIs → Tests 🚩 | ASM Engine | 发真实测试请求，按需 | 这个接口能不能被打穿 |
三种授权方式（横切上表）
| 方式 | 谁在用 | 本质 |
|---|---|---|
| 跨账号 assume role | Cloud Scanner、云 API 拉取、Agentless K8s | CloudFormation 建一套 IAM role（含 OrganizationServiceRoleArn，用来列出组织下所有成员账号），Upwind 去 assume。同一把钥匙，三种用法 |
| 出站：Upwind 存厂商凭证 | Okta、Snowflake、Databricks、GCP logs | clientId + clientSecret，或 clientId + privateKey + kid（每次现签 JWT 断言） |
| 入站：Upwind 发自己的凭证 | GitHub Actions、Slack、Audit Logs | Upwind 作为授权服务器签发 OAuth2 client credentials，第三方拿着调 Upwind API。CI 那个 "Reported via API" 就是这个 |
Sensor / AI Endpoint Sensor 不走以上任何一种 —— 装在机器上，用自己的 sensor 凭证注册。 Auth0 跟以上都无关 —— 那是 Upwind 自己的用户登录 console 用的。
四条规律
- 只有 Sensor 是持续的。 其余全是周期性或事件触发。要实时，必须装 agent。
- 周期性采集器全都配"手动重扫"。 客户修完就想马上看到变绿。
- 同一种数据常有两条独立的路，产品价值在把它们拼起来。 密钥在代码里（Git）vs 磁盘上（Scanner）；漏洞"有没有"（Scanner）vs"要不要紧"（Sensor）。
- 越往下越难拿越值钱。 上半张表"读一下就有"，下半张要么得装 agent，要么得真动手打。
一条易错提醒
Integrations 的分类标签说的是"连的是什么系统"，不是"数据落到哪一页"。 两个已证实的坑：
- GitHub 归
version_control，但数据落 Code（新条目）或 Inventory（旧的 deprecated 条目） - Snowflake / Databricks 归
data_sources，但数据落 Inventory / Findings / Graph，不是 Data 页
待后端确认（❓四处）
- 配置 / 清单的 API 轮询跑在哪 —— Cloud Scanner 上，还是 Upwind 后端？（Data 页接口是
cloud-scanner/，compliance 和 inventory 不是） - K8s 审计日志的上游是谁
- SBOM 包数据是 Sensor、agentless，还是两者合并
- Admission Webhook 怎么装 —— console 里没有安装入口，只有文档链接
English
Main table
| Data | Where in the UI | Who collects | How / when | What it means |
|---|---|---|---|---|
| Processes / files / flows / syscalls | Threats → Investigation → Runtime events 🚩 | Sensor | eBPF in the kernel, continuous push | What is happening right now on a machine |
| Network topology | Inventory → Runtime map | Sensor | Reconstructed from real packets, continuous | Who is actually talking to whom (≠ who's allowed to) |
| Threat detections | Threats → Detections / Stories | Sensor | Event stream → policy-enforcer → detection → aggregated into stories | Someone is doing something bad right now |
| SSH sessions | Threats → SSH sessions (or under Investigation) | Sensor | Terminal recording, continuous | What a human typed on the box, replayable |
| API routes + schemas | Inventory → APIs | Sensor | Extracted from live traffic, continuous | Which endpoints actually exist — including shadow APIs |
| API events | Threats → Investigation → API events 🚩 | Sensor | Traffic records, continuous | Who called which endpoint |
| Package in-use | The in-use filter on Vulnerabilities | Sensor | Did any process load it, continuous | Is this vulnerable package actually used — thousands → dozens |
| — | — | — | — | — |
| Vulnerabilities | Vulnerabilities → Findings | Cloud Scanner | assume role → EC2 ASG → snapshot, unpack, diff vuln DBs. Every N hours / new instance / manual | What vulnerable packages are installed on running assets |
| Sensitive data classification | Data → Data classifications 🚩 | Cloud Scanner (endpoints literally cloud-scanner/) | Sample objects; connect to DBs down to table level (RDS is a scan scope). Every N hours | Which bucket / which table holds PII |
| Secrets in the environment | Data → Secrets | Cloud Scanner | Scan disk snapshots, every N hours | Keys sitting on server disks |
| Malware | Folded into asset / vuln views | Cloud Scanner | Scan snapshots, every N hours | Are there malicious files on the asset |
| — | — | — | — | — |
| Asset inventory | Inventory → Catalog / Graph / Orgs & accounts | Cloud management API after assume-role ❓which compute runs it is invisible | DescribeInstances / ListBuckets etc., periodic | What do I have — the denominator under every percentage |
| Configuration / CSPM | Posture → Findings | Same ❓ | Pull config metadata → run each rule as Rego → emit findings. Periodic + manual re-eval | Which compliance rule this resource violates |
| IAM / permission structure | Identities; Inventory → Identities | Same + Agentless K8s (cluster RBAC) | Pull IAM roles / SSO permission sets / GCP SAs / K8s ServiceAccounts + RoleBindings, periodic | Who can do what to what |
| Cluster config / workload inventory | Inventory → Catalog (K8s grouping) | Agentless K8s | No Sensor; connect to the EKS control plane (internet or SSM), periodic | What's in the cluster, with no agent |
| Tech stack / EOL / EOS | Inventory → Technologies / End of life 🚩 | Asset inventory | Derived from the inventory, periodic | What has already lost support — audit always asks, no CVE needed |
| SBOM (package list) | Inventory → SBOM explorer | Asset inventory ❓Sensor / agentless / merged is invisible | Aggregated by cloud account, periodic | Which resources use log4j — but only covers what's deployed |
| — | — | — | — | — |
| Cloud audit events | Threats → Investigation → Cloud events | Integrations (outbound pull) | Hold the vendor credential → pull CloudTrail / Azure Activity / Entra / GCP audit, periodic | Who used which cloud credential to do what |
| K8s audit logs | Threats → Investigation → Kubernetes events 🚩 | ❓Upstream unconfirmed — Sensor, Agentless K8s, or CloudWatch via a cloud-logs integration | Periodic | Who changed what in the cluster |
| Identity provider data | Identities | Integrations (outbound: Okta / Entra / Google) | OAuth2: clientSecret, or private_key_jwt with a freshly signed assertion, periodic | Who's in the org, in which groups |
| Snowflake assets | Inventory → Catalog / Graph; Posture → Findings | Integrations, outbound pull 🧪 | Periodic | The warehouse counts as an asset — databases and warehouses enter the inventory and get swept by compliance rules |
| Databricks assets + data permissions | Inventory → Catalog / Graph | Integrations, outbound pull 🧪 | Periodic | Workspaces / catalogs / compute enter the inventory, and every data permission traces back to the cloud resource behind it (closer to CIEM than DSPM) |
| — | — | — | — | — |
| IaC misconfigurations | Code → Reviews → IaC | Git App (the version_control channel in Integrations) | Install the Upwind App for repo read access → parse Terraform / Helm / K8s YAML. PR / push / scheduled / manual | Misconfigurations, before they become real resources |
| Secrets in code | Code → Findings → Secrets | Git App | Scan repos, same timing | Keys committed into git history |
| SCA — source | Code → Reviews → SCA (Source code) | Git App | Parse lockfiles, same timing | CVEs in the dependency manifest |
| SCA — images | Code → Reviews → SCA (Container images) | CI/CD Scanner | Unpack image layers + lockfiles. At build time. Authorization is inbound push with an Upwind-issued OAuth credential | CVEs in the image, and which are new vs the previous version |
| SAST | Code → Findings → SAST | ❌ Not implemented, tab greyed out | — | (would be: defects in the code logic itself) |
| Admission events | Threats focus → Admission controller | Admission Webhook | In the customer's cluster, synchronous blocking interception. The kubectl apply instant | Who tried to put what into the cluster, and was it stopped |
| — | — | — | — | — |
| External exposure validation | Attack surface → Findings | ASM Engine | Doesn't observe — attacks. Playbooks have READ / WRITE / EXECUTE modes. On demand, fireable from a posture finding | Can someone actually get in from the internet — not_vulnerable formally closes theoretical alerts |
| API vulnerability tests | APIs → Tests 🚩 | ASM Engine | Sends real test requests, on demand | Can this endpoint actually be broken |
Three authorization mechanisms (cutting across the table)
| Mechanism | Used by | What it is |
|---|---|---|
| Cross-account assume-role | Cloud Scanner, cloud API polling, Agentless K8s | CloudFormation provisions IAM roles (including OrganizationServiceRoleArn, used to list every member account) that Upwind assumes. One key, three uses |
| Outbound: Upwind stores the vendor's credential | Okta, Snowflake, Databricks, GCP logs | clientId + clientSecret, or clientId + privateKey + kid (a freshly signed JWT assertion each time) |
| Inbound: Upwind issues its own credential | GitHub Actions, Slack, Audit Logs | Upwind acts as authorization server and issues OAuth2 client credentials; the third party calls Upwind's API. This is CI's "Reported via API" |
The Sensor and AI Endpoint Sensor use none of these — they're installed on machines and enroll with their own sensor credentials. Auth0 is unrelated to all of this — it's how Upwind's own users log into the console.
Four patterns
- Only the Sensor is continuous. Everything else is periodic or event-triggered. Real-time requires an agent.
- Every periodic collector ships a manual rescan — customers fix something and want it green immediately.
- The same data type usually has two independent paths, and the value is stitching them. Secrets in code (Git) vs on disk (Scanner); "does the vuln exist" (Scanner) vs "does it matter" (Sensor).
- The further down, the harder to get and the more it's worth. The top half is "just read it." The bottom half needs an agent, or an actual attack.
One recurring trap
An integration's category label says what system it connects to, not which page the data lands on. Two confirmed cases:
- GitHub is filed under
version_control, but its data lands in Code (new entry) or Inventory (the old deprecated entry) - Snowflake / Databricks are filed under
data_sources, but their data lands in Inventory / Findings / Graph — not the Data page
Open with the backend (the four ❓)
- Where the config / inventory API polling runs — the Cloud Scanner, or Upwind's backend? (Data's endpoints are
cloud-scanner/; compliance and inventory are not) - The upstream of K8s audit logs
- Whether SBOM package data is Sensor, agentless, or merged
- How the Admission Webhook is installed — no install surface in the console, only a doc link
