What Is a Fix Pull Request and How Does It Work?

A fix pull request is a proposed change to your code that repairs a known security problem, such as moving a vulnerable library to a safe version. It changes nothing by itself. People review it, your tests run against it, and it only becomes part of your product when someone approves it and merges it.

TL;DR: A fix pull request is a suggestion, not an action. A tool or a person prepares the change, explains it, and stops. Your team decides. The review step is what makes automated fixing safe enough to use.

Definition: A pull request is a request to merge one set of code changes into a main copy of the code. A fix pull request is a pull request whose job is to repair a security problem.

What is a pull request in the first place?

Most software teams keep their code in a shared place called a repository. Think of it as a folder that remembers every change anyone has ever made. The main copy of the code lives on a branch, which is just a named line of history. A branch often has a plain name like main.

When someone wants to change the code, they do not edit the main copy directly. They make a separate branch, change the files there, and then open a pull request. The name comes from the idea that you are asking the owners to "pull" your changes into the main branch.

A pull request shows three things. It shows exactly which lines changed, usually as red lines for removed text and green lines for added text. It shows a written explanation from the author. And it shows the results of automatic checks, such as tests, that ran on the change.

Other people can comment, ask for edits, and approve. Only after that does the change merge into the main copy. This is the normal way that careful teams change software, whether the author is a person or a tool.

What makes a pull request a fix pull request?

The difference is the purpose. A normal pull request might add a feature or tidy some code. A fix pull request exists to close a specific security problem that has already been found.

The most common example is a vulnerable dependency. A dependency is a library of code written by someone else that your software uses. When a flaw is found in that library, its maintainers release a new version with a repair. A fix pull request updates your project so it uses the repaired version.

Fix pull requests can also repair other things, such as a risky setting or a missing safeguard in a build process. The shape is always the same: a small, clearly explained change that someone can inspect before it goes live.

Compare that with a ticket. A ticket says "there is a problem, please deal with it." A fix pull request says "here is the exact change that deals with it, ready for you to check." The second one saves the busiest part of the work, which is figuring out what to type.

How does a fix pull request get made, step by step?

The steps below describe the general pattern. Tools differ in the details, but the order is similar.

1. Find the problem. A scan lists the software parts in your project and compares them with known flaws. Say it finds that one library version is affected.
2. Check that a repair exists. Sometimes there is no fixed version yet. In that case a pull request cannot help, and you need a workaround instead.
3. Pick the target version. The fix needs a version that has the repair. A good choice is the smallest jump that works, because smaller jumps carry less risk of surprise changes.
4. Change the right files. The project lists its dependencies in a manifest file and often locks exact versions in a lockfile. A fix usually edits one or both.
5. Run the checks. Your build and tests run on the proposed change. If they fail, that is useful news before anything is merged.
6. Write the explanation. A good fix pull request says what was wrong, what changed, why this version was chosen, and what could go wrong.
7. Wait for review. A person looks at the change, reads the explanation, and approves or asks for changes.
8. Merge and watch. After approval the change joins the main branch. Good teams keep an eye on the result for a while.

Safeguard describes its own flow in a similar order: analysis, a proposed solution, an impact assessment, creating the pull request, and then validation. The point to remember is that the pull request is step six or seven of eight. Most of the care happens before and after it.

How is a fix pull request different from other ways of fixing?

There are three common ways a security problem gets fixed. The table compares them.

The middle row is the sweet spot. You get the speed of automation with the safety of review. The third row is the one that worries security teams, because a change that nobody inspected is a change that nobody can explain later.

What does a worked example look like?

This example uses invented names and invented numbers so you can follow the logic. It is not a real project.

Worked example (invented numbers): A small team runs an app with 40 dependencies. A scan finds that a made up library called pretty-dates, version 2.4.1, has a flaw that lets an attacker crash a web page. The maintainers of pretty-dates fixed it in version 2.4.2.

The fix pull request changes two things:

manifest file:  pretty-dates  2.4.1  ->  2.4.2
lockfile:       pretty-dates  2.4.1  ->  2.4.2

The jump from 2.4.1 to 2.4.2 is a patch step, which by the rules of semantic versioning means only backward compatible bug fixes. Semantic versioning is a naming habit where the three numbers mean major, minor, and patch changes, and the official text says a patch number must go up when only backward compatible bug fixes are introduced.

Now the checks run. Suppose the team has 300 automated tests. If 300 pass, the reviewer sees a small, green change with a clear note. If 4 fail, the reviewer learns that something in the app relied on the old behavior, and can decide what to do before any customer is affected.

Notice what did not happen. Nobody edited production by hand at midnight. Nobody guessed which version to use. And if the new version misbehaves later, the team can revert the merge, which creates a new pull request that undoes the original change.

Why not just let a tool change the code directly?

Speed is tempting. If a flaw is serious, why wait for a human?

The answer is that tools make mistakes, and so do people. A repaired library can still change behavior in ways its maintainers did not intend. A tool that edits the main code without review turns every such surprise into an incident.

Review also protects you from the quiet problems. For example, a reviewer might notice that a fix touches a file owned by another team, or that a new version asks for a different license, or that the explanation does not match the change.

Code hosting platforms support this directly. GitHub documents that administrators can require a set number of approving reviews before a pull request merges into a protected branch, and that required status checks must pass first. Teams can also name code owners, people responsible for certain files, who are asked to review changes to those files. These features apply to tool-made pull requests just as they apply to human ones. For a deeper look at setting them up, see how to configure GitHub branch protection rules.

What should a good fix pull request contain?

A reviewer is more likely to trust a change that explains itself. Look for these items:

• The name of the problem and how serious it is.
• The old version, the new version, and why that version was picked.
• Whether the jump is a patch, minor, or major step.
• A note on whether your code actually uses the flawed part. This is called reachability, and it helps you decide how urgent the change is.
• The results of automatic checks.
• A plain statement of risk, such as "this changes a date format used in two places."

If a fix pull request cannot tell you these things, treat it with caution. If you want to see how evidence can travel with a change, read evidence attached fix PRs and why reviewers trust them.

How does Safeguard handle fix pull requests?

Safeguard can analyze a vulnerability, propose a fix, assess the impact, and open a pull request with the change for review. It supports single fixes and bulk fixes, and its flow includes breaking change detection and validation.

Two facts matter for accuracy. First, fix pull requests are off by default. Autonomous Remediation ships switched off, and every category is set to Manual, so nothing is applied automatically until your team turns it on. Second, even when it is on, the output is a pull request that your normal review process can inspect.

The Safeguard CLI can also write code, in addition to scanning. If you want a quick look at your own exposure first, the free scan at gold.safeguard.sh/scan shows what your software contains and which parts are affected.

For the full pipeline from finding to merge, see from CVE to PR: the full remediation pipeline and how Safeguard Auto Fix works.

Try it yourself

Click through it at your own pace, or open it full screen. Follow one finding from detection to a proposed change and notice where the review step sits.

Quick check

Sources

• Semantic Versioning 2.0.0, the rules for patch, minor, and major numbers.
• About protected branches, GitHub Docs, on required reviews and status checks.
• About code owners, GitHub Docs, on automatic review requests.
• Reverting a pull request, GitHub Docs, on undoing a merged change.

Last reviewed: 19 October 2026.