GitLab Orbit: Find vulnerability blast radius without the manual hunt

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:

1. Find every PHP project. In GitLab Duo Agentic Chat, ask: “Use Orbit to map the blast radius of PHP in this group. List every project that contains PHP code, grouped by subgroup, with owners.”
2. Confirm the base image and version. Use exact code search at the top-level group with regular expression mode on. Run lang:Dockerfile ^FROM.*php to find container base images, and file:composer\.json$ to find Composer projects with no Dockerfile. Compare each FROM tag with the fixed versions.
3. Find open findings. Once scans have run, ask Agentic Chat to collect every container scanning finding for CVE-2026-109618 and CVE-2026-109619 across the group from the vulnerability report. This requires Ultimate and the Security Manager role.
4. Check against what’s running. Orbit and code search cover what your repositories declare on the default branch. Compare that list with your runtime inventory from configuration management or cloud tooling, starting with internet-facing services, since PHP can also run on hand-built servers outside any repository.

The PHP2Shell remediation guide covers fixed versions and how to check for compromise. Teams on GitLab Self-Managed or GitLab Dedicated can start with the guide's advanced search and repository languages API steps until Orbit reaches their instance.

Run the same check for any shared component

The steps above work beyond PHP. When a widely used library ships a security fix, a package you depend on is flagged as malicious, a CI template many projects inherit needs a change, or an internal SDK ships a breaking security upgrade, you start with the same question: what depends on it, and who owns it? Orbit answers from the same graph each time, so your team starts from a list instead of a search.

Map your blast radius before the next disclosure

GitLab Orbit is now generally available for Premium and Ultimate customers, starting with GitLab.com today and reaching Self-Managed and GitLab Dedicated over the coming weeks. Customers can try it free for 30 days through their GitLab account team. If you're new to GitLab, talk to our team about getting started with a paid plan, and we can add an Orbit trial as part of it.

Check out the documentation to get started. For a broader view of your security posture, request your GitLab Security Standard assessment to see how blast radius mapping fits into the rest of your security program. If your teams run PHP, start with the PHP2Shell remediation guide and upgrade now.