A build graph is a map of a repository's projects and tasks and how they depend on each other. Build tools use it to decide what to run and what to cache. Security teams can use the same map to scope scans, estimate the blast radius of a vulnerable package, and notice new dependency edges.
Definitions
- Project graph: the projects in a workspace and the dependencies between them. Nx's documentation says the projects form a graph known as the Project Graph, and that Nx uses it to decide which tasks to run and when results can be restored from cache.
- Task graph: a separate graph of tasks and their dependencies, based on the project graph, which determines how tasks are executed.
- Affected set: the projects that depend, directly or through others, on the files a change touched.
Nx also states that the graph stays up to date because it is calculated by analyzing source code, and that you can click on a dependency line to find which files created the dependency. Other build systems model the same idea in their own way.
Why a security person should read it
- Scoping scans. If a change touches a shared library, every project that depends on it is in play. The graph gives you that list without guessing.
- Blast radius. When a package has a vulnerability, the graph shows which services reach it through internal packages. It is a starting point, not proof of exploitability, so combine it with reachability analysis.
- Boundary review. A new edge from the public web app to an internal admin package is a design decision. Seeing edges added in a pull request is a cheap review signal.
- Cache trust. The graph decides what is restored from cache. If it is wrong, a stale result can stand in for a real one. See Bazel sandboxing and undeclared inputs.
What happens during a migration
Moving to a new build tool or merging repos changes the graph. Dependencies that were published versions in separate repos become local links. A change in one package now triggers builds and scans in others. Three questions to ask:
- Does the new graph include every project, including ones with no build target?
- Does any scan that used to run on every push now run only for affected projects? Our guide on scanning only affected packages with Nx and Turborepo covers the risk of that shortcut.
- Is the graph computed from source or from a hand-written file that can go stale?
A quick exercise
Pick one shared package. List the projects that depend on it according to the graph, then check that list against what your scanner reports for that package. Differences point to either a graph gap or a scanner gap. Both are worth fixing.
For internal-package questions, see reachability across internal packages in a monorepo.
Try it yourself
Click through it at your own pace, or open it full screen.
Follow how a vulnerable package connects to code that actually calls it, and compare that with a plain list of dependencies.
Safeguard's reachability analysis works at the call level to separate findings that matter from ones that do not, and its SBOM and dependency scanning cover the dependency side.
Quick check
Is a build graph the same as an SBOM?
No. A build graph maps your own projects and tasks. An SBOM lists components, including third-party ones, in a built product.
Does the affected set prove a service is vulnerable?
No. It shows what depends on a changed package. Exploitability still needs analysis.
Sources
Last reviewed: 19 October 2026.
