Scan your own dependencies and code first, sort findings by whether they are reachable and exploitable, fix or document the rest, and keep the evidence. A bank partner will ask about vulnerability handling, so arriving with a current inventory and a clear triage record shortens the review.
This is general information, not legal advice.
Why do this first
The 2023 interagency guidance has banks reviewing your information security program, your systems and your response to new vulnerabilities. If your first scan happens during their review, you answer under pressure and the findings look like surprises.
Steps
- Build the inventory. List direct and transitive dependencies for each shipped service, with versions.
- Scan for known vulnerabilities and record the date and tool output.
- Triage by exposure. Ask if the vulnerable function is reachable, if the service is internet facing, and if a fix exists.
- Fix the urgent items and open tickets for the rest with owners and target dates.
- Add a pull request gate so new critical issues on reachable code stop before merge.
- Save the evidence in one place with dates.
Decision table for triage
| Finding | Reachable | Fix available | Action |
|---|---|---|---|
| Critical | Yes | Yes | Fix now |
| Critical | Yes | No | Mitigate and track |
| High | No | Yes | Schedule with normal updates |
| Low | No | No | Accept with a note and review date |
This table is a starting policy, not a regulatory standard. Set your own thresholds and write them down.
What to show the bank
A one page summary works well: inventory date, scan date, counts by status, how you triage, and your gate policy. Offer detail on request. Do not claim zero vulnerabilities, because it is rarely true and invites doubt. Avoid calling any report a certification.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through and watch how many findings drop out once unreachable code is excluded, then compare what is left to your triage table.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning, reachability analysis, and policies and gates for pull requests. Try the free scan at gold.safeguard.sh/scan.
Quick check
Should we hide findings we have not fixed?
No. Show them with owners and dates. A transparent backlog reads better than a suspiciously empty one.
How current should the scan be?
Recent enough that you can say it reflects the release under review. Rescan before the call.
Sources
Last reviewed: 19 October 2026.
