GitLab Orbit 新演示怎样串联漏洞涉及的项目和责任人

GitLab 在 2026 年 10 月 29 日发布的 Orbit 演示，解决的是漏洞处置里最费人工的一段：发现组件有问题之后，怎样快速知道它落在哪些项目、经过哪些交付链路，以及最后应该找哪个团队负责。Orbit 的重点不是再做一个扫描器，而是把 GitLab 已经拥有的代码、合并请求、流水线、安全发现、环境和所有权关系放进一个可查询的上下文图谱。

官方地址：https://docs.gitlab.com/orbit/

一句话理解：扫描器告诉你“有漏洞”，Orbit 试图补上“影响哪些项目、改动从哪里来、谁能处理、是否已经到达环境”这张关系图。它能缩短人工拼表时间，但代码仓库里的声明仍不能代替运行环境清单。

Orbit 补上的不是另一个扫描器

我看这次演示时最明显的变化，是问题入口从“分别打开几个系统”变成了“围绕一个漏洞提问”。传统依赖扫描、容器扫描和代码搜索各自能提供一部分证据，却不天然知道某个项目对应哪个服务、某次合并请求又影响了哪条流水线。Orbit 把这些对象放到同一图谱后，Agent 可以围绕关系查询，而不是反复抓取接口再人工拼接。

官方文档把 Orbit 定义为 GitLab 数据和代码的生命周期上下文图谱。它索引的不是单一仓库，而是项目、合并请求、流水线、工作项、安全发现和源代码等对象；答案还会受既有 GitLab 权限过滤。这个定位很重要：它提供的是有上下文的查询入口，不是自动替安全团队做风险定级或补丁决策。

新演示怎样串联项目与责任人

演示里的自然语言问题可以拆成四个互相咬合的查询对象：先找出包含目标组件的项目，再确认组件是通过源码、基础镜像还是依赖文件进入项目；随后关联引入它的合并请求和构建流水线，最后把项目或服务映射到负责人。这样得到的不是一张孤立的漏洞列表，而是一份可以分派工作的影响面清单。

例如，安全团队可以把问题表达为“在这个顶层组里，哪些项目包含 PHP，按子组列出项目和负责人”。如果扫描结果已经建立，还可以继续询问某个 CVE 影响哪些项目、哪些环境，以及相关修复是否进入生产。这里的关键不是照搬一句提示词，而是让问题同时包含范围、组件、责任归属和交付状态。

# 下面是向 Agentic Chat 描述查询目标的自然语言示例，不代表本机执行命令
Use Orbit to map the blast radius of the vulnerable component in this group.
# 结果应优先整理项目、所属子组、负责人和相关流水线，便于分派修复任务
List affected projects with owners and the pipelines that build them.

如果团队使用外部 Agent，官方资料给出的连接方式包括 MCP 或 GitLab CLI；GitLab Duo Agent Platform 则可以直接查询 Orbit。无论入口是哪一种，查询的应是同一份图谱，权限也应沿用 GitLab 现有角色，而不是为了让 Agent 看得更多而另建一套越权数据源。

我会怎样把演示落到一次排查

1. 先限定图谱范围。从一个顶层组或明确的项目集合开始，避免把无关团队的结果混进处置清单。
2. 再确认组件来源。结合代码搜索查看 Dockerfile 的基础镜像、Composer 或其他依赖文件，区分“声明存在”和“实际构建进去”。
3. 把发现和交付关系接起来。将安全发现关联到引入它的合并请求、构建流水线以及已知环境，形成可分派的修复顺序。
4. 最后补运行时库存。Orbit 主要回答 GitLab 中被索引的生命周期信息；手工服务器、外部镜像仓库或配置管理系统里的实例，仍要与运行库存交叉核对，优先确认互联网暴露服务。

这套顺序也解释了为什么“列出所有受影响项目”比“找到一个包含漏洞的仓库”更有价值：前者能直接生成责任分工，后者通常还要安全、平台和研发三方继续手工对表。

正式可用范围与需要保留的边界

GitLab 官方文档显示 Orbit 在 GitLab 19.5 转为正式可用；公告称 Premium 和 Ultimate 客户可以使用，GitLab.com 先行，Self-Managed 与 GitLab Dedicated 按后续安排到达。具体实例是否已经开放，应以自己的 GitLab 文档、租户能力和管理员设置为准。

另外，官方公告中的速度、Token 和重试次数是 GitLab 在特定任务与模型条件下的测试结果，不应直接当成每个团队的固定收益。真正上线前，建议先选一个经常需要跨项目追踪的共享组件，记录查询范围、权限角色、责任人字段和运行时库存来源，再决定是否把 Orbit 纳入漏洞响应流程。

相关问题

Orbit 会替代依赖扫描和容器扫描吗？

不会。扫描器负责发现组件或镜像中的风险，Orbit 负责把发现与项目、交付链路和责任归属关联起来，两者是互补关系。

Orbit 的答案是否能代表所有正在运行的实例？

不能直接这样理解。仓库默认分支、扫描结果和 GitLab 生命周期数据之外的手工服务器、外部镜像或运行时漂移，仍需使用配置管理、云平台或资产系统核对。

外部 Agent 能直接看到整个 GitLab 组织吗？

不应默认可以。官方说明强调答案会遵循既有 GitLab 权限；连接方式改变的是入口，不应改变查询者原本能访问的数据范围。

来源说明：GitLab 官方公告与 Orbit 文档用于核实功能范围、发布日期、连接方式和权限边界。本文只把公告中的演示思路改写为排查框架，不把演示画面当作真实环境证据。