Burn Down Overdue Criticals After a Bank Exam Finding

When an exam finding says your bank has critical vulnerabilities past their remediation dates, the fastest credible answer is a dated burn-down plan, not a cleanup sprint. Rank the overdue list by real exploitation and exposure, collapse it into the smallest set of package upgrades that clears it, open those upgrades as tested pull requests in batches your engineers can actually review, stop new criticals from joining the queue, and send every item you cannot fix on time through a written, expiring exception. Then show the trend every month until the examiner closes the item.

This guide is for the application security lead at a regional bank who owns that backlog. It covers the rules behind the finding, why overdue lists grow back, a plan that works with the tools you already have, an illustrative scenario, and then how the same job runs in Safeguard. Nothing here is legal, regulatory or audit advice, and nothing here tells you what your own finding says. Your examiner, your counsel and your board decide that.

Key takeaways

• Read the finding's category first. It sets your clock, and an OCC and FDIC rule effective 2 November 2026 changes when those agencies issue MRAs.
• Overdue is measured against your own policy. The Interagency Guidelines set no patch deadlines. Your written standard does, and the examiner tests whether you meet it.
• Burn down by package, not by finding. Many findings trace back to a few components; one upgrade per repository closes them together.
• Exploitation decides order. CISA's Known Exploited Vulnerabilities (KEV) catalog and FIRST's EPSS come before raw CVSS.
• Stop the inflow before you celebrate the outflow. A gate on new criticals keeps the line from climbing back.
• Exceptions are part of the plan. Anything you cannot fix by its date needs an owner, a justification, compensating controls and an expiry.
• Safeguard capabilities in this post, all GA: software composition analysis and vulnerability management with EPSS and KEV enrichment (GA), reachability analysis and prioritization (GA), autonomous remediation with Griffin fix pull requests, single and bulk (GA, ships switched off with every category set to Manual), policies and gates with Block, Warn and Notify actions and approvals through exceptions (GA), mitigations and risk acceptance records (GA), Jira ticketing integration (GA), dashboards and scheduled reports (GA), the Safeguard CLI and CI integration (GA), the MCP server (GA), and Zero AI mode, bring your own model and on-prem deployment (GA).

The job and who owns it

The job is simple to state and hard to finish: take a backlog of critical and high severity vulnerabilities in the software the bank builds or customizes, bring every item inside the remediation timeline the bank's own policy promises, and keep it there.

The owner is usually the head of application security or the AppSec lead. At a regional bank that person often runs a small team that does not write the application code. The code belongs to product teams who maintain digital banking, lending and treasury tools, core integrations and a long tail of small services. The AppSec lead can find problems all day. Fixing them takes someone else's time.

That split is why the backlog exists. Each finding becomes a ticket, each ticket waits behind product work, and months later the overdue line becomes a written finding.

The situation: the exam report lands

The trigger is a sentence in a report of examination, or a supervisory letter, that says something close to this: critical vulnerabilities were not remediated within the timeframes set by the bank's own vulnerability management policy, and the bank lacked effective processes to track and escalate overdue items. The wording varies. The shape is consistent.

Then the CISO forwards it to you, the chief risk officer wants a corrective action plan at the risk committee within weeks, internal audit wants to validate it, and the examiner wants a written response with dates and, later, evidence that the plan ran.

A bad week looks like this: a spreadsheet of several thousand rows, managers told to "prioritize security tickets" with no added capacity, a dip before the board meeting, a rebound a month later, and a repeat finding at the next exam.

The rest of this guide is about avoiding that week.

What the rules behind the finding say

Bank regulators set principles and test you against your own commitments. Know which documents frame your finding before you write the response.

The Interagency Guidelines Establishing Information Security Standards

For national banks the standards sit in 12 CFR Part 30, Appendix B, with parallel versions from the Federal Reserve and the FDIC. Three provisions matter most here:

• III.C.3 requires the bank to regularly test the key controls, systems and procedures of the program, with frequency and nature set by the bank's risk assessment, and with tests conducted or reviewed by people independent of those who run the program.
• III.E requires the bank to monitor, evaluate and adjust the program in light of relevant changes in technology, threats and its own business arrangements.
• III.F requires a report to the board or a board committee at least annually describing the program's overall status, including risk management and control decisions, results of testing and recommendations for changes.

None of these sets a patch deadline, so "overdue" almost always means overdue against your own written standard.

The FFIEC handbook sections examiners lean on

Two FFIEC IT Examination Handbook sections come up in these findings. The Information Security booklet, section II.C.10(d), covers patch management. The Architecture, Infrastructure, and Operations booklet, section VI.B.3, covers vulnerability and patch management and, as the Conference of State Bank Supervisors quotes it, expects management to "periodically assess systems and software for vulnerabilities" using current scanners.

The state supervisors' board guidance on vulnerability and patch management is a useful translation of these sections into questions. It asks whether the institution prioritizes patches by severity with known exploited vulnerabilities at the front, whether it tests patches before production, whether it tracks the patches management chooses to delay or not apply, and whether compensating controls cover unpatched assets. Every one of those questions maps to a part of a burn-down plan.

How a finding is classified, and why that changed on 2 November 2026

The Federal Reserve's SR 13-13 defines two categories of supervisory finding. Matters Requiring Immediate Attention are matters of significant importance and urgency that must be addressed immediately. Matters Requiring Attention are important and are expected to be addressed over a reasonable period. The guidance says communications of either kind must specify a timeframe for corrective action, that examiners may require an action plan, and that the board must respond in writing with corrective actions and timeframes. Reserve Banks then follow up to verify completion.

For OCC and FDIC supervised banks, a joint final rule announced in OCC Bulletin 2026-40 and published in the Federal Register on 1 September 2026 takes effect on 2 November 2026. It defines "unsafe or unsound practice" and limits when those agencies may issue an MRA, tying it to practices that could reasonably be expected to materially harm the bank's financial condition or present a material risk of loss to the Deposit Insurance Fund, or to actual violations of law. The rule also lets the agencies communicate informal "supervisory observations." The OCC's bulletin says the agencies want examiners and banks to prioritize material financial risks over concerns about process and documentation.

Read exactly how your finding was issued, and ask your compliance team how the new rule applies. Do not assume a lighter label means a lighter fix: an overdue critical in an internet-facing banking application is a risk whatever the label.

NIST SP 800-40 Rev. 4 and the SSDF

NIST SP 800-40 Revision 4, published April 2022, defines enterprise patch management as identifying, prioritizing, acquiring, installing and verifying patches, updates and upgrades. It frames patching as preventive maintenance and a cost of doing business, which is the argument you will need when asking engineering leaders for capacity.

NIST SP 800-218, the Secure Software Development Framework, is the reference for software the bank writes. Practice RV.2, "Assess, Prioritize, and Remediate Vulnerabilities," has two tasks that describe a burn-down: RV.2.1, analyze each vulnerability to gather enough information about risk to plan its remediation, and RV.2.2, plan and implement risk responses. The examples include recording each vulnerability in issue tracking and calculating risk from exploitability and impact.

KEV, EPSS and BOD 26-04 as reference points

CISA's KEV catalog is the authoritative list of vulnerabilities seen exploited in the wild. CISA recommends that every organization prioritize remediation of KEV entries, even though only federal civilian agencies are bound to the catalog's deadlines.

FIRST's EPSS publishes a daily probability that a CVE will be exploited in the next 30 days. It is a ranking signal, not a verdict.

CISA's Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk," issued 10 June 2026, replaced BOD 22-01 for federal civilian agencies. It sets remediation timelines from four variables: whether the asset is publicly exposed, whether the CVE is on KEV, whether exploitation can be automated and whether exploitation gives partial or total control. Banks are not bound by it, but it is a good model for a risk-based clock you can defend.

How teams do it today and where it breaks

Most AppSec teams at regional banks run some version of the same loop. Understanding where it fails tells you what the new plan has to change.

The common thread is that the work is organized around findings while the fix is organized around components and repositories. A burn-down plan flips that.

Step by step: a burn-down plan that works with any tools

The steps below work with any scanner, any ticketing system and any CI. Where Safeguard can do a step, the section after this one shows how.

1. Classify the finding and set the response date

Write a one page summary: the exact finding text, its category (MRIA, MRA, observation, or your agency's equivalent), the corrective timeframe if the report gives one, the date your written response is due and who signs it. Quote any section of your own policy the finding cites.

2. Fix the denominator

You cannot burn down a list you cannot define. Agree on scope in writing:

• Which assets count: all repositories the bank builds or customizes, container images it builds, and the deployed applications those produce.
• Which findings count: critical and high severity vulnerabilities in first-party code dependencies and images, with severity taken from a stated source.
• What "overdue" means: the age of a finding measured from first detection, against the timeline in your policy for its class.

Then reconcile the scanner's repository list against source control and your asset inventory. Every unscanned repository is a future finding you have not counted, and examiners notice when the denominator moves.

3. Re-rank the backlog by risk, not by score

Sort the overdue list into bands. A simple banding that tracks the logic of BOD 26-04 and the state supervisors' guidance:

The clocks in that table are example inputs. Your policy sets the real ones, and if the finding says your policy was not met, either meet it or change it formally through governance. Do not quietly redefine it in the response.

"Unreachable" is a reason to reorder, not to ignore, and a band can change overnight when a CVE joins KEV, so re-run the banding weekly.

4. Collapse findings into fix units

Group the overdue findings by vulnerable component and fixed version, then by repository. A fix unit is "upgrade package X from version A to version B in repository R." Ten CVEs in the same library usually close with one fix unit per repository. This is the single biggest lever in the plan. It turns a list of thousands into a list of hundreds, and it tells engineering managers exactly what you are asking for.

For each fix unit, record:

• the package, current version and target version
• the findings it closes and their bands
• whether the target is a patch, minor or major version change
• whether the fix is direct or requires moving a transitive dependency
• the owning team and the repository's test coverage

5. Plan capacity in waves

Fix units differ in effort. A patch level bump in a well tested service is a review and a merge. A major version change in a legacy integration might be a week of work. Split the plan into waves:

• Wave 1: P0 and P1 fix units that are patch or minor changes. These go first because they carry the most risk and the least effort.
• Wave 2: remaining P0 and P1 units with major changes. These need named engineers and dates.
• Wave 3: P2 units, batched by repository so each team gets one combined change rather than ten.
• Wave 4: P3 units, folded into normal upgrade cadence with a documented rationale.

The constraint is usually review and test capacity. Ask each team how many upgrade pull requests it can review and merge per week alongside product work, set your dates from that, and get engineering leadership to agree in writing. A missed commitment turns an MRA into a repeat finding.

6. Stop new debt at the door

Add a check to every build pipeline that fails when a new critical, or a new KEV listed vulnerability, enters a protected branch. Start in warning mode for a short period so teams can see what would fail, then switch to blocking. Without this step, the inflow of new findings will match your burn-down rate and the line will not move.

7. Run exceptions through a register

Some items will miss their dates for legitimate reasons: a vendor dependency pins a version, a major upgrade needs a rewrite, a fix does not exist yet. Each gets an exception record with:

• the finding and asset
• the business justification
• compensating controls in place, such as network restrictions, feature flags or a web application firewall rule
• the approver, who should not be the requester
• an expiry date, after which the item returns to the overdue list automatically

This is the "process to document and track these exceptions" the state supervisors' questions ask about. An exception without an expiry is a risk acceptance nobody will revisit.

8. Report the same way every month

Pick a small set of measures (the "What to measure" section below has a checklist), report them on the same dates to the same committee and keep every month's version. The evidence that closes a finding is a series of reports showing a process running, not one good number.

Corrective action plan template

Use this as the skeleton of your written response. Replace every value with your own.

Illustrative scenario: a regional bank clears its overdue criticals

This is a composite example, not a customer. The bank, its people and every number below are invented to show the workflow. The numbers are example inputs for you to replace with your own; they are not results.

The bank. Example Bank is a fictional regional bank with roughly 120 application repositories, from digital banking to internal tools. The AppSec team is three people; product engineering is about 80 engineers in nine teams.

The finding. The report of examination states that critical vulnerabilities in internally developed applications were not remediated within the 30 day timeline in the bank's vulnerability management standard, and that the bank lacked a consistent way to track and escalate overdue items and exceptions. The response is due in 45 days.

The starting numbers (example inputs). On the day the finding arrives, the scanner reports 2,600 open critical and high findings across the in-scope repositories. Of those, 900 are critical and older than 30 days.

Week 1: classify and scope. Reconciling source control against the scanner finds 14 repositories never scanned. They are added before counting.

Week 2: re-rank. Banding the 900 overdue criticals by KEV status, EPSS, exposure and reachability puts 40 in P0, 210 in P1, 380 in P2 and 270 in P3. The P3 group is mostly internal tools and code paths the analysis marks as not reachable; each gets a recorded rationale rather than a silent downgrade.

Week 2: collapse into fix units. Grouping by component and fixed version turns the 900 findings into 310 fix units across 85 repositories. Most of the P0 and P1 risk sits in about 30 widely used libraries. Of the 310 units, 190 are patch or minor upgrades.

Week 3: plan waves. Managers estimate each of the nine teams can review and merge about eight ready to review upgrade pull requests a week, an example capacity of about 70. Wave 1 (P0 and P1 patch and minor units, about 120) fits into two to three weeks of that capacity. Wave 2 (P0 and P1 major upgrades, about 40) gets named engineers and dates over the following six weeks. Wave 3 and Wave 4 follow on a monthly cadence.

Week 3: stop the inflow. The team adds a gate to every pipeline that blocks merges introducing a new KEV listed or critical vulnerability on protected branches, after a two week warning period.

Week 4: exceptions. Eighteen items cannot be fixed on time. Some need a vendor library update, some a rewrite. Each gets an exception with compensating controls, an approver from risk management and a 90 day expiry.

Week 6: the response. The corrective action plan goes to the risk committee and then the examiner with waves, dates, interim targets, the gate rollout and the exception register. Internal audit agrees to validate the overdue P0 and P1 counts at 90 days.

Months 2 to 6: run it. The monthly report shows overdue P0 and P1 counts, fix units merged, the inflow of new criticals at the gate and exceptions opened, closed and expired. The scenario stops here on purpose: your numbers depend on your code, teams and policy, so the next sections give measures to track, not outcomes to expect.

How Safeguard does this

Safeguard maps onto the plan above step by step. Every capability named here is generally available. Screens and commands appear only where Safeguard's documentation shows them; where the docs describe an outcome rather than a screen, so does this section.

1. Build the inventory and the denominator

Safeguard's software composition analysis (GA) builds a full transitive dependency inventory for each repository and container image you connect, and vulnerability management (GA) matches it against advisory sources. The Vulnerabilities docs list its sources, among them the National Vulnerability Database, OSV, CISA KEV, vendor security bulletins and researcher disclosures. Safeguard re-scans projects daily, and when new CVEs are published, projects are re-evaluated automatically. That daily re-evaluation is what keeps your denominator honest between reports.

The Vulnerabilities tab groups findings as Critical, High, Medium, Low and Exploitable, where Exploitable means known active exploitation. Each finding carries CVE ID, CVSS, EPSS, exploit status, the affected component and version, the fixed version and reachability.

2. Re-rank by exploitation and reachability

Reachability analysis and prioritization (GA) combines reachability with EPSS, KEV, runtime context and business context into one ranked list. The reachability docs describe three kinds of analysis (static call graph, dynamic runtime observation and configuration), four classes (reachable, conditionally reachable, unreachable and unknown) and a 0 to 100 Priority score. Unknown results are treated as potentially reachable, and the docs say quality varies by language.

The Vulnerabilities table has Priority and Reachability columns, and the docs show filters such as reachable:true, kev:true and epss:>0.3. Combined, env:production reachable:true kev:true is the docs' example of a P0 view. Scoring weights are configurable per tenant under Settings, Prioritization. You can also ask Griffin in plain language, for example "Show my P0 findings in production that are reachable."

Write down the filter that defines each band from step 3 and run it every week.

3. Collapse findings into fix pull requests

Autonomous remediation (GA) is where Safeguard turns findings into fix units. According to the AI Remediate docs, Griffin AI analyzes the vulnerability and your codebase, determines the safest upgrade path, assesses breaking changes, creates a pull request and runs validation tests. It upgrades vulnerable packages, handles transitive dependency conflicts and updates lock files.

There are three ways to start it, all documented:

1. Single vulnerability. Open the vulnerability, click AI Remediate, review the proposed changes and click Create Pull Request.
2. Bulk. Select vulnerabilities, click AI Remediate Selected, and Griffin batches compatible fixes into one pull request per repository after you review them.
3. Page level. From the Vulnerabilities page, click AI Remediate at the top; Griffin analyzes all fixable vulnerabilities, presents a remediation plan for review, and creates pull requests once you approve.

Bulk is the step 4 lever: findings that share a component in the same repository arrive as one change, so a team reviews one pull request instead of ten tickets. Each pull request carries the CVE reference, a summary of changes, breaking change warnings, test results if configured and advisory links. Griffin labels breaking change risk as Safe, Minor, Major or Critical, which maps directly to your wave plan: Safe and Minor go to Wave 1, Major and Critical go to Wave 2 with a named engineer.

4. Decide how much runs on its own

Autonomous remediation ships switched off, with every category set to Manual. Nothing is applied until your team turns it on. The offering covers several remediation categories, including dependencies, licenses, security posture and findings, each with its own setting and strategy. For vulnerability and dependency fixes the strategies are Safest (backward compatible fixes only), Balanced (minor versions and patches), Aggressive (all fixes including major versions) and Smart (the model chooses per item).

The docs list AI Remediate settings including Auto-Create PRs, Require Approval, Test Integration, Breaking Change Policy and Branch Naming. A sensible start is to leave the master switch off, run bulk remediation by hand on Wave 1 with the Safest strategy and tests on, and consider automatic pull requests for patch level fixes only after weeks of clean results. Either way, a human reviews and merges every change, and your normal change management applies.

5. Gate new criticals at merge

Policies and gates (GA) enforce your standard on every scan. The Policies and Gates docs describe policies as rules that evaluate SBOMs and generate findings, and gates as checkpoints that enforce them. Policies are created under Settings, Policies with conditions such as vulnerability severity, CVSS score and EPSS score, and templates include No Critical Vulnerabilities.

Each policy has one action, and the policy outcomes docs define them precisely:

Approval is not a gate action. It runs through policy exceptions, covered in the next step.

To fail a build on a gate, the docs show this CLI command:

safeguard ci scan --wait --fail-on-gate <gate>

It waits for the scan and for the gate's policies to be evaluated, exits 0 when the gate is Passed or Warning, and exits non-zero when it is Failed, Error or Not evaluated. You can also fail on severity with --fail-on critical, and the CI integration docs give a complete workflow file and the API key scopes it needs. The policy outcomes docs note that outcomes are turned on per workspace by Safeguard, so confirm yours shows an Outcome column. These snippets are as the docs show them; they were not run for this post.

Roll out with Warn for two weeks, then switch to Block.

6. Record exceptions and risk acceptances with an expiry

Safeguard gives you two documented records. A policy exception is requested with the policy, finding, business justification and expiration date, then approved or denied, with an audit trail. A mitigation, from the Mitigations docs, records a risk acceptance, false positive, workaround or not applicable decision with a required justification and approver, optional evidence, scope and, for risk acceptances, an expiry.

The details that matter to an examiner are in the docs: Safeguard notifies before a mitigation expires (14 days, 7 days and on the date), expired mitigations stop excluding the vulnerability from gate results, and every create, change, approval, expiry and revocation is logged with who and when. That is the step 7 register, with the return to the overdue list built in.

7. Route the work to the teams who own it

If your engineering teams live in Jira, the Jira integration (GA) creates issues automatically. The Jira integration docs list triggers for new critical vulnerabilities, new high vulnerabilities, gate failures and policy violations, with project mapping, default assignee and status synchronization. Use it for the work that needs a person, such as Wave 2 major upgrades and expiring exceptions, and let fix pull requests carry the patch level work.

8. Report the trend

The Dashboard docs describe widgets for aging vulnerabilities, mean time to remediation, vulnerabilities fixed per week, AI Remediate versus manual fixes and time to fix by severity, with PDF export and scheduled weekly or monthly reports. The reachability docs describe a Prioritization dashboard with backlog aging and time to remediate by priority band. Schedule the monthly report to the same audience on the same date, and keep every copy.

9. Keep code where your risk team wants it

Safeguard can run in Zero AI mode (GA), with the platform working deterministically and no language model involved, or with your own model (GA), or with quantized Safeguard models running on-prem or air-gapped (GA). The local runner CLI (GA) scans on your own machine and sends only encrypted results. Decide this with model risk before the first pull request. On posture, Safeguard's wording is "designed for FedRAMP High" and "SOC 2 Type II audit in progress."

What to measure

Use this checklist for the monthly report. These are measures to track, not results to expect; define each in writing first.

• Overdue criticals and highs by band (P0 to P3), counted against your written policy, as of the same day each month.
• Age of the oldest overdue item in each band. One very old P0 says more than a falling total.
• Fix pull requests opened, merged, rejected and reverted per month, with reasons for rejections and reverts.
• Inflow at the gate: new critical or KEV listed findings blocked or warned per month.
• New overdue items: findings that crossed their deadline this month. This is the line that tells you whether the process is holding.
• Exceptions opened, approved, expired and renewed, and how many renewals had a new justification.
• Coverage: repositories and images in scope versus scanned, and the date each was last scanned.
• Validation status: whether internal audit or an independent party has tested the numbers this quarter, which speaks to III.C.3.

What Safeguard does not do

• It does not interpret your finding or negotiate with your examiner. It provides data and records; the response, the commitments and the relationship with the agency stay with the bank.
• It does not merge code or bypass your change management. Fix pull requests are proposals. Your engineers review them and your release process decides when they ship. Autonomous remediation ships switched off.
• It does not fix vulnerabilities in software you do not build. Your core processor, vendor appliances, hosted services and operating systems need their vendors' patches. Safeguard's remediation applies to the open source dependencies and container images in code you build or customize.
• It does not make every fix painless. Major version upgrades can need real code changes. Breaking change detection tells you the risk level; it does not remove the work.
• It does not guarantee reachability results for every language or pattern. The docs say quality varies by language and that reflection, dynamic dispatch and data driven issues limit static analysis. Unknown results are not suppressed, and you should not suppress them either.
• It does not set your remediation timelines. The clocks in your policy, and any change to them, are governance decisions for the bank.
• It does not replace independent testing. Internal audit or a third party must still validate that the program works.

Common mistakes

• Counting findings instead of fix units. It hides where the work is and overstates how much engineering time you need.
• Downgrading unreachable items silently. Record the rationale, keep them on a later clock and re-check when code changes.
• Skipping the gate. Burn-down without a gate on new criticals is a treadmill.
• Exceptions without expiry. They pile up into an unmanaged risk register the next examiner will find.
• Redefining "overdue" in the response. If the policy timelines are wrong, change them through governance with a date and a rationale, not inside a spreadsheet.
• Turning on full automation on day one. Start with reviewed bulk pull requests on safe fixes and expand as trust builds.

FAQ

How do I respond to an exam finding on overdue critical vulnerabilities?

Classify the finding, fix the scope, re-rank the overdue list by exploitation and exposure, group it into fix units, plan waves with engineering capacity, add a gate on new criticals and run exceptions through an expiring register. Put all of that in a corrective action plan with owners, dates and monthly interim targets, then report the same measures every month.

Do bank regulators set a deadline for patching critical vulnerabilities?

The Interagency Guidelines do not set patch deadlines. Your written vulnerability management policy does, and examiners test against it. CISA's BOD 26-04 timelines bind federal civilian agencies, not banks, but they are a useful model for a risk-based clock.

What is the difference between an MRA and an MRIA?

Under the Federal Reserve's SR 13-13, an MRIA is a matter of significant importance and urgency that must be addressed immediately, while an MRA is important and must be addressed over a reasonable period. Both require corrective action within a stated timeframe and a written response from the board.

Should we prioritize by CVSS, EPSS or KEV?

Use all three, weighted by how direct the evidence is: KEV first, because exploitation is observed; EPSS next, because it estimates exploitation in the next 30 days; and CVSS for severity within those groups. Add exposure and reachability to decide the band.

Can AI-generated fix pull requests be used at a regulated bank?

Yes, if they pass the same review, testing and change management as any other change. Safeguard's autonomous remediation ships switched off, opens pull requests rather than merging, and can run with Zero AI mode, your own model or on-prem models if your model risk team requires it.

What do we do when no fixed version exists?

Record a mitigation or exception with compensating controls and an expiry, track the upstream issue and revisit on the expiry date. The section below on fixing without waiting for upstream describes the options Safeguard offers when a fix is slow to arrive.

What happened to the FFIEC Cybersecurity Assessment Tool?

The FFIEC removed it from its website on 31 August 2025, as OCC Bulletin 2024-25 announced. Describe your program against current references and your own policy.

What evidence closes the finding?

Months of consistent reports showing overdue counts falling and staying down, the gate operating, exceptions expiring and being reviewed, and an independent validation of the numbers. A single clean snapshot rarely closes a repeat issue.

Many overdue criticals already have a fixed version waiting, and the hard part is getting that version merged across every repository. When a fix does not exist yet, the same plan needs a way forward that does not depend on a maintainer's schedule, and the section below sets out both.

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 CLI demo shows a single fix end to end on a developer's machine. You install the CLI, run safeguard to open the interactive terminal and ask it to "fix the lodash CVE in this repo". It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing; then it shows /permissions, /model and /scan . in turn. It is the same fix unit idea from this guide, at the scale of one repository and one engineer.

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

The local runner demo shows how to set up the runner on your own machine, approve it with its device code and then scan from the terminal. For a bank that will not grant repository access to a hosted service, it is a way to build the inventory without moving source code.

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

The Claude demo shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use. An AppSec lead can use the same connection to ask each week which items are still overdue, without building a report by hand.

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

For the product view of this job, see the AI remediation use case. Related reading: how to answer an NCUA exam finding on patching and vendor software, the internal audit request list for application security at a bank, keeping AppSec coverage through a hiring freeze, budgeting engineering time for dependency upgrades each quarter and autonomous remediation in Safeguard: categories, strategies and the off by default setting.

To try the workflow, download Safeguard or start with the documentation.

Quick check

Sources

• 12 CFR Part 30, Appendix B, Interagency Guidelines Establishing Information Security Standards (eCFR)
• Federal Reserve SR 13-13, Supervisory Considerations for the Communication of Supervisory Findings
• SR 13-13 attachment (PDF)
• OCC Bulletin 2026-40, Unsafe or Unsound Practices, Matters Requiring Attention: Final Rule
• Federal Register, Unsafe or Unsound Practices, Matters Requiring Attention (1 September 2026)
• OCC Bulletin 2024-25, FFIEC Cybersecurity Assessment Tool sunset
• CSBS, Vulnerability and Patch Management: Questions Board Members Should Ask (PDF)
• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• NIST SP 800-218, Secure Software Development Framework (PDF)
• CISA, Known Exploited Vulnerabilities
• CISA BOD 26-04, Prioritizing Security Updates Based on Risk
• FIRST, Exploit Prediction Scoring System
• Safeguard docs: Vulnerabilities
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: AI Remediate
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Mitigations
• Safeguard docs: CI integration
• Safeguard docs: Jira integration
• Safeguard docs: Dashboard
• Safeguard use case: AI remediation

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