GitLab Orbit

A critical vulnerability needs a fix and a map. The fix is usually fast. Finding where the vulnerable component lives, who owns it, and whether it's exposed to the Internet is what costs you time. Most security teams piece that answer together from scanner reports, spreadsheets, and a Slack thread asking who owns a service nobody recognizes, and you stay exposed for every hour that takes.

GitLab Orbit, now generally available, replaces this manual work with a single query. Orbit connects code, merge requests, pipelines, security findings, and ownership in one graph that stays current as your teams ship. Ask which projects are affected and who owns them, and you get an answer in minutes. Agents answer from the graph instead of crawling repositories and stitching together API calls, so they need fewer retries and fewer tokens to get there.

Why scanners alone can't answer the question

PHP2Shell, the set of critical PHP flaws disclosed last week, illustrates the problem. PHP is usually installed as a system package, compiled from source, or baked into a container image, not managed as an application dependency. Vulnerable versions can sit on web servers, in container images, in old CI jobs, or in internal tools nobody remembers building. The fix was a version upgrade. Finding every affected installation took time.

Security tools provide different views of the environment. Dependency scanning identifies vulnerable application dependencies. Container scanning detects vulnerabilities in operating system packages, language dependencies, and other software components. Code search helps locate where images and configurations are referenced. But identifying a vulnerability is only part of the job. Teams still need to know which services are affected, who owns them, which pipelines build and deploy them, and where to apply the fix. That information is often spread across multiple systems.

That leaves your team to connect the dots, each holding a different piece. Your security engineer can assess the severity but may not see every affected system. Your platform engineer owns the base images and CI templates that hundreds of projects depend on, but can't see every project that uses them. Your developers get pulled off their roadmap to search repositories for a component they may not know they own. Your CISO has to tell leadership whether the company is exposed before anyone has a full list.

An attacker only needs to find one vulnerable system. You need to find all of them. Exploiting a vulnerability is now the most common way breaches begin, at 31% in Verizon's 2026 report, and the same report found attackers using generative AI at several stages of an attack. The map needs to exist before the advisory lands.

A first-party graph of your entire SDLC

Orbit draws on the data GitLab already runs on: your merge requests, pipelines, deployments, and vulnerabilities. A CVE in Orbit's graph connects directly to the services, pipelines, environments, and teams it touches. Because the graph is first-party, there's no second system to keep in sync and no new instrumentation to stand up.

Without Orbit, an agent or analyst can usually find the vulnerable code but not the full exposure. Someone assembles that picture by hand, tool by tool, and the gaps show up as the long tail of services nobody checked. With Orbit, one query maps the CVE to the services, pipelines, environments, and owners that depend on it, and the output is a scoped, prioritized list your security team can act on.

Agents without Orbit hit the same wall: they can't see the whole system, so they guess. In GitLab's testing on the same tasks with the same model, agents running through Orbit were up to 11 times faster, used up to 4.5 times fewer tokens, and needed up to 45 times fewer retries. During an incident, faster answers arrive while the team is still triaging, lower token use keeps queries across a large group from becoming a cost problem, and fewer retries mean your team can act on the first answer instead of re-running the question.

Watch the demo to learn how GitLab Orbit can help you understand your exposure:

One graph that connects a CVE to its owner

Blast radius is how far a vulnerability reaches: which projects contain the flawed component, how it got there, who owns those projects, and what changed recently. GitLab already holds most of those facts in separate places, and Orbit connects them. Turn it on for a top-level group, and Orbit indexes projects, merge requests, pipelines, work items, security findings, and source code into one graph of how they relate.

From there, you ask in plain language instead of correlating systems by hand: which projects use this library, which merge requests brought it in, and who owns each project? An agent traverses the graph and answers from indexed project data, and you can audit the graph queries behind each answer.

Access follows the roles you've already set, so people and agents see only what they're permitted to see. GitLab's built-in agents, including the Security Analyst Agent, use Orbit directly, and external agents such as Claude Code and Codex reach the same graph over MCP.

Contain your exposure quickly

After PHP2Shell, leadership's first question is whether you're exposed. Without a map, your answer is "we're checking." With Orbit, your answer is a list: these projects contain PHP, these teams own them, and these pipelines build them.

The first hour with Orbit looks like this: