Use your update tool's path exclusion setting with glob patterns, scoped per ecosystem. One widely used bot documents an exclude list that ignores matching directories and files during update scans. Exclude vendored copies and test fixtures, but never exclude directories that ship in your product.
Why the noise happens
Update tools search for manifests. They do not know which ones matter. A repository can hold copied third party code, sample projects in a docs folder, test fixtures with old lockfiles, and generated output. Each contains a manifest, and a tool that crawls the whole tree opens pull requests for all of it.
Some of those pull requests are harmful as well as noisy. Updating a lockfile inside a test fixture can break the test that depended on the old version. Updating vendored code can drift from upstream and make a later sync painful.
What the documentation offers
The options reference of the bot says that by default all directories and files in the specified directory are included in the scan unless excluded. When an exclusion list is defined, files and directories matching the patterns are ignored for that ecosystem entry. Patterns are globs, relative to the directory for that update configuration, and each ecosystem can have its own list.
The reference's sample patterns show the idea:
| Pattern style | What it matches |
|---|---|
| A folder with two stars after it | Everything under that folder at any depth |
| A folder with one star after it | Files directly in that folder, not subfolders |
| A star with a file extension | Files with that extension in any directory, for some forms |
| An exact path | That one file |
Other tools use different mechanisms, such as package name rules or path ignore lists, so read the documentation for yours.
Steps
- List every manifest in the repository. A search for package manifests and lockfiles is enough.
- Mark each as shipped, tooling or sample. Shipped code ends up in a build or image. Tooling runs in CI. Samples and fixtures do neither.
- Exclude samples and fixtures. Decide case by case for vendored code, covered below.
- Run one update cycle and check that the unwanted pull requests are gone.
- Write the reason next to each exclusion and review the list every quarter.
The vendored code question
Vendored code is not automatically safe to hide. If you copy a library into your tree and ship it, it is in your product, and an advisory against it applies to you. Excluding it from update pull requests means nobody is nudged to refresh it. Pair the exclusion with another process: a scan of the vendored copy, a note of its upstream version, and a calendar reminder to resync.
Never exclude by accident
A broad pattern can hide a real service. Excluding everything under an apps folder, for example, would drop every application in a monorepo. Test your patterns against the list of manifests from step one, and make sure each shipped manifest still gets updates.
Also keep vulnerability scanning separate from update exclusions. An excluded path may still ship, and your scanner should still see it, which is the point of scanning the built artifact as well as the source. Our post on what a clean scan does and does not mean covers that gap.
Quick check
Will excluding a path stop security alerts for it?
It stops update scans in that tool for the path. Your separate scanner may still see the code, and should if it ships.
Should test fixtures ever be updated?
Rarely. Their versions are often pinned on purpose. Exclude them, and update them by hand when the test changes.
Safeguard builds an SBOM and dependency inventory from manifests and lockfiles, so you can see shipped and vendored packages in one place, and reachability analysis shows which flagged ones your code calls. A free scan works on public repositories.
Sources
Last reviewed: 19 October 2026.
