Five Scanners, One Queue: Consolidating Findings at a Regulated Bank

If your bank runs several scanners that each report the same vulnerable library in their own console, the fix is not another scanner. Pick one system of record, give every finding a stable identity key, merge duplicates while keeping every scanner's evidence attached, start each remediation clock once, and tell your examiner and auditors exactly how the count changed. Do it in that order and the queue your engineers work from becomes the same number your board and your regulator see.

This guide is for the Head of Application Security or Product Security at a US bank, credit union, broker dealer or payments company, usually after an audit observation that vulnerability numbers do not reconcile, a board question nobody can answer with one figure, or an engineering revolt over ticket floods. The first two thirds work with whatever tools you already own. Safeguard appears only in the section headed "How Safeguard does this". Nothing here is legal, regulatory or audit advice; read the primary texts linked below with your compliance and legal teams.

Key takeaways

• No US banking rule requires a single queue. Every one of them requires you to identify vulnerabilities, rank them by risk, fix them on a documented timeline and prove it. Duplicate findings make all four harder to show.
• The most common exam problem with scanner sprawl is not missed vulnerabilities. It is two reports that disagree, and a remediation clock nobody can explain.
• Consolidation is a data problem first: one system of record, one finding key per finding type, one severity scale that follows your written policy, and one place where exceptions are approved.
• Merge, never delete. A merged finding keeps every source scanner's evidence and first-seen date, so an auditor can trace any number back to raw output.
• Tell examiners before your metrics move. A drop in open findings that you did not explain looks like a reporting change, because it is one.
• In Safeguard, first-party engines report into one unified findings model (GA), AutoTriage collapses cross-scanner duplicates into one correlated finding (GA), vulnerability prioritization uses EPSS, CISA KEV and reachability analysis (GA), and policies and gates (GA) enforce your timelines with Block, Warn and Notify actions, with approval handled through exceptions.
• Autonomous remediation (GA) ships switched off, with every category set to Manual.

The situation

The audit committee pack is due Friday. Your vulnerability slide says 412 open critical and high findings, sourced from the container scanner. The infrastructure team's slide says 1,130, sourced from the network scanner. The second line of defence has a third number from the GRC tool, which imports from two of your five scanners and none of the others. Internal audit opened an observation last quarter titled something like "vulnerability metrics are not reconciled across sources", and the follow-up date is three weeks out. All of these numbers are illustrative; yours will differ.

Meanwhile engineering has stopped reading security tickets. One outdated library in one service produces a dependency finding, a container layer finding, a host finding after deployment, and sometimes a dynamic test finding. That is four tickets, four severities, four due dates and four owners for one fix. When the developer bumps the version, three close on the next scan and the fourth stays open for a month because the host scanner runs weekly against an image tag nobody uses any more.

A bad week here looks like this:

• An examiner asks for every critical finding open longer than your policy allows, with evidence of the approval for each one, and the honest answer is "which tool do you want it from?"
• A board member asks whether a widely reported exploited vulnerability affects you. Three teams answer, with three different lists.
• Your remediation SLA report shows a finding as 90 days overdue that was fixed in week one, because the duplicate in another tool never closed.

Scanner fatigue in a regulated shop is about volume you cannot explain to someone with the authority to write it up.

What the rules behind the finding actually ask for

None of the documents below mention a "queue". Read them for what they ask you to show: that vulnerabilities are identified, ranked by risk, remediated on a timeline you wrote down, and that management can see the status. Every one of those becomes easier to prove with one deduplicated record per issue, and harder with five overlapping ones.

The Interagency Guidelines and the FTC Safeguards Rule

For national banks and federal savings associations, the Interagency Guidelines Establishing Information Security Standards sit in Appendix B to 12 CFR Part 30 (the FDIC and Federal Reserve versions are parallel). Section III.C (Manage and Control Risk) asks the institution, among other things, to regularly test the key controls, systems and procedures of its program (III.C.3). Section III.F requires a report to the board or a board committee at least annually on the overall status of the program, discussing material matters such as risk management and control decisions and results of testing. If your test results come from five sources that disagree, that annual report starts from a weak base.

Non-bank financial institutions under FTC jurisdiction work to the Safeguards Rule at 16 CFR Part 314. Section 314.4(d)(2) is unusually specific: where there is no effective continuous monitoring, you must run annual penetration testing and vulnerability assessments at least every six months, plus after material changes. Section 314.4(i) requires the Qualified Individual to report in writing to the board at least annually on the program's overall status and material matters.

The FFIEC Information Security booklet

The FFIEC IT Examination Handbook's Information Security booklet is still the reference most bank examiners carry. Its patch management section, II.C.10(d), says management should establish a monitoring process for available patches, a process to evaluate them against the threat and network environment, a prioritization process across classes of systems and applications, and an exception process, with appropriate documentation, for patches management decides to delay or not apply. It also expects in-house software to be kept patched. Examiners use the booklet to frame questions; how your institution meets it is up to you.

The FFIEC Cybersecurity Assessment Tool, which many banks used to map maturity, was retired on 31 August 2025. If your vulnerability management narrative still cites CAT maturity levels, update it before the next exam.

NYDFS Part 500

If you hold a New York charter or license, 23 NYCRR 500.5 requires penetration testing at least annually (500.5(a)(1)), automated scans plus manual review of systems the scans do not cover, at a frequency set by your risk assessment (500.5(a)(2)), a monitoring process so you are promptly informed of new vulnerabilities (500.5(b)), and timely remediation "giving priority to vulnerabilities based on the risk" they pose (500.5(c)). "Prioritized by risk" is hard to evidence when the same vulnerability carries three different severities.

PCI DSS v4.0.1

If you process card data, PCI DSS v4.0.1 is the most concrete text on this subject. Requirement 6.3.1 asks you to identify security vulnerabilities using industry recognized sources and assign each a risk ranking. Requirement 6.3.3 asks that applicable security patches are installed, with the one month window after release applying to critical vulnerabilities; the PCI Security Standards Council says v4.0.1 reverted that window to critical vulnerabilities only, with other patches on a time frame you set. Requirement 11.3.1 asks for internal vulnerability scans at least once every three months, with high risk and critical vulnerabilities resolved and rescans confirming it. Your assessor will sample findings and ask for the trail from detection to closure. Two trails for one finding invite a question you would rather not answer in the room.

NIST SP 800-40 Rev. 4 and SP 800-53

NIST SP 800-40 Revision 4, published in April 2022, reframes patching as preventive maintenance and asks organizations to define risk response scopes and maintenance plans rather than treating each CVE as an emergency. NIST SP 800-53 Rev. 5 control RA-5 (vulnerability monitoring and scanning) asks you to analyze scan reports (RA-5c) and remediate legitimate vulnerabilities within organization-defined response times based on a risk assessment (RA-5d). RA-5b is the closest any standard comes to this post's topic: it asks for tools and techniques that "facilitate interoperability among tools" by using standards for naming flaws and measuring impact. SI-2c asks you to install security updates within a defined period of their release. Many banks use these as their policy vocabulary even though they are not binding on a private institution.

CISA BOD 26-04 as a reference point

Binding Operational Directive 26-04 applies to federal civilian agencies, not to banks. Issued on 10 June 2026, it replaced the revoked BOD 22-01 and moves from fixed deadlines to risk-based timelines built on four factors: KEV status, exploit automation, technical impact and asset exposure. It is useful as a published, defensible model for how a risk-based clock can work, and some institutions borrow its structure for their own policy. Cite it as a reference, never as a requirement.

What follows from all of this

Why regulated shops end up with five scanners

Nobody designs this. In a bank each addition was usually a reasonable answer to a specific obligation: a host scanner for PCI quarterly scans, static analysis for the secure development policy, a composition tool after a supply chain scare, the cloud provider's image scanner because it was one click, dynamic testing because an assessor recommended it. Each is defensible alone. Together they produce overlapping findings with incompatible severity scales, different names for one asset, and no shared idea of what "fixed" means. The answer is not to rip tools out on day one. It is to put one record in front of all of them.

Step by step: consolidating findings into one queue, with or without a new tool

These steps work with spreadsheets, a ticketing system and the scanners you already have. Expect the first pass to take a quarter, not a sprint.

1. Inventory every emitter

List every tool or process that creates a security finding. Include the ones that only produce PDF reports. For each, record the fields below. This table is your scoping document and the first artefact internal audit will want.

The "Regulatory driver" column matters. It tells you which tools you cannot switch off without changing a policy or a commitment to an examiner or assessor.

2. Choose one system of record

Decide where the canonical record of each finding lives. It can be a vulnerability management platform, an ASPM product, your GRC tool, or a ticketing project, but it must be exactly one. Every report to management and every answer to an examiner comes from it. The scanners become sources, not records.

A useful test: if an examiner asks "how many critical findings were open past due on 30 September?", which single query answers it? If the honest answer involves a spreadsheet join, you do not have a system of record yet.

3. Give every finding a stable key

Deduplication only works when the same issue produces the same key no matter which tool saw it. The key differs by finding type. Here is a starting template.

Two things make the key work: normalize identifiers to a CVE where one exists (tools mix advisory IDs, CVEs and internal IDs), and express packages in the package URL format (purl), because tools spell ecosystem names differently. The related post on deduplicating findings across scanners goes deeper on key design.

4. Merge, and keep the evidence

When two findings share a key, merge them into one record. Never delete the source rows. The merged record should carry:

• the earliest first-seen date across all sources (this is your clock start, see step 6);
• every source scanner, with a link to its raw output;
• the highest severity any source assigned, until your policy rescoring in step 5 replaces it;
• a merge log entry: who or what merged it, when, and on what key.

The merge log is the piece auditors care about. If you cannot show why two rows became one, a drop in the count looks like suppression.

Watch for false merges. Two findings on the same CVE in the same package but in two different services are two findings, with two owners. The key must include the asset or service, or you will close one team's finding when the other team fixes theirs.

5. Rescore once, against your written policy

Each scanner ships its own severity logic. Your policy should define one. A defensible model for a regulated institution combines:

• the CVSS base score from the authoritative source, as a starting point only;
• whether the vulnerability is on CISA's Known Exploited Vulnerabilities catalog;
• the FIRST EPSS probability that it will be exploited in the next 30 days;
• whether the vulnerable code is reachable in your application, where you can tell;
• the asset's criticality and exposure (internet facing, handles customer data, in PCI scope).

Write the scoring rule down, version it, and attach the version to every finding. When the rule changes, you can explain why a finding's due date moved. The point of PCI DSS 6.3.1's "risk ranking" and NYDFS 500.5's "prioritized by risk" is that the ranking is yours and documented, not whatever a vendor's default happens to be.

6. Start every clock once

The clock is the biggest source of audit friction after consolidation. Decide, in policy, that the remediation clock starts at the earliest first-seen date across all sources for that key, and that it does not restart when a second scanner sees the same issue. Write down what happens when a finding is rescored: most institutions keep the original first-seen date and recompute the due date from the new severity.

Here is an illustrative timeline table you can adapt. The numbers are examples, not a recommendation; set your own with your risk committee.

If you process card data, make sure the critical rows are no looser than the one month window PCI DSS 6.3.3 sets for critical patches.

7. One owner per finding, routed by asset

Route each merged finding to the team that owns the asset, not to the team that owns the scanner. That means maintaining an asset to owner map (repository, image, host and application to team). Without it, consolidation creates one big queue with no owner, which is worse than five small queues with owners.

8. One exception process

Risk acceptances, false positive markings and compensating controls must live on the merged finding, with a justification, an approver and an expiry date. If a developer marks a finding as not applicable in one tool, that decision should apply to the merged record and therefore to every source. Give each not applicable decision a reason code and, for code you build, an expiry, because a function that was not called in March may be called in June. For third party software where the supplier says a CVE does not affect their product, ask for a machine readable VEX statement (CSAF VEX or CycloneDX VEX) and attach it, rather than a sentence in an email.

9. Run in parallel, then turn off the duplicate pipes

For one full reporting period, run the old reports and the new queue side by side. Reconcile the differences line by line: every finding in an old report should map to a merged record, or have a written reason why not (out of scope asset, already closed, different key). Only after that reconciliation is signed off should you stop the old tools from creating tickets directly. Keep the scanners themselves running where a regulatory driver requires them or where one covers an asset class nothing else does; you are removing duplicate destinations first, not detection. Retiring a tool is a change to your control inventory, so tell your second line before it happens.

10. Report the change before the numbers move

Write a one page methodology note for internal audit, your second line and, through your usual channel, your examiner. It should say what changed, the date it changed, how findings are now counted, how the clock is computed, and a reconciliation of the last old period to the first new one. Then report both counts for one period, and either restate historical trends under the new method or mark the chart where the method changed. Do not frame it as "we now have fewer vulnerabilities". You have the same vulnerabilities; you now count each one once.

Which questions an examiner or auditor will ask, and what to hand them

The questions below are typical of the shape of exam and audit requests on this topic. They are not quotes from any letter.

How do you deduplicate without losing the audit trail?

The rule is simple to say and easy to break: merging changes how you display findings, never what you recorded. Keep raw scanner output immutable, store it with a retention period that matches your record keeping policy, and make every merge reversible. If a merge was wrong (step 4's false merge), you should be able to split the record and get both histories back.

Store three dates for every merged finding: first seen by any source, first seen by each source, and merged on. That lets you answer both "when did you know?" and "when did your process recognize it as one issue?", which are different questions and both come up.

Which tool should be the system of record?

The right answer depends on where your people already work and where your evidence must live. Use these criteria rather than a vendor shortlist:

• It can ingest every emitter you must keep, either natively or through a documented import.
• It stores raw evidence or links to it, and keeps a merge and status history.
• It supports your finding key, or lets you define one.
• It models exceptions with approver and expiry, not just a "won't fix" status.
• Its reports can be reproduced by query, so an auditor can rerun them.
• Its access model fits your segregation of duties: the people who approve exceptions are not the people who own the fix.

If the winner is not your GRC tool, feed the GRC tool from it.

A worked example: one library, four rows, one record

This example is illustrative, with invented names and round numbers.

A payments service, call it ledger-api, uses an old version of a JSON parsing library with a published high severity CVE. Before consolidation, four rows exist:

1. The composition scanner reports the CVE in ledger-api's lockfile on 2 September, severity High.
2. The container scanner reports it in the ledger-api image on 4 September, severity Critical (it uses a different CVSS version).
3. The host scanner reports it on two production nodes on 9 September, severity High.
4. The dynamic test does not report it, because the vulnerable parser path is not reachable from the outside.

After consolidation, there is one record keyed on CVE plus package URL plus service ledger-api. First seen is 2 September. Sources are three scanners, each linked. Policy rescoring takes the authoritative CVSS score, checks KEV (not listed) and EPSS (low), and notes that the service handles cardholder data, which raises its asset criticality. The policy result is High, due 2 October. One owner: the payments platform team. One ticket. When the team upgrades the library on 20 September, the next scan from each source confirms the fix and the merged record closes with three confirmations attached.

The report your board sees counts this as one high finding, closed in 18 days. The examiner, if they sample it, sees the trail from three sources to one record to one fix.

How Safeguard does this

Everything below comes from Safeguard's offering documentation and docs.safeguard.sh. Where the docs do not show a screen or command, this section describes the outcome only. Every capability named here is generally available (GA).

1. Bring first-party scanning into one findings model

Safeguard runs its own engines for software composition analysis (SCA, GA), static analysis (SAST, GA), dynamic testing of verified targets (DAST, GA), container images and infrastructure as code. According to the Unified Findings docs, these engines do not each keep a separate inbox. They report into one unified findings model (GA), where each record carries a finding type, and you browse them from a single Findings tab per project.

The Findings tab has a Scanner dropdown. "All scanners" is the default and shows every finding type together; picking one engine narrows the table and its summary statistics to that engine. The project Info page shows a Scanner Coverage section with one card per scanner and a live finding count, which gives you the coverage view from step 1 without building it by hand. Dependency vulnerabilities from SCA live in their own Vulnerabilities tab, which the docs say is deliberate, to avoid showing the same data twice.

Because findings share one model, the docs say they share correlation keys: a dynamic test result can be linked to the static analysis source that produced it, so a confirmed, reachable issue is prioritized together across engines. Every finding is scoped to your tenant and organization.

2. Collapse cross-scanner duplicates with AutoTriage

AutoTriage (GA) works over the unified findings model. When more than one engine reports the same underlying issue, for example SAST and SCA pointing at the same component, AutoTriage collapses them into a single correlated finding. Low signal and redundant findings are down ranked or merged.

The detail that matters for an auditor: AutoTriage reports a reduction metric showing how much finding volume it removed, so the deduplication is measurable rather than opaque. That number belongs in your methodology note from step 10. AutoTriage is switched on by an administrator through a feature flag that the server enforces. Your result will depend on your code and your scanner mix, so measure it on your own estate rather than expecting a set figure.

3. Rank by exploitation and reachability

The Vulnerabilities tab groups findings into Critical, High, Medium, Low and Exploitable, the last meaning known active exploitation in the wild. Vulnerability management (GA) draws on the NVD, GitHub Security Advisories, OSV, CISA KEV and vendor bulletins, and each record shows CVSS, EPSS, exploited status, affected component, fixed version and reachability.

Reachability analysis (GA) asks whether the vulnerable code is actually called, alongside runtime and configuration context, and the docs list business context inputs such as asset criticality, data sensitivity and exposure. Those map closely to the scoring inputs in step 5. You can filter by severity, CVSS range, EPSS range, exploited status, fix availability and reachability, or use natural language search; the docs give the example "Show me critical vulnerabilities in production that are actively exploited". Safeguard performs daily continuous scanning, re-evaluating projects as new CVEs are published, which keeps first-seen dates honest.

4. Turn your timeline policy into policies and gates

Policies and gates (GA) are where your written standard becomes enforcement. Policies evaluate your SBOMs and generate findings; gates are checkpoints that enforce them. You create a policy under Settings, then Policies, with Create Policy, using the visual builder or YAML. Conditions in the docs include vulnerability severity, CVSS score, EPSS score, license, component age and maintenance status, and policy creation from plain English prompts is also available (GA).

Each policy has one Action, as the policy outcomes docs explain:

Notify does not repeat on every evaluation; it fires when a policy moves from passing to failing, and again when a failing policy finds new matching issues. A gate that has never been evaluated shows Not evaluated, never Passed, and an Error is never counted as a pass. That behaviour is useful in front of an auditor: a missing evaluation cannot be read as a clean result.

In a pipeline, the docs show this command to fail a CI job when a gate fails, once policy outcomes are turned on for your workspace (Safeguard turns them on per workspace):

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, or if the policies were not evaluated before the timeout. We have not run this command for this post; check the CI/CD integration docs for the secret key setup.

5. Put exceptions on the finding, with approval and expiry

Approval in Safeguard runs through exceptions, not through a gate action. From a policy violation you click Request Exception, select the policy and finding, give a business justification and an expiration date, and submit for approval. Approvers are notified, decide, and the docs say an audit trail is recorded. On the Vulnerabilities tab, Accept Risk asks for an expiration date and a business justification and is submitted for approval, and Mark False Positive asks for a justification and goes for approval where your policy requires it.

That covers step 8: every exception lives on the finding it covers, with who asked, who approved, why and until when. The Mitigations docs describe how mitigations and risk acceptances are tracked over time.

6. Work the queue: status, assignment and export

The Findings docs describe a status workflow of Open, In Progress and Resolved, with Mitigated and Suppressed as side states. Each finding card shows severity, status, affected component, the gate that caught it and when it was first seen. You can assign findings to a team member with a note (the assignee is notified), and bulk actions let you change status, assign, add to a sprint or ticket, export or mitigate several at once. The Jira integration can create issues automatically for findings (for example, new critical or high vulnerabilities) with bidirectional status synchronization, so engineers keep working where they already work while the record stays in one place.

7. Fix where a fix exists

Where a fixed version exists, AI Remediate on the Vulnerabilities page has Griffin analyse the vulnerabilities, generate remediation plans and open pull requests after you review the proposed changes. Autonomous remediation (GA) can open tested, policy gated fix pull requests on one repository or in bulk, but it ships switched off, with every category set to Manual. Your team decides what, if anything, runs on its own.

8. Bring supplier statements in as data

CSAF and VEX upload (GA) lets you load supplier vulnerability statements, so a vendor's "not affected" claim becomes data attached to your inventory rather than an email. This fits step 8's advice to ask suppliers for machine readable VEX.

9. Run it where your data rules require

Regulated institutions often cannot send source code to a third party model. Safeguard supports Zero AI mode (GA), where the platform runs deterministically with no LLM, bring your own model (GA), and on-prem and air-gapped deployment (GA). The local runner (GA) runs scan jobs on your own machine and, per the docs, uploads only the resulting SBOM and findings, never your source code.

10. Answer board and examiner questions from the same record

Safeguard's MCP server (GA) has read-only tools for gate outcomes, policy outcomes and evaluation history, available when policy outcomes are on and your MCP access settings allow them. That lets an analyst ask an assistant such as Claude for the overdue criticals and their exceptions and get an answer from the same record engineering works from. You control which tools the assistant can call.

How this maps to the steps

What Safeguard does not do

• It does not make your regulatory decisions. Safeguard does not decide your remediation timelines, approve exceptions, or tell you what your examiner or assessor will accept. Your risk committee, second line and legal counsel own those calls.
• It does not automatically absorb every scanner you own. The unified findings model and AutoTriage, as documented, operate over findings from Safeguard's engines. The docs pages read for this post do not show a general import flow for results from other vendors' scanners, so plan for tools you keep to be reconciled at the reporting layer, and ask Safeguard directly about ingesting a specific tool before you plan around it.
• It does not promise a reduction figure. AutoTriage reports the reduction it achieved on your data; it does not guarantee one in advance, and neither does reachability analysis.
• It does not replace your GRC system or your ticketing system. It can feed Jira and export data. The board pack, the methodology note and the conversation with your examiner remain yours.
• It does not fix vendor appliances or hosted services. When a vulnerability lives in software you do not build, the fix and often the VEX statement come from the vendor.
• It does not turn on autonomous fixes by itself. Autonomous remediation ships off, with every category on Manual.
• Some API paths are not live yet. The Findings docs carry a banner that the documented /v1 REST endpoints currently return 404. Use the app, the CLI or CI flows instead.

Common mistakes

• Buying a dashboard before deciding the key. A tool that displays five feeds side by side is still five feeds. Decide the finding key and the merge rules first.
• Deleting duplicates. Deleted rows cannot be shown to an auditor. Merge and keep the evidence.
• Keying without the asset. CVE plus package without the service merges two teams' findings into one and closes the wrong one.
• Restarting the clock on rescoring or on a new source. It makes overdue findings look current. Keep the earliest first-seen date.
• Letting each scanner's severity stand. Your policy, not the vendor default, is what PCI DSS 6.3.1 and NYDFS 500.5 ask you to evidence.
• Changing the count without a note. Tell internal audit and your examiner before the metric moves, and run both methods for one period.
• One big unowned queue. Consolidation without an asset to owner map moves the backlog from five places to one place where nobody works.
• Permanent false positive decisions. Code changes. Put an expiry on not applicable decisions for code you build.
• Switching off a scanner that an assessor relies on. Check the regulatory driver column first.

FAQ

How do I consolidate findings from multiple security scanners?

Choose one system of record, define a stable key per finding type (vulnerability ID plus package URL plus service for dependencies; CWE plus location for code; CWE plus route and parameter for dynamic tests), merge findings that share a key while keeping every source's evidence, rescore once against your written policy, and start the remediation clock at the earliest first-seen date.

Do bank regulators require a single vulnerability management tool?

No. The FFIEC Information Security booklet, the Interagency Guidelines, the FTC Safeguards Rule and NYDFS Part 500 ask you to identify, rank, remediate and report on vulnerabilities. They do not prescribe tools. One queue simply makes those things easier to prove.

How do I deduplicate the same CVE found by different scanners?

Normalize identifiers to CVE where one exists, express packages as package URLs, and include the asset or service in the key. Two findings with the same CVE, package and service are one finding; the same CVE in two services is two findings with two owners.

When does the remediation SLA clock start after deduplication?

Most institutions start it at the earliest first-seen date across all sources and do not restart it when another tool sees the same issue. Write that rule into your vulnerability management policy so it is applied the same way every time.

Will consolidating scanners reduce our reported vulnerability count?

Usually the count of records drops because duplicates merge, but the number of real vulnerabilities is unchanged. Explain the method change to internal audit and your examiner before the number moves, and report both counts for one period.

How does PCI DSS v4.0.1 treat vulnerability ranking?

Requirement 6.3.1 asks you to identify vulnerabilities from industry recognized sources and assign each a risk ranking. Requirement 6.3.3 sets a one month window for critical patches, and 11.3.1 covers internal scans at least every three months with rescans. Document your ranking method and apply it the same way every time.

Should EPSS or CISA KEV override CVSS in our policy?

Many institutions use CVSS as the starting point, then raise priority for anything on the KEV catalog and use EPSS to order the rest. FIRST describes EPSS as a probability of exploitation activity in the next 30 days, which complements CVSS rather than replacing it.

Is the FFIEC Cybersecurity Assessment Tool still used for vulnerability management?

No. The FFIEC retired the CAT on 31 August 2025. Update any vulnerability management narrative that still cites CAT maturity levels.

A single queue tells you what to fix first, but the queue only shrinks when fixes land. The section below explains how Safeguard closes the gap between a finding and a fix, including for open source dependencies where upstream has not shipped one yet.

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 connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. For a Head of AppSec preparing a board pack, the same connection is how an analyst can ask for overdue findings and gate outcomes in plain language, with tool access limited to what you allow.

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

The second demo sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. Teams at regulated institutions that will not grant repository access to an outside service use this pattern to keep code in house while still feeding results into one place.

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

The third demo is a real CLI session: the developer asks Safeguard to fix the lodash CVE in a repository, the CLI reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. It shows what the far end of a consolidated queue looks like: one finding, one owner, one reviewed fix.

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

Quick check

Sources

• eCFR: 12 CFR Part 30, Appendix B, Interagency Guidelines Establishing Information Security Standards
• eCFR: 16 CFR Part 314, Standards for Safeguarding Customer Information
• FFIEC IT Examination Handbook, Information Security booklet, II.C.10(d) Patch Management (archived copy)
• FDIC: Sunset of FFIEC Cybersecurity Assessment Tool
• 23 NYCRR 500.5, Vulnerability management (Cornell LII)
• NYDFS: Cybersecurity resource center
• PCI DSS v4.0 SAQ D for Merchants (requirement text for 6.3.1, 6.3.3 and 11.3.1)
• PCI SSC: Just Published, PCI DSS v4.0.1
• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• NIST SP 800-53 Rev. 5 catalog (OSCAL, RA-5 and SI-2)
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk
• CISA Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System
• Package URL specification
• OASIS SARIF v2.1.0
• OASIS CSAF v2.0
• Safeguard docs: Unified Findings and Feature Flags
• Safeguard docs: AutoTriage
• Safeguard docs: Findings
• Safeguard docs: Vulnerabilities
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Mitigations
• Safeguard docs: Jira integration
• Safeguard docs: CI/CD integration
• Safeguard docs: Air-gapped deployment
• Safeguard docs: Local Runner

Related reading: enterprise vulnerability management: one queue, not five, how to deduplicate findings when several scanners overlap, how to stop duplicate findings when you scan in several places, what vulnerability management auditors accept, what a written vulnerability management policy should cover and answering an NCUA exam finding on patching.

Try it yourself: download Safeguard or read the Safeguard docs.

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