Take the targets that own the changed files, ask Bazel for their reverse dependencies, and scan the services those targets belong to. Keep a scheduled full scan too, because a new advisory can affect code that nobody on the team touched, and keep the check cheap.
The idea
In a graph based build, you can ask which targets depend on a changed target. That list is the blast radius of the change, and it tells you where a scan matters. This is the same idea behind running only affected tasks in other monorepo tools: compute the affected set from the dependency graph and skip the rest.
Bazel's query guide describes the rdeps function, which finds the reverse dependencies of a set of targets within the transitive closure of a universe you choose. For example, if you are going to change some code, you might want to know what other code you are about to break. The same answer tells you what to rescan.
Steps
- Get the changed files for the pull request from git, comparing against the merge base with the target branch.
- Map each changed file to its owning target. Bazel can do this for source files, as the query guide explains for file labels.
- Run a reverse dependency query for those targets within the universe of your repository, or the portion you care about.
- From the result, collect the deployable targets: services, binaries, images.
- Scan the dependency declarations of each deployable target, once per target.
- Post one summary comment on the pull request.
Where the approach has limits
| Limit | Handling |
|---|---|
| Third party dependencies declared in a central file | A change to that file affects every target that uses the changed package; query accordingly |
| Files outside the build graph | Treat as always affecting a full scan |
| Very large query results | Cache and scope the universe |
| Query cost on huge repositories | Run it on a dedicated runner with a warm cache |
The second row matters during onboarding. In a legacy monorepo, some code is built by scripts outside Bazel. Those directories need path based rules instead.
Combine with a scheduled scan
Affected target scanning only reacts to change. Pair it with a daily or weekly scan of the entire default branch, so a new advisory on an old package is caught even if nothing near it changed.
Check that it works
After you set it up, test it. Create a branch that changes a shared library, confirm that dependent services are scanned and look at the list of targets. Then change an isolated service and confirm only it is scanned. If the first test touches fewer services than you expect, your mapping misses edges.
Keep the test as a recurring check. Build graphs change, and the mapping can quietly break.
Where Safeguard fits
Safeguard policies and gates apply to the pull request, and continuous monitoring covers the full branch on a schedule, so affected target scanning and the scheduled scan can feed one view. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Does this work for non Bazel build systems?
The idea carries over. Many tools can compute affected projects from a graph. The query syntax differs.
Is the affected set always safe to trust?
Only as far as your graph is complete. Test it with a change to a shared library and verify dependents are included.
Sources
Last reviewed: 19 October 2026.
