Pull vulnerability evidence for a bank IT exam in five days

Bank examiners usually ask for the vulnerability and patch management program in writing, an asset and software inventory, scan results for a date range, a list of open findings with their age, the exceptions management approved, and proof that third parties and their software are covered. With five business days, the work is not finding more data. It is mapping each request item to one owner and one source, agreeing a single dated extract with engineering, checking each population before it leaves your hands, and logging exactly what you provided.

This post is a plan for the compliance or GRC lead at a US bank who has just received the first day request list and does not have direct access to the tools where half the evidence lives. The first two thirds work with whatever tools you already run. Safeguard comes in near the end, with its limits stated plainly. Nothing here is legal or regulatory advice, and the request list you receive is the only authority on what your examiners want.

Key takeaways

• The FFIEC Information Security booklet (September 2016) still sets the shape of the vulnerability and patch questions: an inventory of hardware, software, information and connections (II.C.5), a patch management process with seven named parts including a documented exception process (II.C.10(d)), and vulnerability assessments run at a frequency set by risk (IV.A.2).
• The FFIEC Cybersecurity Assessment Tool (CAT) was sunset on 31 August 2025. The FFIEC statement of 29 August 2024 points banks to NIST CSF 2.0, CISA's Cross-Sector Cybersecurity Performance Goals, the Cyber Risk Institute's Cyber Profile and the CIS Critical Security Controls. The examination itself did not go away, and examiners can ask about areas no single tool covers.
• The Interagency Guidelines Establishing Information Security Standards still require regular testing of key controls (III.C.3), service provider oversight (III.D) and at least annual board reporting (III.F). Those three clauses explain most of the third-party and exception questions.
• Agree one extract specification with engineering on day two: fields, date range, scope, time zone and an "as of" timestamp. Every later argument about numbers goes back to that spec.
• Check every population for completeness, date range and scope before you hand it over. A reconciliation to the inventory is the single most useful check.
• Keep an evidence log of every item provided: request number, file name, hash, as of date, who prepared it and who approved its release. That log is next exam's head start.
• Safeguard capabilities covered in this post, all GA: the Compliance and GRC suite (frameworks, controls, evidence, tests, readiness scores), vulnerability management with EPSS and CISA KEV enrichment, reachability analysis, mitigations and risk acceptances with expiry and approval, bulk export in common formats, TPRM vendor management and SBOM requests, SBOM generation, policies and gates, and Portal audit trails.

The situation

The first day letter arrives on a Monday. Of its many items, eight or ten touch vulnerability and patch management, and they are due Friday.

You own the response. You do not own the scanners, the ticketing projects, the code hosts or the container registries. AppSec has one tool, infrastructure another, the cloud team a third, and vendor management keeps its own spreadsheet with a column labelled "SOC report received".

A bad week looks like this. Tuesday brings back three exports with different date ranges and different definitions of "open". Wednesday someone notices a critical application missing from the scan population because it moved to a new cloud account in the spring. Thursday a risk acceptance turns up that expired in July. Friday you send what you have, and the examiner's first follow up asks why the open critical count in the board report does not match your extract.

None of that means the program is weak. It means the evidence was assembled under time pressure without a shared definition. The plan below prevents each of those failures in order.

What examiners usually request for vulnerability and patch management

Request lists differ by agency, examination scope and the bank's size and risk profile. The list you receive defines your obligations. What follows is the shape of the expectations behind it, taken from the primary texts.

The FFIEC Information Security booklet

The FFIEC IT Examination Handbook's Information Security booklet, dated September 2016, is the main reference for this area. Four parts drive most vulnerability requests.

II.C.5, Inventory and Classification of Assets. Management should keep an updated inventory of technology assets, classified by sensitivity and criticality, "including hardware, software, information, and connections." Examination procedure 6 under Objective 6 checks that assets are identified, classified and kept current. That is why the inventory request usually comes first, and why a scan population that does not tie to it is the first thing an examiner tests.

II.C.10(d), Patch Management. Management should use automated patch management and run vulnerability scanners periodically. The booklet lists seven processes: monitoring for available patches, evaluating patches against the threat and network environment, prioritizing across classes of computers and applications, obtaining, testing and securely installing patches, an exception process with appropriate documentation for patches management decides to delay or not apply, carrying production patches into the disaster recovery environment, and updating inventories and recovery plans. Examination procedure 15 under Objective 6 restates these and names "internally developed software provided to customers" as in scope, which matters if your bank ships mobile or web applications.

IV.A.2, vulnerability assessments. A vulnerability assessment defines, identifies and classifies vulnerabilities, with scanners searching for known vulnerabilities such as CVE entries. Frequency comes from the risk management process. So the request is usually scans for a period, plus how you decided the frequency.

II.C.20, Oversight of Third-Party Service Providers. Management should perform due diligence, put security responsibilities in contracts, obtain independent review of the provider's security and verify that the third party's cyber risks are identified, measured, mitigated, monitored and reported. Requests about vendor patching, SOC reports and contract clauses start here.

The FFIEC's Architecture, Infrastructure, and Operations booklet (June 2021) covers vulnerability and patch management in section VI.B.3. The FFIEC site blocked our automated requests, so we rely on a South Dakota Division of Banking fact sheet that quotes it: a program that identifies vulnerabilities, prioritizes them by risk and remediates in a timely way, including cloud systems the institution is responsible for. Check the booklet itself before you cite it.

The Interagency Guidelines

The Interagency Guidelines Establishing Information Security Standards sit in each agency's rules (for national banks and federal savings associations, Appendix B to 12 CFR Part 30). Three sections matter for this week.

• III.C.3 requires the bank to regularly test the key controls, systems and procedures of the information security program, with frequency and nature set by the risk assessment, and with tests conducted or reviewed by independent third parties or staff independent of those who run the program. Scan results and penetration test reports are evidence for this clause, which is why examiners ask who reviewed them.
• III.D requires due diligence in selecting service providers, contracts that require appropriate security measures, and, where the risk assessment calls for it, monitoring that includes reviewing audits, summaries of test results or equivalent evaluations.
• III.F requires a report to the board or a board committee at least annually, covering the program's overall status and material matters such as risk management and control decisions, service provider arrangements and results of testing. Examiners often compare the numbers in that report to the numbers in your extract.

What that becomes on a request list

The table below translates those sources into the requests GRC leads commonly see. It is a planning aid, not a list of what your examiners will ask.

What replaced the FFIEC CAT, and does it change the request?

The FFIEC, on behalf of its members, issued a statement on 29 August 2024 that it would sunset the Cybersecurity Assessment Tool on 31 August 2025. The OCC published it as Bulletin 2024-25, the FDIC as FIL-61-2024, and the Federal Reserve as SR 24-7. The Federal Reserve's letter says the CAT was released in June 2015 as a voluntary tool and would be removed from the FFIEC website on 31 August 2025.

There is no single successor. The statement names four resources banks can use instead: NIST Cybersecurity Framework 2.0, CISA's Cybersecurity Performance Goals, the Cyber Risk Institute's Cyber Profile and the CIS Critical Security Controls. CISA has since published Cross-Sector CPGs 2.0, which it says are aligned to the CSF 2.0 functions and add a Govern function.

Does this change the request list? Mostly, it changes the framing rather than the evidence.

• If your bank used the CAT's maturity levels as the backbone of its self-assessment, examiners may ask what you use now and how you mapped to it. A clear answer is "we assess against CSF 2.0 (or the CRI Profile) and here is the mapping", with the date of the last assessment.
• The Federal Reserve's letter says examiners "may address areas not covered by all tools" and that its examinations are risk focused. So a clean self-assessment against any framework does not replace the handbook based procedures.
• Old CAT maturity ratings are history. Present them as the prior baseline if they help show progress, not as the current assessment.

If you have moved to CSF 2.0, these subcategories line up with the vulnerability requests: ID.AM-02 (inventories of software, services and systems are maintained), ID.AM-04 (inventories of services provided by suppliers are maintained), ID.RA-01 (vulnerabilities in assets are identified, validated and recorded), ID.RA-08 (processes for receiving, analyzing and responding to vulnerability disclosures are established), PR.PS-02 (software is maintained, replaced and removed commensurate with risk) and GV.SC-07 (supplier risks are understood, recorded, prioritized, assessed, responded to and monitored). NIST SP 800-40 Revision 4 (April 2022) is the matching NIST guide for patching. It defines enterprise patch management as identifying, prioritizing, acquiring, installing and verifying patches, updates and upgrades, and frames patching as preventive maintenance rather than an emergency activity.

Step by step: the five-day plan

The plan assumes the request list arrived on day one, the due date is the end of day five and you can get one or two hours a day from an engineer in each team that owns a source. Adjust the days to your calendar. The order matters more than the dates.

Day one: map every item to a source and an owner

Read the whole list once, then give every item that touches vulnerability, patch, inventory, testing or third-party software a row in a tracker.

1. Copy the request number and wording exactly. Do not paraphrase.
2. Decide the evidence shape: a document, a population (a list of records), a sample, or a narrative.
3. Name one system of record. If two overlap, pick one and write down why.
4. Name one owner and one backup: the person who can pull the data, not their manager.
5. Write down the access you need, and ask for a read only role today, not on Thursday.
6. Send scoping questions to your examiner liaison on day one, not day five.

A tracker row needs only a few columns:

Before you close day one, tell each owner what you need, by when, and that a spec is coming tomorrow, so nobody exports early in their tool's default shape.

Day two: agree one extract specification with engineering

This is the most important day. One written spec, agreed by the owners, decides what "open", "critical" and "remediated" mean for this response.

1. Fields. For vulnerability populations, ask for: finding identifier, asset or application identifier, environment, component and version where relevant, CVE or other identifier, severity as your policy defines it, CVSS score, whether it is on the CISA Known Exploited Vulnerabilities catalog, first detected date, due date under policy, status, closed date, and exception reference if any.
2. Severity source. State whether severity is the scanner's rating, CVSS, or your policy's adjusted rating. If your policy adjusts for exploitation or exposure, say so and keep both columns.
3. Date range. Use the period on the request list. If none is stated, use the period since the last examination and say so in the cover note.
4. Scope. List the asset classes and environments in scope: production servers, workstations, network devices, cloud workloads, container images, internally developed applications, applications provided to customers. Mark anything excluded and the reason.
5. Time zone and timestamp. Agree one time zone and an "as of" time for every extract, for example the close of business on day two.
6. Query. Ask each owner to save the exact filter or query used, so the extract can be reproduced in a follow up request.
7. Format. CSV or Excel for populations, PDF for documents. Ask for no hidden columns, no merged cells and no colour coded status.

Keep the spec to one page.

Day three: pull, then check each population

Run the checks in the next section before you summarize anything.

1. Confirm each file matches the spec: fields present, period correct, as of timestamp shown.
2. Reconcile scope against the inventory (the next section shows how).
3. Recompute the summary numbers yourself from the population: counts by severity, ages, on time rate.
4. Compare those numbers with the most recent board or committee report. If they differ, find out why now and write the reason down.
5. Pull the exception register and tie each open exception to findings in the population.

Day four: exceptions, third parties and narratives

1. Exceptions. Check each open exception for an approver, approval date, expiry date, justification and any claimed compensating control. List expired ones separately with what happened to each. Missing approvals matter more than the number of exceptions.
2. Third parties. Assemble the in-scope vendor list, the latest review date for each critical vendor, the independent reports you reviewed and the contract clauses on security and notification.
3. Narratives. Where the request says "describe", write what the process is, who runs it, how often and where the evidence sits.
4. Owner review. Ask each owner one yes or no question: is this accurate as of the timestamp?

Day five: package, approve and log

1. Name files consistently, for example the request number, a short title and the as of date.
2. Write a one page cover note per request that states the period, the as of timestamp, the scope and exclusions, and any caveats.
3. Get release approval from whoever your bank requires (often the CISO, the chief risk officer or legal).
4. Hash each file and enter it in the evidence log before you upload or send it.
5. Provide the evidence through the channel your examiners specify, and record when you did.
6. Keep a copy of exactly what you provided, separate from working files.

If something is not ready, say so plainly in the cover note with a date. A known gap with a date reads better than a population that later turns out to be wrong.

How to check a population before you hand it over

Examiners test populations because samples drawn from an incomplete population prove nothing. Run these checks yourself first. They take an hour or two per population, and they are the difference between a clean first round and a week of follow ups.

A worked example, with illustrative numbers. The inventory lists 400 production servers in scope; the host scan extract covers 372. Of the 28 gaps, 15 were decommissioned (recorded in the change system), 9 are appliances the vendor scans under contract, and 4 sat in a new cloud account never added to the scan schedule. The first two groups are explanations. The last is a finding you report yourself, with the dates you fixed the schedule and first scanned them. Redo this with your own numbers; every gap needs a written reason before the examiner asks.

For applications and containers, also confirm that internally developed applications appear at all, and that production images are represented by the image actually running, not only the latest build.

How to show third-party and open source components are in scope

There are two different "third-party" questions, and it helps to answer them separately.

Third-party service providers

The first is about service providers: the core processor, the online banking platform, managed security providers, cloud providers. The expectation comes from the Interagency Guidelines III.D, from the booklet's section II.C.20 and from the Interagency Guidance on Third-Party Relationships: Risk Management, which the OCC, the Federal Reserve and the FDIC issued on 6 June 2023 (OCC Bulletin 2023-17). That guidance describes a risk management life cycle and says that not all third-party relationships carry the same level of risk or criticality.

Examiners typically want to see which critical vendors hold customer information, that contracts require security measures and notification, that you reviewed the vendors' independent reports, and that vendor managed systems are not silently missing. For hosted systems you cannot scan, the evidence is the contract, the report, your review and any vendor vulnerability notices.

Open source and third-party software inside your own applications

The second question is about software inside systems you build or run: open source libraries in your applications, packages in container images, components in vendor software on your servers. The booklet's inventory covers software, and procedure 15 covers software provided to customers. Host scanners often miss these components, so the clearest evidence is a software bill of materials (SBOM) per application or image, plus the findings matched against it.

CISA's 2026 update to the SBOM minimum elements adds data fields and practices to the earlier baseline. Bank examinations do not require conformance to it, but it is a fair reference for what a usable SBOM contains. For vendor software, show which SBOMs or component lists you asked for and received.

How to log what was provided and keep it for the next exam

An evidence log answers three later questions: what exactly did we give them, as of when, and who approved it.

Keep the log and the provided copies in one restricted location under your retention schedule; see how long to keep vulnerability records and change tickets. When the exam closes, add the findings and your responses, plus a short note on what you would extract differently next time.

For the general mechanics of a request list, see what a PBC list is and how to answer it. For keeping each response to what was asked, see how to respond to an auditor evidence request without over sharing.

How Safeguard does this

This section shows the same five days when the software supply chain evidence sits in Safeguard. Every capability named is generally available (GA), and screens and steps come from docs.safeguard.sh. Safeguard covers the software side: the code, dependencies, container images, SBOMs and vendor software you connect or upload. It does not replace host and network scanners for systems it does not scan.

1. Get read only access on day one. Safeguard's roles are Tenant Admin, Manager, User and Viewer, with SSO group mapping. Ask for a Viewer role covering every organization in the exam. The docs say exports respect RBAC, so you only export what your role can see.

2. Choose your frameworks (Compliance and GRC suite, GA). Open Compliance › Manage, then the Frameworks tab, switch a framework on and select Save. It then appears on Compliance › Frameworks, Controls and Overview. For a bank, the relevant entries include NIST CSF 2.0 and GLBA. There is also an FFIEC CAT framework page; treat it as a legacy mapping for continuity with an older self-assessment, not as current guidance. The docs say choosing a framework does not certify compliance.

3. Read the readiness score for what it is. The docs define it as the share of in-scope requirements that pass, either on a scan that finds them met or on a person's attestation that names its evidence. A requirement scoped out with a written justification leaves the score. The docs call it Safeguard's assessment of what it can see, "not an audit opinion or a certification." Use it to find gaps before day five, not as evidence for the examiner.

4. Use automated tests where they exist. Per the docs, connected systems run automated tests that map to SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS, NIST CSF 2.0 and the CIS benchmarks, and a crosswalk carries that evidence to equivalent controls elsewhere. For a bank that moved from the CAT to CSF 2.0, this is the most direct route from connected systems to control evidence.

5. Pull the vulnerability population (vulnerability management, GA). In the Enterprise Software Supply Chain Manager (ESSCM), each project's Vulnerabilities tab groups findings as Critical, High, Medium, Low and Exploitable (known exploitation in the wild). Each finding carries the CVE, CVSS, EPSS, exploited status, affected component and version, fixed version, references and reachability. Filters include severity, CVSS and EPSS ranges, exploitable status, component, fix availability, reachability and date range, which is how you apply the spec's period. Data comes from the NVD, GitHub Security Advisories, OSV, CISA KEV, vendor bulletins and researcher disclosures, and projects are re-evaluated daily as new CVEs publish.

6. Export in the spec's format (bulk export, GA). Tables support filtering, sorting and column selection, with export to CSV, Excel, PDF, JSON and other formats. Select the spec's columns, apply the date filter, export, and record the filter in your tracker.

7. Show reachability as a column, not a filter (reachability analysis, GA). Reachability ranks findings by whether the vulnerable code path is called, alongside EPSS, KEV and business context. Use it in your prioritization narrative, but keep unreachable findings in the population. Dropping them is a scope decision your policy must support.

8. Pull the exception record (mitigations and risk acceptances, GA). In a project's Mitigations tab, each record has a type (Risk Acceptance, False Positive, Workaround or Not Applicable), a justification, an expiry date for risk acceptances, an Approved By field, optional evidence and a scope. Status is Active, Expired, Revoked or Superseded. Filter by Status: Expired to find lapsed acceptances, then extend, revoke or fix each one. The docs say owners are notified 14 and 7 days before expiry and on the day. List any mitigations auto-applied by a mitigation policy separately; the examiner will want to see who approved the policy.

9. Keep approvals with people. The Requests and approvals docs say a policy, evidence, an access review, a test exclusion or a risk acceptance counts only once a person decides it, and that the AI assistant and MCP clients can prepare work but never approve, accept or sign off. That matches the booklet's expectation of a named approver.

10. Run a compliance report for the period. The Compliance docs list pre-built reports, including a vulnerability summary and an SBOM completeness audit, and a custom flow: navigate to Reports, select Create Report, select the framework, configure scope and date range, then generate and export. Use the spec's as of date and range so report and population agree.

11. Show the open source inside your applications (SBOM generation and analysis, GA). Safeguard generates SPDX and CycloneDX SBOMs for connected repositories, container images and uploaded manifests, with the full transitive dependency inventory. Export the SBOM per in-scope application or image with its findings.

12. Show third-party oversight for vendor software (TPRM, GA). The Third-Party Risk Manager's vendor directory records each vendor's products, contact, contract status, risk tier (Critical, High, Medium, Low), SBOM status and last assessment date. You can bulk import vendors from a CSV template, link contracts with SLA terms, security requirements and SBOM obligations, and invite vendors to a self-service portal to submit SBOMs and answer questionnaires. SBOM requests are tracked from Sent to Validated or Rejected, and monitoring alerts on new critical vulnerabilities or KEV additions. Export the critical vendor list with SBOM status and last assessment date, and attach your own review notes.

13. Show the rules are enforced (policies and gates, GA). If your policy says known exploited vulnerabilities must not reach production, policies and gates can enforce it at build, CI and release with Block, Warn or Notify actions, with approvals handled through exceptions. A gate configuration and its outcome history show the written timeline applied in the pipeline.

14. Keep the trail of what you shared (Portal, GA). Portal, the SBOM publish and share product (not the free entry tier of the same name), logs every action, records who accessed what and when, and exports the trail for auditors. Publishing creates an immutable copy; sharing distributes that copy as is.

15. Feed your own evidence log. Exports and audit trails support the log; they do not replace it. Hash each file, record the filter or report settings and file it under the request number.

Autonomous remediation (GA) can open tested fix pull requests, but it ships switched off, with every category set to Manual. Leave it that way during exam week; changing remediation behaviour while populations are pulled makes the as of timestamp harder to defend.

Request item versus Safeguard versus what you still own

What Safeguard does not do

What remains the bank's

• The examiner relationship. Safeguard does not talk to examiners, receive request lists or submit responses. Your liaison, your cover notes and your clarifying questions stay with you.
• Narrative answers and judgements. Safeguard does not write your narrative responses or decide what your policy means. Its AI assistant can help prepare drafts, but release decisions, approvals and sign offs are made by people.
• Approval and release. Who approves an exception, who signs the self-assessment and who releases evidence to examiners are governance decisions for your bank.

Coverage and other limits

• Evidence covers what is connected and scanned. Safeguard's findings cover the repositories, container images, uploaded manifests and SBOMs, and vendor software you bring into it. Operating systems on hosts outside scanned images, network devices, end user devices and vendor hosted services need their own evidence from the tools and contracts that cover them.
• The FFIEC CAT page is a mapping, not guidance. The CAT entry in Safeguard's framework library maps scan requirements and catalog controls to CAT domains. The CAT itself was retired on 31 August 2025, so the page is useful for continuity only. It is not current examination guidance and not an FFIEC product.
• The GLBA page maps to the FTC rule's text. Safeguard's GLBA framework page cites the FTC Safeguards Rule (16 CFR Part 314). Banks supervised by the OCC, the Federal Reserve or the FDIC follow the Interagency Guidelines in their own agency's rules instead, so check which text applies to your charter before you cite a control from that page.
• A readiness score is not an audit opinion. The docs say so directly. Use it to find gaps, not as evidence of compliance.
• No regulatory or legal advice. Safeguard and this post describe common evidence shapes. Your request list, your regulator and your counsel decide what is required.
• Posture. Safeguard's own posture is stated as a platform designed for FedRAMP High and with a SOC 2 Type II audit in progress. If your vendor management team needs to assess Safeguard as a service provider, request the Trust Center materials rather than relying on marketing copy.

Common mistakes

• Default exports. Three tools' defaults give three definitions of open. Send the spec before anyone pulls data.
• A summary without its population. Examiners recompute summaries. Provide both.
• Counting risk accepted findings as closed. They are open findings with a documented decision.
• Forgetting expired exceptions. A lapsed exception is a finding in itself.
• Silently filtering out unreachable or low EPSS findings. Prioritization belongs in a column and the narrative.
• Leaving out applications provided to customers. Procedure 15 names them.
• Mixing as of dates. Use one timestamp and say so.
• Presenting CAT maturity levels as current. Show what you assess against now.
• Live tool access instead of fixed extracts. A live view cannot be reproduced; still provide a dated extract.
• Not logging what left the building. Without a log and a hash, you cannot prove what you provided.

FAQ

What vulnerability management evidence do bank examiners request?

Commonly the policy, the inventory, scan results for a period, open findings by severity and age, remediation against policy timelines, the exception register, penetration test reports and third-party oversight evidence, following booklet sections II.C.5, II.C.10(d), IV.A.2 and II.C.20. Your request list is the authority.

What replaced the FFIEC Cybersecurity Assessment Tool?

Nothing replaced it one for one. The FFIEC sunset the CAT on 31 August 2025 and named NIST CSF 2.0, CISA's Cybersecurity Performance Goals, the Cyber Risk Institute's Cyber Profile and the CIS Critical Security Controls as resources banks can use instead.

Do examiners still use the FFIEC IT Examination Handbook?

The handbook booklets remain the examiners' reference. The Information Security booklet is dated September 2016, and the Architecture, Infrastructure, and Operations booklet, which covers vulnerability and patch management in VI.B.3, is dated June 2021. Retiring the CAT did not retire the handbook.

How far back should a vulnerability extract go?

Use the period on the request list. If none is stated, ask your liaison; the period since the last examination is a common default. State it in your cover note.

How do I prove a vulnerability population is complete?

Reconcile it to the inventory in both directions, explain every gap in writing, confirm the date range and as of timestamp, remove duplicates and recompute the summary numbers from the population. Save the query so it can be rerun.

Should risk accepted vulnerabilities appear as open?

Yes, in most cases. They are open findings with a documented, approved, time limited decision. Show them in the open population with the exception reference, approver and expiry date.

How do I show open source components are covered?

Provide an SBOM per in-scope application or container image, and the findings matched against it. The booklet's inventory section covers software, and examination procedure 15 covers internally developed software provided to customers.

What should an evidence log for an examination contain?

The request number and text, file name and version, a hash, the as of timestamp and period, the source system and saved query, who prepared, reviewed and released it, when and how it was provided, and any follow up requests linked to it.

Can a compliance tool's readiness score be given to examiners as evidence?

Be careful. A readiness score is a tool's view of what it can see. Safeguard's own docs say its readiness score is not an audit opinion or a certification. Provide the underlying evidence and let the score stay an internal gap finder.

Does the 2023 interagency third-party guidance apply to software vendors?

The June 2023 interagency guidance applies to banks' third-party relationships broadly and scales oversight to risk and criticality, so technology providers supporting critical activities get the closest look.

Most of the open findings in a population like this sit in open source dependencies and container images that your teams build, and that is also where the exception register grows when no fix is available yet. The section below describes how Safeguard closes those two gaps, so fewer items reach the exception register at all.

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 shows Claude connected to Safeguard through its MCP server: you add Safeguard from Claude's connector directory, sign in with OAuth and choose which Safeguard tools Claude may use. For an exam week, the same connection lets a GRC lead who does not live in engineering's tools ask plain questions, such as which projects had open critical findings during the period, and then go to the app to export the population the spec defines. The assistant can prepare work; approvals and release stay with people.

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

The second demo is a real desktop app session. The CLI session shows in the desktop app's conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with a dependency upgrade done and tests passing. It does not show an examination response. It shows how an engineer can close a finding with every change approved by a person, which is the kind of record an exception or remediation narrative can point to.

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

Quick check

Sources

• FFIEC IT Examination Handbook, Information Security booklet, September 2016 (archived copy of the ithandbook.ffiec.gov PDF)
• OCC Bulletin 2024-25, FFIEC Cybersecurity Assessment Tool Sunset Statement
• FDIC FIL-61-2024, Sunset of the FFIEC Cybersecurity Assessment Tool
• Federal Reserve SR 24-7, FFIEC Cybersecurity Assessment Tool Sunset Statement
• 12 CFR Part 30, Appendix B, Interagency Guidelines Establishing Information Security Standards (eCFR)
• OCC Bulletin 2023-17, Interagency Guidance on Third-Party Relationships: Risk Management
• NIST Cybersecurity Framework 2.0 (NIST CSWP 29)
• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• CISA Cross-Sector Cybersecurity Performance Goals
• CISA Software Bill of Materials (SBOM)
• South Dakota Division of Banking, Vulnerability and Patch Management fact sheet
• Safeguard docs: Compliance
• Safeguard docs: Compliance frameworks
• Safeguard docs: FFIEC CAT framework page
• Safeguard docs: GLBA framework page
• Safeguard docs: ESSCM Vulnerabilities
• Safeguard docs: ESSCM Mitigations
• Safeguard docs: Requests and approvals
• Safeguard docs: TPRM Vendor Management
• Safeguard docs: Portal
• Safeguard docs: Analytics and Dashboards

Related reading: software bill of materials expectations from banking regulators.

To try the flows in this post, download Safeguard or read the Safeguard docs.

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