Write a Dependency Fix Pull Request That Passes Bank Change Review

A bank's change review wants five things in a dependency upgrade pull request: why the change is needed (the advisory, its severity and whether it is being exploited), what exactly changed, what could break and how you tested it, how you would roll it back, and a link to the approved change record with an approver who is not you. If any one of those is missing or vague, the reviewer has no choice but to bounce it. The rest of this post is a template and checklist you can paste into your next pull request today.

Key takeaways

• Change reviewers at banks are not judging your code. They are checking that the change was proposed, justified, analysed for security impact, tested, approved by someone else and recorded, because that is what NIST SP 800-53 CM-3 and CM-4 and PCI DSS Requirement 6.5.1 describe, and what examiners working from the FFIEC IT Examination Handbook will sample.
• A version bump is still a change. A "chore: bump" title with an empty description is the single most common reason upgrade pull requests get rejected.
• Put the risk case in the description: advisory ID, CVSS, EPSS probability, CISA KEV status, and whether your code reaches the vulnerable function.
• Show impact with evidence: the lockfile diff, the transitive packages that moved, the changelog lines you read, and the test and scan results attached to the pull request.
• Rollback for a dependency upgrade is usually a revert plus a redeploy of the previous build. Say which build, and say whether any data or schema change makes the revert unsafe.
• Segregation of duties shows up in the repository as branch protection, required reviews, code owners, and a rule that the author cannot approve or merge their own change.
• Emergency changes are allowed almost everywhere, but they need a retrospective review and the same evidence, collected after the fact.
• Safeguard can draft much of this for you. Autonomous remediation (Griffin AI Remediate) is GA and ships switched off, with every category set to Manual. Policies and gates are GA. Portal audit trails are GA. The Jira integration is GA.

The situation

It is audit week. Change management is in scope, and the change advisory board, or the change manager who reviews pull requests on its behalf, has started bouncing anything thin. Your upgrade of a logging library from one patch release to the next has come back twice. The first time the note said "no business justification". The second time it said "testing evidence not attached; rollback plan missing".

From where you sit this feels like paperwork for a one line change. From where the reviewer sits, it looks different. They will be asked by an internal auditor, and later by an examiner, to pick a sample of production changes and show for each one who asked for it, why, what was tested, who approved it and whether the approver was independent of the author. If your pull request cannot answer those questions on its own, the reviewer is the one who has to explain the gap.

A bad week looks like this: a critical advisory lands on Monday for a library in the payments service, the fix is a minor version bump, and the pull request sits in review until Thursday because the change record is incomplete. Meanwhile the vulnerability is on the CISA Known Exploited Vulnerabilities catalog. Nobody did anything wrong technically. The delay came from missing words in a description field.

The fix is to write the pull request the way the reviewer has to read it.

What the rules actually ask for

None of what follows is legal, regulatory or audit advice, and your bank's change policy is the document that governs your work. What follows is the shape of the expectations that your change policy was written to meet, taken from the primary texts.

What do the FFIEC Development, Acquisition, and Maintenance booklet and NIST SP 800-53 CM-3 and CM-4 expect of a change?

FFIEC. The Federal Financial Institutions Examination Council publishes the IT Examination Handbook. In 2024 it issued the Development, Acquisition, and Maintenance booklet, which replaced the Development and Acquisition booklet from April 2004. The OCC announced it in Bulletin 2024-26 on 5 September 2024 and described its purpose plainly: the examination procedures in the booklet "help examiners evaluate a financial institution's controls and risk management processes" for the development, acquisition and maintenance of its systems and components. The bulletin highlights the system development life cycle, supply chain risk management for systems and components, and "the importance of system and software maintenance to an institution's resilience". A dependency upgrade is software maintenance on a component you acquired, so it sits right in the booklet's frame.

The handbook is guidance for examiners, not a regulation, and the booklet itself is the text to read for the detail; this post does not quote it beyond what the OCC bulletin says. Your bank's change policy is how your institution says it meets that guidance, and it is the document your reviewer is applying to your pull request.

NIST SP 800-53 Rev. 5, CM-3 Configuration Change Control. Many banks map their internal controls to NIST SP 800-53, and CM-3 is the clearest statement of what a controlled change is. In NIST's own words the base control asks an organisation to:

1. Determine and document which types of changes are configuration controlled.
2. Review proposed changes and approve or disapprove them "with explicit consideration for security and privacy impact analyses".
3. Document the change decisions.
4. Implement the approved changes.
5. Retain records of the changes for a defined period.
6. Monitor and review activities associated with the changes.
7. Coordinate and provide oversight through a defined change control element (a board or a person) that meets at a defined frequency.

The discussion text under CM-3 says change control covers the "systematic proposal, justification, implementation, testing, review, and disposition" of changes, and it lists changes made to remediate vulnerabilities explicitly. A dependency upgrade that fixes a CVE is squarely in scope.

CM-3(2) Testing, Validation, and Documentation of Changes. Test, validate and document changes before finalising the implementation.

CM-4 Impact Analyses. Analyse changes to determine potential security and privacy impacts before the change is implemented. CM-4(2), Verification of Controls, adds that after the change you verify the affected controls still work as intended.

CM-5 Access Restrictions for Change. Define, document, approve and enforce the physical and logical access restrictions associated with changes. In a repository, this is who can push to the release branch, who can merge, and who can deploy.

PCI DSS Requirement 6.5.1. If your service touches cardholder data, PCI DSS applies too. The requirement text, as the PCI Security Standards Council reproduces it in its v4.0 Self-Assessment Questionnaire D, says changes to all system components in the production environment are made according to established procedures that include the reason for, and description of, the change; documentation of security impact; documented change approval by authorized parties; testing to verify that the change does not adversely impact system security; for bespoke and custom software changes, testing of all updates for compliance with Requirement 6.2.4 before they are deployed; and procedures to address failures and return to a secure state. Requirement 6.5.4 says roles and functions are separated between production and pre-production environments "to provide accountability such that only reviewed and approved changes are deployed". The council's note on v4.0.1, published in 2024, says that limited revision added no new requirements and deleted none, so the same requirement numbers apply.

NIST SSDF (SP 800-218). The Secure Software Development Framework puts the same idea from the builder's side. PW.4 is about reusing well secured software and keeping third party components maintained and verified. RV.2 is about assessing, prioritising and remediating vulnerabilities, including planning and implementing a risk response for each one. A dependency fix pull request is where RV.2 happens in practice.

CISA KEV and BOD 26-04, as context. CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with confirmed exploitation. BOD 26-04 (10 June 2026), which superseded BOD 22-01, sets risk based remediation timelines for federal agencies using factors such as asset exposure and KEV status. It does not bind a bank, but reviewers increasingly ask "is it on KEV?" because it is the clearest public signal that a fix is urgent.

FIRST EPSS. The Exploit Prediction Scoring System, published by FIRST, estimates the probability that a published CVE will be exploited in the wild in the next 30 days. It is updated daily and is free. It answers a different question from CVSS: not how bad is it if exploited, but how likely is exploitation soon.

Put those together and a reviewer's checklist almost writes itself. Every item on it maps to a field in your pull request.

Step by step: build a pull request that passes first time

This works with any source control host, any CI system and any ticketing tool. Nothing here needs Safeguard.

1. Open or link the change ticket first. Most bank change policies want the change request to exist before the code is merged, and many want it before review starts. Put the ticket key in the branch name and the pull request title so the link survives squash merges.
2. Name the advisory, not just the version. Your title should say what risk the change removes: "Upgrade jackson-databind to 2.x.y to fix CVE-YYYY-NNNNN (High, KEV: no)". A reviewer scanning a queue of thirty changes reads titles, not diffs.
3. Pull the risk facts from primary sources. Get the CVSS vector and score from the advisory or the NVD record, the EPSS probability from FIRST, and the KEV status from CISA. Copy the numbers with the date you looked, because EPSS changes daily.
4. Say whether your code reaches the vulnerable function. If you know, say how you know (a call graph, a search for the affected API, a reachability tool). If you do not know, say "not analysed" rather than guessing. Reviewers trust an honest unknown more than a confident maybe.
5. Keep the change to the dependency. Do not bundle a refactor, a feature or a formatting pass. One change, one reason, one rollback. If the upgrade forces code changes, include only those, and call them out.
6. Show the full dependency diff. Paste or attach the lockfile diff summary: which direct dependency moved, which transitive packages moved with it, and any that were added or removed. A minor bump that pulls in a new transitive major is exactly what reviewers want to see before they approve.
7. Read the changelog and quote what matters. List the release notes between the old and new versions that touch behaviour you use: deprecations, default changes, removed APIs. One line each, with a link.
8. Run and attach tests. Unit and integration tests in CI as usual, plus anything specific to the library: a smoke test of the code path that uses it, a contract test against the service it talks to. Link the CI run, not a screenshot.
9. Rescan after the change. Run your dependency scanner on the branch and show that the target finding is gone and nothing new of equal or higher severity appeared.
10. Write the rollback. Name the previous build or image tag, say the revert is a single commit, and say whether any migration, cache format or serialisation change would make reverting unsafe.
11. Request the right reviewers. A code owner for the affected service, and whoever your policy names for security or change approval. Do not approve your own pull request through a second account, and do not ask a teammate to rubber stamp it.
12. Do not merge until the ticket is approved. If your bank's tooling links the two, let the status check enforce it. If it does not, check by hand and say so in a comment.

What should the pull request description contain, field by field?

Here is a template you can save as .github/pull_request_template.md (or your host's equivalent) and fill in for every dependency change. It is deliberately plain. Reviewers work from it line by line.

## Change summary
- Change ticket: CHG-12345 (state: Approved / Pending CAB)
- Change type: Standard / Normal / Emergency
- Service and environment: payments-api, production
- Component: com.fasterxml.jackson.core:jackson-databind
- From version: 2.15.2   To version: 2.15.4
- Direct or transitive: direct

## Why (risk being removed)
- Advisory: CVE-YYYY-NNNNN / GHSA-xxxx-xxxx-xxxx (link)
- CVSS v3.1: 8.1 High (vector: link to NVD record)
- EPSS: 0.0X probability, Nth percentile (FIRST, checked 2026-10-25)
- CISA KEV: not listed (checked 2026-10-25)
- Reachability: affected API used in OrderMapper.java (call path linked) / not analysed
- Policy or SLA: bank vulnerability standard, High = 30 days, due 2026-11-20

## What changed
- package manifest: version bump only
- lockfile: 1 direct, 3 transitive packages moved (summary below)
- code changes: none / list each file and why

## Impact and risk assessment
- Breaking changes in release notes: none affecting our usage (links)
- Behaviour changes we rely on: default for FAIL_ON_UNKNOWN_PROPERTIES unchanged
- Blast radius: payments-api only; no shared library change
- Data or schema impact: none

## Testing
- CI run: link (unit, integration, contract tests passed)
- Targeted tests: serialisation round trip for Order, Refund, Chargeback
- Dependency rescan on this branch: target finding resolved; no new High or Critical
- Performance or smoke test in staging: link

## Rollback
- Previous build: payments-api 4.18.2 (image digest sha256:...)
- Method: revert this commit and redeploy previous build through normal pipeline
- Revert safe: yes (no data migration, no serialisation format change)

## Approvals
- Code owner review: requested from @payments-owners
- Security or change approver: per CHG ticket
- Author did not approve or merge: confirmed by branch protection

And here is what each field is for, so you can explain it if a reviewer asks.

How do you show testing and impact for a dependency upgrade?

Reviewers do not need you to prove the upgrade is perfect. They need to see that you looked in the places where an upgrade usually breaks, and that you wrote down what you found.

Start with the dependency diff, not the code diff. For a dependency change the code diff is often one line, and the lockfile diff is where the risk is. Summarise it in the description: direct packages moved, transitive packages moved, packages added, packages removed, and any major version jumps among the transitive ones. Most package managers can print a tree before and after (for example npm ls, mvn dependency:tree, pip freeze, go list -m all), and the difference between the two outputs is the evidence.

Then read the release notes for every version you skip. If you move from 2.15.2 to 2.15.4, read 2.15.3 and 2.15.4. If you are jumping a minor version, read every minor release in between. Note anything that touches APIs, defaults or serialisation formats you use.

Then test the path that uses the library. Your general test suite is necessary but not enough, because it may not exercise the specific features of the library you depend on. A focused test that calls the code path through the upgraded library is worth more to a reviewer than a thousand unrelated passing tests.

Then rescan. A scan of the branch that shows the target finding gone, and no new high or critical findings introduced by the transitive moves, answers CM-4's question directly: what is the security impact of this change?

Finally, say what you did not test. If there is no staging data for a rarely used code path, say so. "Not covered: legacy CSV export, no fixtures; monitored after deploy via error rate dashboard" is the kind of sentence that gets a pull request approved, because it shows the risk was considered and accepted openly.

A simple way to grade your own impact assessment before you ask for review:

When is an emergency change path appropriate, and what must follow it?

Almost every bank change policy has an emergency or expedited path, and almost every one of them says the same thing in different words: you may implement first and complete the approval and documentation afterwards, but only when waiting would cause more harm than the change, and the retrospective review is not optional.

For dependency fixes, the cases that usually qualify are a vulnerability that is being actively exploited (KEV listed, or a credible vendor or CISA alert), affecting a system that is reachable by attackers, where the normal change window is days away. A high CVSS score on its own, with no exploitation and no reachable code path, usually does not qualify. Your policy decides; this is just the usual shape.

What must still happen, and what reviewers will look for in the retrospective:

1. Verbal or recorded approval from whoever the policy names for emergencies, before deploy, even if the ticket is completed later. Record who approved and when, in the pull request or ticket.
2. The same pull request fields, filled in within the window your policy allows (often the next business day or the next change board).
3. Testing you could do before deploy recorded honestly, plus any testing done after.
4. A post implementation review: did the change work, did anything break, is a follow-up change needed?
5. The emergency flag on the ticket, so the change board can see how often the emergency path is used. A team that uses it every week will be asked why.

The worst emergency change is one with no record at all, because when an examiner samples it, there is nothing to show.

How do approvals and segregation of duties show up in the repository?

Examiners and auditors look for segregation of duties because it prevents one person from writing and shipping an unreviewed change. In the repository, it is not a policy statement; it is a set of settings you can screenshot.

On GitHub, for example, branch protection rules on the release branch can require pull request reviews before merging, require status checks to pass, and prevent bypassing the rules. GitHub's documentation also describes an option to dismiss stale pull request approvals when commits that affect the diff are pushed, and an option to insist that the most recent reviewable push is approved by someone other than the person who pushed it, so that an approval covers the code that is actually merged. A CODEOWNERS file makes the owners of the changed paths automatically requested reviewers, and the "Require review from Code Owners" setting makes one of their approvals mandatory. Other hosts have equivalent settings under different names.

What this looks like when a reviewer checks your pull request:

Two practical points for a developer. First, if a bot or service account opens your dependency pull requests, make sure it cannot also approve or merge them, and that a human is the approver of record. Second, if your team has admins who can bypass branch protection, the bypass needs to be rare, logged and justified, because every bypass is a change an auditor can pick.

How does the pull request become evidence for audit?

A merged pull request is already most of the evidence an auditor asks for when they sample a change. It has the author, the timestamps, the description, the diff, the review approvals and the status checks. What turns it into good evidence is three habits.

1. Link both ways. The pull request links the change ticket and the ticket links the pull request. Auditors usually start from a list of production deploys or a list of tickets, and they need to get from one to the other without asking you.
2. Keep the evidence inside the record. Attach or link CI runs, scan results and test output from systems that keep them for your retention period. A link to a CI run that expires after 30 days is not evidence a year later. Check how long your CI keeps logs and artifacts and compare it with the retention period your policy sets under something like CM-3 e.
3. Do not rewrite history on protected branches. Squash merges are fine, force pushes to the release branch are not. The record has to match what shipped.

When the auditor picks a sample, the request usually looks like this: for these changes, show the request, the approval, the testing and the deploy. If your pull request template is filled in and linked to the ticket, you answer by sending links.

What changes when the fix is in a transitive dependency?

Many advisories land on a package you never chose. It arrived three levels down, pulled in by a framework or a client library, and the direct dependency has not yet released a version that moves it. You then have two honest options, and the pull request should say which one you took.

Option 1: upgrade the direct dependency. If a newer release of the package you declared pulls in the fixed transitive version, this is the cleaner change, because you stay on a combination the maintainers tested. The cost is that a bigger set of packages moves, so the impact section gets longer. List the direct move first, then the transitive move that removes the vulnerability, then everything else that moved with it.

Option 2: force the transitive version. Every major ecosystem lets you override a transitive version from the top: the overrides field in npm, resolutions in Yarn, dependencyManagement in a Maven parent POM, dependency constraints in Gradle, a constraints file for pip. This keeps the change small, but it puts you on a combination nobody upstream tested. A reviewer will want three extra lines in the description:

• Why you forced it. For example: "the direct dependency has no release that moves this package yet; upstream issue linked".
• Compatibility evidence. The version range the direct dependency declares for the transitive package, and whether your forced version sits inside it. If it sits outside, say so plainly and point to the targeted tests that cover the code path.
• When the override comes out. An override left in place for years is its own risk, because it silently pins a package you are not watching. Add a follow-up ticket to remove it once the direct dependency catches up, and put that ticket key in the pull request.

Either way, the rescan on the branch matters more for transitive fixes than for direct ones, because it is the only evidence that the vulnerable version is really gone from the resolved tree and not still present through a second path. Two dependencies can each pull in their own copy, and fixing one path leaves the other.

A reviewer's pre-approval checklist

If you review other people's dependency changes, or want to check your own before you ask, this is the list a change reviewer works through. Paste it into a review comment and tick each line.

- [ ] Change ticket linked, type correct (standard / normal / emergency), state allows merge
- [ ] Title names the component, target version and advisory ID
- [ ] Severity, EPSS and KEV status present, each with the date checked
- [ ] Reachability stated, with evidence or "not analysed"
- [ ] Direct and transitive moves listed; no unexplained packages
- [ ] Release notes for every skipped version read; relevant lines quoted
- [ ] CI run linked; targeted tests for the affected code path named
- [ ] Rescan on the branch: target finding gone, nothing new at High or Critical
- [ ] Rollback names the previous build and says whether revert is safe
- [ ] Reviewer is not the author; code owner review present
- [ ] Approval covers the latest push
- [ ] Evidence links will outlive the retention period

A worked example (illustrative)

This example is invented, with round numbers, to show the fields filled in. It is not drawn from any real bank or customer.

The payments team receives a high severity advisory for a JSON library used directly by one service and transitively by two others. CVSS is 8.1. EPSS is 0.02, which is low but not negligible. It is not on KEV. The team's vulnerability standard gives high severity findings 30 days.

The developer opens CHG-12345 as a normal change, opens one pull request per service, and fills in the template. For the direct dependency the change is a patch bump with two transitive moves; the release notes mention a default change that does not affect the service. Targeted tests cover the three message types that use the library. The rescan shows the finding resolved and nothing new. Rollback is the previous image digest. The code owner approves, the change manager approves the ticket, and the pull request merges in the next window, well inside the 30 days.

Ten days later the same CVE is added to KEV. The two services with transitive exposure have not shipped yet. Their pull requests are already open with the same evidence, so the team asks the change manager to move them to the emergency path, records the approval in the ticket, deploys that afternoon and completes the post implementation review the next morning. Every step is on the record.

How Safeguard does this

Everything above works without Safeguard. What Safeguard adds is that the analysis, the pull request, the gate result and the record can come out of one place, so you spend less time collecting evidence by hand. Each capability below is described only as Safeguard's offering files and docs describe it.

1. Connect the repository (GitHub integration, GA). In Integrations, on the Project/Product tab, connect GitHub with a personal access token. Safeguard's docs recommend a fine-grained token scoped to selected repositories. For scanning, read-only Contents and Metadata are enough. Fix pull requests need two optional write permissions: Contents read and write (to create the branch and commit) and Pull requests read and write (to open the pull request, request reviewers, add labels and comment). Commit statuses read and write lets Safeguard set its quality gate status, safeguard/code-analysis, on pull requests. A dedicated service account works the same way, which helps keep the author of the change separate from its approver.

2. Scan and find the issue (SCA and vulnerability management, GA). Each connected repository becomes a project that Safeguard scans for an SBOM and findings. Vulnerability matching draws on public sources including NVD, GHSA, OSV and CISA KEV, and findings carry EPSS and KEV context. Reachability analysis and prioritisation (GA) ranks the findings your code actually calls, which gives you the reachability line in the template without guessing. How much it narrows the list depends on the codebase, so measure it on your own repositories before you quote a number to anyone.

3. Generate the fix with AI Remediate (autonomous remediation, GA, ships off). Safeguard's docs describe five stages: Griffin AI analyses the vulnerability and your codebase, works out the safest upgrade path, assesses impact (breaking changes and compatibility), creates the pull request, and runs tests to validate the fix. From a vulnerability you click AI Remediate, review the proposed changes, and click Create Pull Request. Bulk remediation creates one pull request per repository, and page level remediation lets you review a plan for every fixable vulnerability on the Vulnerabilities page before approving it. Autonomous remediation ships switched off, with every category set to Manual, so nothing is applied until your team turns it on and chooses what runs on its own.

4. Check the generated pull request against the template. Safeguard's docs say its generated pull requests include a title with the CVE reference, a description of the vulnerability, a summary of the changes, breaking change warnings, test results when tests are configured, and links to the relevant advisories. Breaking change detection grades each fix as Safe, Minor, Major or Critical, with manual review recommended for Major and required for Critical. That covers the Why, What changed, Impact and Testing sections of the template. You still add the change ticket, the rollback plan and anything bank specific, because those are yours.

5. Configure how fixes are created. In Settings, AI Remediate, the docs list five settings: automatic creation of pull requests for safe fixes, a manual sign-off step before any pull request is created, test integration that runs tests before a pull request is created, a breaking change policy, and branch naming. A bank will usually turn the manual sign-off step on, turn test integration on, keep automatic creation off at first, and set branch naming to include the ticket key so the link survives.

6. Gate the pull request on policy (policies and gates, GA). Policies evaluate your SBOMs and produce findings; gates enforce them at checkpoints. In Settings, Policies you create a policy with conditions such as severity, CVSS or EPSS thresholds and licences, and set its Action. Safeguard's docs define three actions: Block (the gate fails), Warn (the gate passes with a warning naming the policy) and Notify (the gate passes and a notification goes to your configured channels). In CI, the docs show this command, which waits for the scan and fails the job when the gate fails:

   safeguard ci scan --wait --fail-on-gate <gate name or id | all>
   

   It exits 0 when the gate is Passed or Warning, and non-zero when the gate is Failed, Error or Not evaluated. The gate outcomes are recorded, and expanding a gate shows each linked policy's action, outcome, matches and evaluation history. Policy outcomes are turned on per workspace by Safeguard, so check that your workspace shows the Outcome column. Make the CI job a required status check on the protected branch, and the gate result becomes part of the pull request's record.

7. Handle the case where you cannot fix yet (exceptions). If a fix is not possible inside the window, the docs describe a Request Exception flow: select the policy and finding, give a business justification, set an expiry date and submit for approval. Approvers are notified, decide, and the decision is recorded in the audit trail. Approval runs through exceptions; it is not a gate action. Your bank still decides who the approvers are.

8. Link the ticket (Jira integration, GA). Under Settings, Integrations, JIRA, you connect Jira Cloud, Server or Data Center with an API or personal access token, map organisations to Jira projects, and choose triggers such as new critical or high vulnerabilities, gate failures or policy violations. Status sync runs both ways: resolving a finding can move the Jira issue to Done, and a Jira issue closed as Done or Resolved marks the finding resolved. A Jira issue closed as Won't Fix creates a mitigation recorded as risk acceptance, so make sure only people who are allowed to accept risk can use that status. You can also create issues by hand from a finding or in bulk.

9. Keep the record (Portal audit trails, GA). Portal, Safeguard's SBOM publish and share product, includes Audit Trails with SIEM export, and the policies and gates docs describe compliance reporting by policy, exception history and violation trends. Together with the pull request history in your source control host and the ticket in Jira, that gives an auditor the request, the analysis, the gate result, the approval and the deploy in a form they can sample.

10. Use the CLI when you want to fix it yourself (Safeguard CLI, GA). If you would rather make the change by hand, the Safeguard CLI's assistant can read a finding and its advisory, edit the manifest, and run your install and test commands. It asks before any command that changes something. It pushes nothing on its own, so the pull request, the review and the merge still go through your normal process.

What remains the bank's

Your change policy, the definitions of standard, normal and emergency changes, the list of approvers for each, and the change advisory board's schedule all stay with the bank. So do production access, the deploy pipeline, branch protection settings, retention periods for CI logs and artifacts, and the decision to accept a risk instead of fixing it. Safeguard can produce the analysis and the pull request and record the gate results and exceptions; the bank decides whether the change happens.

What Safeguard does not do

• It does not approve changes. Safeguard opens pull requests and records gate outcomes and exception decisions. The approval of record comes from the people your change policy names, in your source control host and your ticketing system.
• It does not enforce your branch rules. Required reviews, code owners, required status checks and bypass permissions are settings in your source control host. Safeguard can set a commit status and fail a CI job on a gate, but whether a failed status blocks a merge is your branch protection.
• It does not turn on by itself. Autonomous remediation ships switched off with every category set to Manual. Generated pull requests still need human review, and the docs advise against auto merging breaking changes.
• It does not write your rollback plan. It does not know your deploy pipeline, your previous image digests or whether a revert is safe for your data.
• It does not replace legal or audit judgement. This post and the product describe common practice; your auditors and examiners decide what is sufficient.

Common mistakes

• Merging before the ticket is approved. The most common finding in a change sample. If it cannot be enforced in tooling, check it by hand every time.
• "Chore: bump dependencies" with forty packages. Reviewers cannot assess what they cannot see. Split by service and by reason.
• Tests run on a different commit from the one merged. Make the latest push need its own review, or dismiss stale approvals, so the evidence matches the code.
• Rollback written as "revert if needed". Name the build, the method and whether data changes make it unsafe.

FAQ

What does a bank change review need in a dependency upgrade pull request?

The reason for the change (advisory ID, severity, EPSS, KEV status), exactly what changed (direct and transitive versions), an impact assessment, testing evidence, a rollback plan, a linked and approved change ticket, and an approval from someone other than the author.

Does a patch version bump really need a change ticket?

At most banks, yes for anything that reaches production, although many policies treat low risk, pre-approved change types as "standard changes" with lighter approval. Check your policy's definition. NIST CM-3 lists vulnerability remediation as a controlled change type.

Is CVSS enough to justify an urgent upgrade?

Usually not on its own. Reviewers increasingly want EPSS (the likelihood of exploitation in the next 30 days) and CISA KEV status (confirmed exploitation) alongside CVSS, plus whether your code reaches the vulnerable function.

How do I write a rollback plan for a dependency upgrade?

Name the previous build or image digest, say the method (revert the commit and redeploy through the pipeline), and say whether any data migration, cache or serialisation change makes the revert unsafe. If it does, describe the forward fix instead.

Can a bot open the pull request and still pass change review?

Yes, as long as a human reviews and approves it, the bot cannot approve or merge its own changes, and the pull request carries the same evidence a human author would provide.

What counts as segregation of duties in GitHub?

Required reviews from someone other than the author, code owner review on the affected paths, required status checks, approvals that cover the latest push, and no routine bypass of branch protection. Production deploys run from the pipeline.

When can I use the emergency change path for a CVE?

When your policy's emergency criteria are met, typically active exploitation of a reachable vulnerability where waiting for the normal window causes more risk than the change. Get the named approver's recorded approval first and complete the documentation and post implementation review afterwards.

Does Safeguard approve or merge fix pull requests?

No approval of record comes from Safeguard. It can open fix pull requests (when you enable it), set a quality gate status and fail a CI job on a gate. Your reviewers approve, and your branch protection decides what can merge.

Everything above gets a fix through review once a fixed version exists. The harder case is the advisory where upstream has not shipped one yet, or where the fixed version arrives later than your bank's remediation deadline, and that is where the next section helps.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal with safeguard, and asks it to fix a lodash CVE in a repository. The CLI reads the finding and the advisory, asks before any command that changes something, edits package.json, runs npm install and npm test with approval, prints a summary and pushes nothing. For a bank developer, that summary is the raw material for the "Why", "What changed" and "Testing" sections of the template, and the pull request, the review and the merge still go through your normal process.

Click through it at your own pace, or open it full screen.

The second demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. For a change reviewer, the same connection lets you ask plain language questions about a finding before you approve a fix, for example which services carry the vulnerable version, without exporting spreadsheets.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download the app and CLI at https://safeguard.sh/download and read the setup guides at https://docs.safeguard.sh/docs .

Quick check

Sources

• OCC Bulletin 2024-26, FFIEC Information Technology Examination Handbook: New Development, Acquisition, and Maintenance Booklet (5 September 2024)
• NIST SP 800-53 Rev. 5 catalog (OSCAL), CM-3, CM-4 and CM-5
• NIST SP 800-218, Secure Software Development Framework Version 1.1
• PCI SSC, PCI DSS v4.0 Self-Assessment Questionnaire D for Merchants (Requirements 6.5.1 and 6.5.4)
• PCI SSC blog, Just Published: PCI DSS v4.0.1
• CISA Known Exploited Vulnerabilities Catalog
• CISA BOD 26-04, Prioritizing Security Updates Based on Risk
• FIRST, Exploit Prediction Scoring System (EPSS)
• GitHub Docs, About protected branches
• GitHub Docs, About code owners
• Safeguard docs: AI Remediate
• Safeguard docs: Policies and gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Jira integration
• Safeguard docs: GitHub integration

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.