Bulk fix pull requests apply the same kind of repair across many repositories at once, opening one pull request per repository so each team can review its own code. They save the repeated work of fixing the same flaw by hand, as long as you control order, pace, and review.
TL;DR: Bulk fixing turns one problem found in fifty places into fifty small pull requests instead of fifty tickets. The risk is review overload, so start with a pilot wave, rank by urgency, and keep one reviewer per repository.
Definition: A bulk fix is a single action that prepares fix pull requests for the same problem across many repositories, one pull request per repository.
Why do teams need bulk fixes?
A single flaw in a popular library can show up in dozens of your repositories. Fixing it by hand means opening each repository, finding the version, editing files, running tests, and writing an explanation. Do that fifty times and a week is gone.
Backlogs have the same shape. Over a year, a company can pile up hundreds of old findings that no one had time to fix. Doing them one by one is slow and discouraging. Bulk fixing makes a dent in that pile without asking each team to start from zero.
Safeguard supports single and bulk fixes, and it also has a page level option, so check the product documentation for how that one behaves. In bulk mode it opens one pull request per repository. That choice matters. A pull request that lives in the repository it changes goes to that repository's owners, uses that repository's tests, and follows that repository's review rules.
What is the difference between single and bulk fixes?
| Mode | What it does | Good for |
|---|---|---|
| Single | Prepares one fix pull request for one finding in one repository | Careful, targeted work and first trials |
| Bulk | Prepares fix pull requests across many repositories, one per repository | Cleaning up a common flaw or a backlog |
Start with single mode to learn what a good pull request looks like. Move to bulk when you are comfortable.
What are the steps for a safe bulk fix?
- Define the target. Choose the problem: a single vulnerable library, or a class of finding. A narrow target is easier to review than a broad one.
- List the affected repositories. A software bill of materials, or SBOM, helps here. An SBOM is a list of every part inside a piece of software. Search them for the affected library to see where it appears.
- Rank by urgency. Put repositories where the flaw is reachable, or where the system faces the internet, first.
- Choose a cautious strategy. In Safeguard, Safest applies backward compatible fixes that should not break existing functionality.
- Pick a pilot wave. Choose five or so repositories with strong tests and willing owners.
- Run the wave and review. Each owner reviews the pull request in their own repository.
- Measure. Count merged, changed, closed, and broken.
- Run the next wave. Increase the size only if the results are good.
- Close the loop. Rescan to confirm that the flaw is gone from merged repositories, and track the rest.
For a view of a long backlog cleanup, read bulk remediation of an aged vulnerability backlog.
Why is review load the real challenge?
Opening pull requests is easy. Reading them is hard. If a bulk run opens eighty pull requests on a Monday, eighty people have a new task, and many will approve quickly just to clear the queue. That defeats the purpose of review.
Three habits help.
- Waves, not floods. Release pull requests in groups sized to what teams can review that week.
- One owner per repository. Use code owners so the right person is asked automatically. GitHub documents that a CODEOWNERS file names people or teams responsible for code, and that they are automatically requested for review when a pull request changes files they own.
- A standard explanation. When every pull request in a wave explains itself the same way, reviewers learn the pattern and read faster.
Branch rules help too. GitHub documents that administrators can require a set number of approving reviews and passing status checks before merging into a protected branch. Bulk pull requests meet those rules like any other change. For setup details, see how to require human review for bot pull requests.
What does a worked example look like?
This example is invented, with invented numbers, to show how waves keep a bulk fix under control.
Worked example (invented numbers): A company has 60 repositories. A scan shows that 42 of them use an affected version of a made up library, pretty-dates 2.4.1, which has a flaw fixed in 2.4.2. Reachability analysis shows that 9 of the 42 call the flawed function.
| Wave | Repositories | Selection | Pull requests opened | Result (invented) |
|---|---|---|---|---|
| 1 | 5 | Reachable, strong tests, willing owners | 5 | 5 merged in 2 days |
| 2 | 4 | Remaining reachable repositories | 4 | 3 merged, 1 closed because tests failed |
| 3 | 15 | Unreachable, strong tests | 15 | 14 merged in a week, 1 sent back for edits |
| 4 | 18 | Unreachable, weaker tests | 18 | Held for two weeks while tests improve |
By the end of week three, in this made up story, 22 of 42 repositories are fixed, including 8 of the 9 where the flaw was reachable. The team handles the one remaining reachable repository by hand because its tests failed. Notice that nobody faced more than a few pull requests in a day. The pace stayed human.
What can go wrong?
- A fix that works in most places but not all. Repositories differ. Expect a few to need manual work.
- Pull requests that go stale. If a pull request sits for weeks, it can conflict with new changes. Re-run the fix instead of repairing an old one.
- Overconfidence after a clean wave. Each wave tests a different set of repositories. Keep reviewing.
- Missing owners. Archived or abandoned repositories may have no one to review. Decide in advance whether to fix, archive, or accept the risk, and record that choice.
How does Safeguard handle bulk fixes?
Safeguard provides autonomous remediation with fix pull requests as a generally available capability, including bulk fixes with one pull request per repository. Its flow covers analysis, a proposed solution, an impact assessment, pull request creation, and validation, and it includes breaking change detection.
Fix pull requests are off by default, and every category is set to Manual, so nothing opens in bulk until your team turns on Autonomous Remediation. Reachability analysis helps you rank repositories, and SBOM and dependency scanning show where a library appears. The Safeguard CLI can also write code, in addition to scanning.
To see which of your own repositories contain affected dependencies, run the free scan at gold.safeguard.sh/scan. For a wider look at the pipeline, read from CVE to PR: the full remediation pipeline.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one action produces a separate pull request for each repository, and think about how you would split them into waves.
Quick check
Does a bulk fix put all changes into one giant pull request?
No. Safeguard opens one pull request per repository, so each repository's owners can review the change in their own code with their own tests.
How many repositories should the first wave include?
A handful, such as five, chosen for strong tests and willing owners. Increase the size only when the results are good.
Will a bulk fix merge changes without review?
Fixes arrive as pull requests, so your review rules apply. Bulk fixing is also off by default in Safeguard, and every category starts on Manual.
What if some repositories have no owner?
Decide on purpose whether to fix, archive, or accept the risk, and write the choice down. Do not let those repositories silently stay vulnerable.
Sources
- About protected branches, GitHub Docs, on required reviews and status checks.
- About code owners, GitHub Docs, on automatic review requests.
Last reviewed: 19 October 2026.
