Ask your build tool for the affected set: the packages that changed plus the packages that depend on them. Nx and Turborepo both do this from the project graph. Scan that set on pull requests, treat a lockfile change as touching everything, and keep a scheduled full scan.
Why changed files are not enough
If libs/shared changes, the services that import it are affected even though none of their files changed. A path filter on one service folder misses that. A graph aware command does not.
What Nx documents
The Nx docs say affected determines the minimum set of projects affected by a change. It identifies changed files with Git, maps them to projects through the project graph, finds projects that depend on the modified ones, and runs the task on that set. It takes a base and a head commit, and the docs recommend setting the base to the latest successful commit on the main branch so every change since the last good run is included.
One detail matters for dependency scanning. By default a lockfile change marks all projects as affected, and an option in nx.json can narrow that.
nx affected -t scan --base=origin/main --head=HEAD
What Turborepo documents
Turborepo uses a filter option. Source control filters are wrapped in square brackets, for example comparing against the previous commit or against the main branch. A leading three dots before a package name selects that package and its dependents. Multiple filters are a union.
turbo run scan --filter=[main...HEAD]
Comparing the approaches
| Need | Nx | Turborepo |
|---|---|---|
| Changed packages only | affected | filter with a git range |
| Plus dependents | Included by the project graph | Three dots prefix on a name |
| Lockfile change | All projects by default, configurable | Check your config and test it |
| Needs git history | Yes, base commit | Yes, the ref in brackets |
Both depend on history being available, see why shallow clones break diff scans.
Lockfile changes
A lockfile change can alter the resolved version of a library used by many packages. That is exactly when a new vulnerability can appear. Do not narrow the affected set for lockfile changes until you have confirmed what your tool does.
A practical split
- Pull request: scan the affected set and fail on new high severity findings.
- Main branch merge: scan the affected set again with the merged state.
- Nightly: scan everything, because advisories change without any commit.
That third point is the one teams forget. New advisories land against code you did not touch. Safeguard supports continuous monitoring so existing dependencies are rechecked as advisories change, and the free scan at https://gold.safeguard.sh/scan is a quick one off check.
Try it yourself
Open the monitoring demo and watch how a package that did not change can still get a new finding.
Click through it at your own pace, or open it full screen.
Quick check
Does affected scanning include dependents of a changed package?
Yes in Nx, through the project graph, and in Turborepo when you use the three dots prefix on a package name.
Why keep a nightly full scan?
New advisories can match code that has not changed, so changed only scans cannot find them.
Sources
Last reviewed: 19 October 2026.
