A retail bank can start a software supply chain security program by treating software components as third-party relationships: inventory them, tier them by criticality, assess and monitor them across a life cycle, and add engineering controls for the code the bank builds. US interagency guidance on third-party risk gives the structure supervisors already know.
What do supervisors already expect?
In June 2023 the OCC, the Federal Reserve and the FDIC issued interagency guidance on third-party relationships and risk management, published by the OCC as Bulletin 2023-17. The bulletin says the guidance outlines the third-party risk management life cycle and identifies principles for each stage, clarifies that not all relationships carry the same risk or criticality, and says practices should fit the bank's risk profile, complexity and the criticality of the activity the third party supports. It applies to all banks with third-party relationships and rescinded earlier OCC bulletins on the topic.
That framing helps. You do not need a new governance model for supply chain risk. You need to extend the one you have so that it covers open source libraries, build tools, SDKs and the vendors behind them.
How do software components fit a third-party model?
A constructed example: a bank's mobile app uses a payment SDK from a vendor, thirty open source libraries and a build service. The vendor has a contract and a review. The libraries have neither. A flaw in one of them is, in practice, a supplier incident with no named supplier and no contact.
To close that gap, treat each category differently by criticality. A core banking vendor gets full due diligence. An open source library in a customer-facing flow gets automated checks and a named internal owner. A library in an internal script gets lighter handling.
What are the starting steps?
NIST's SSDF provides practices for the software the bank develops, drawn from sources such as BSA, OWASP and SAFECode, and NIST notes few development life cycle models address security in detail. Use it as the engineering checklist next to the third-party life cycle.
Planning and inventory come first: list applications, their components and the vendors involved, and mark which support critical activities. Due diligence follows: for vendors, collect security documents, incident notification terms and software composition information. Contracting and monitoring follow: include breach notice and right to audit terms where appropriate, and watch for new advisories on components in use. Termination planning matters too: know how you would replace a component or vendor.
On the engineering side, require a software bill of materials for apps you build and request one from critical vendors. Scan dependencies on every build. Pin versions and build releases in controlled pipelines with restricted publish rights. Keep a record linking each release to its SBOM, so you can answer within hours which apps contain a newly disclosed vulnerable component.
Where can Safeguard help?
Safeguard provides SBOM generation and dependency scanning, reachability analysis, policy gates, and compliance automation that can help organize evidence for frameworks you are working toward. It does not certify anything on your behalf, and your examiners decide what satisfies them.
What to do
- Assign an executive owner and bring supply chain risk into the existing third-party risk committee.
- Inventory applications, components and vendors. Rate each by criticality.
- Request SBOMs and incident contacts from critical vendors. Generate your own SBOMs for apps you build.
- Add dependency scanning, secrets scanning and pinned builds to pipelines.
- Define how a newly disclosed vulnerability is triaged against the inventory, with a target time to answer and owners.
- Add supply chain scenarios to incident exercises.
- Report metrics to the board: coverage of SBOMs, time to identify affected apps and open critical findings.
Quick check
Does the interagency guidance mention SBOMs?
The OCC bulletin summary does not. It sets out the life cycle and principles. SBOMs are a practical way to apply those principles to software components.
Should every library get a full vendor review?
No. The guidance says relationships differ in risk and criticality, so match depth of review to what the component supports.
Sources
- OCC Bulletin 2023-17: Third-Party Relationships, Interagency Guidance on Risk Management
- NIST: Secure Software Development Framework
Last reviewed: 18 October 2026.
