Software Supply Chain Security for Capital Markets: A 90-Day Plan

A broker-dealer or asset manager secures its software supply chain by knowing what software touches customer information and trading, holding every service provider to written duties on security and breach notice, and keeping the open source inside its own code current and accounted for. Since the SEC amended Regulation S-P in 2024, that is no longer only good practice: firms need an incident response program, customer notice within 30 days, and service provider oversight that includes notice to the firm within 72 hours of a breach. Public firms also answer to the SEC's disclosure rules, and FINRA expects outsourced functions to be supervised like any other.

This guide is for the CISO, the chief compliance officer, the head of trading or platform technology, the AppSec lead, vendor risk and the engineers who keep the order flow running. The first two thirds work with the tools you already have. This is not legal advice; read the rules with your counsel.

Key takeaways

• Regulation S-P now has a breach clock and a vendor clock. The 2024 amendments require an incident response program, notice to affected individuals no later than 30 days after a firm becomes aware of an incident, and service provider oversight that includes notice to the firm within 72 hours. Larger entities had to comply by 3 December 2025 and smaller entities by 3 June 2026.
• Public firms have a four business day disclosure clock. Form 8-K Item 1.05 applies once a firm determines a cybersecurity incident is material, and Regulation S-K Item 106 asks how the firm manages cyber risk, including risk from third parties.
• FINRA supervises the vendor, through you. Regulatory Notice 21-29 reminds member firms that outsourcing an activity does not outsource the supervisory obligation under Rule 3110.
• Some expected rules are not coming. On 12 June 2025 the SEC withdrew its pending cybersecurity risk management proposals for broker-dealers and for advisers and funds, the adviser outsourcing proposal and the Regulation SCI expansion. Plan around the rules in force.
• The incidents are recent and close to the market. A November 2023 ransomware attack forced a US broker-dealer to cut its links to clearing firms and left its books and records out of date for months, and the SEC fined an exchange group 10 million dollars in May 2024 for late Regulation SCI notice of an intrusion that began in a VPN device.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis, software composition analysis, vulnerability management with EPSS and KEV, reachability analysis, policies and gates, autonomous remediation (ships switched off), TPRM with SBOM requests and vendor monitoring, CSAF and VEX upload, the compliance and GRC suite with GLBA and SOX ITGC frameworks, Trust Center, the Safeguard CLI and local runner, and on-prem, air-gapped and Zero AI deployment options.

The situation

The trigger is usually one of five things: the Regulation S-P compliance date has passed and examiners want the incident response program and service provider procedures in writing; a large vendor has had an incident; the Item 106 paragraph on third-party risk is due in the annual report; a FINRA request asks for vendor due diligence files; or an advisory lands for a package in your client portal and nobody can say which applications carry it.

A bad week looks like this. A vendor emails at 6 p.m. on a Friday to say it "may have experienced unauthorized access." Your contract has no notice clock. The procurement vendor list does not match the CMDB, and neither shows that the vendor's SDK is compiled into your mobile trading app. Compliance is counting toward a 30-day customer notice, legal is asking about materiality, and the desk wants to know whether to switch the feed off.

Every one of those is a supply chain question. Firms that answer quickly already have an inventory that joins vendors to systems and data, contract language that sets clocks, and a record of the open source inside the software they build.

What software capital markets firms run

Capital markets firms run more software, and more kinds of it, than most industries. The table below is the starting map. Each row is a place where a supplier or an open source component can carry risk into the firm.

Three patterns stand out. Much of the most sensitive data sits with service providers such as clearing firms, custodians, fund administrators, archivers and statement vendors, which is exactly where Regulation S-P's service provider requirements aim. The code firms build themselves pulls in large open source trees that only the firm will keep current. And remote access appliances run vendor code at the edge of your network, which is where the intrusion in the ICE order below began.

The regulations and frameworks that apply

US rules lead here. The SEC, FINRA and, for some firms, state regulators set the obligations; voluntary frameworks shape how firms meet them.

SEC Regulation S-P, as amended in 2024

Regulation S-P is the SEC's privacy and safeguards rule for broker-dealers (including funding portals), investment companies, registered investment advisers and transfer agents. The SEC adopted amendments on 16 May 2024 to address breaches and the use of service providers. The amended Rule 30 (17 CFR 248.30) now requires:

• Written safeguards. Policies and procedures covering administrative, technical and physical safeguards for customer information.
• An incident response program. Policies and procedures reasonably designed to detect, respond to and recover from unauthorized access to or use of customer information, including assessing the nature and scope of an incident and taking steps to contain and control it.
• Customer notice. Notice to affected individuals whose sensitive customer information was, or is reasonably likely to have been, accessed or used without authorization, as soon as practicable but no later than 30 days after the firm becomes aware of the incident. The notice must describe the incident, the data involved and what individuals can do.
• Service provider oversight. Policies and procedures requiring oversight, including due diligence and monitoring, of service providers, designed to ensure they take appropriate measures to protect against unauthorized access and notify the firm as soon as possible, but no later than 72 hours, after becoming aware of a breach that results in unauthorized access to a customer information system the service provider maintains.
• Records. Written documentation of compliance, kept under the recordkeeping rule that applies to the firm type.

The SEC's adopting announcement set compliance at 18 months after Federal Register publication for larger entities and 24 months for smaller ones, which put the dates at 3 December 2025 and 3 June 2026. Both have passed. FINRA's 2026 Annual Regulatory Oversight Report lists Regulations S-P and S-ID first among the rules implicated by cybersecurity and summarizes the 2024 amendments, a fair signal of where exam questions start.

For supply chain work, the service provider paragraph changes daily life. A firm may agree in writing that a service provider sends customer notices for it, but the obligation stays with the firm, so contracts, vendor inventory and incident runbook have to line up.

SEC cybersecurity disclosure rules for public companies

On 26 July 2023 the SEC adopted rules that require registrants to disclose material cybersecurity incidents on Form 8-K Item 1.05, generally within four business days after the firm determines an incident is material, and to describe cyber risk management, strategy and governance annually under Regulation S-K Item 106. The Form 10-K disclosures began with fiscal years ending on or after 15 December 2023, and Form 8-K disclosure began on 18 December 2023 for most registrants.

These rules apply to public companies, so they reach listed broker-dealer holding companies, listed asset managers and exchange groups, not every registered firm. Item 106(b) asks whether the registrant has processes to oversee and identify such risks from cybersecurity threats associated with its use of any third-party service provider. A supply chain program is how you answer that honestly.

The SEC has also shown it reads these disclosures closely. On 22 October 2024 it settled charges against four current and former public companies that had been affected by the compromise of SolarWinds' Orion software, finding that each had made materially misleading disclosures about the intrusions. Penalties ranged from 990,000 dollars to 4 million dollars. The orders found that two of the companies described cyber risks hypothetically when they knew the risks had already materialized.

Regulation SCI for exchanges, clearing agencies and large ATSs

Regulation Systems Compliance and Integrity applies to SCI entities, which include national securities exchanges and registered clearing agencies; the ICE order's respondents included both. It sets duties for the integrity and security of SCI systems and requires prompt notice to the SEC of SCI events, including systems intrusions. In the ICE order of 22 May 2024, the SEC described the obligation as immediate notice to SEC staff and an update within 24 hours, unless the entity reasonably estimated the intrusion would have no or a de minimis impact.

If your firm is not an SCI entity, it still matters, because your exchange and clearing counterparties are bound by it.

FINRA Rules 3110 and 4370, and Regulatory Notice 21-29

FINRA Rule 3110 requires each member firm to have a supervisory system reasonably designed to achieve compliance. Regulatory Notice 21-29, published on 13 August 2021, reminds firms that this obligation covers activities and functions performed by third-party vendors and their sub-vendors. The notice discusses risk-based due diligence before onboarding, ongoing supervision, cybersecurity, and what happens when a vendor relationship ends. Rule 4370 requires business continuity plans, which should account for the failure of a critical vendor.

FINRA's 2026 Annual Regulatory Oversight Report covers cybersecurity and cyber-enabled fraud under financial crimes prevention and has a separate third-party risk section under firm operations. The report is not a rule, but it tells you what examiners will ask about.

What the SEC withdrew in June 2025

On 12 June 2025 the SEC withdrew a group of pending proposals issued between March 2022 and November 2023 (published in the Federal Register on 17 June 2025) and said it did not intend to issue final rules on them. For this topic, the important ones are the 2023 proposed cybersecurity risk management rule for broker-dealers and other market entities, the 2022 proposed cybersecurity rule for advisers and funds, the 2022 proposal on outsourcing by investment advisers and the 2023 proposal to expand Regulation SCI. Any future action would need a new proposal. That leaves Regulation S-P, the disclosure rules, Regulation SCI as it stands and FINRA's rules as the operative US obligations. Firms that built programs around the withdrawn proposals should check that their documents cite the rules that actually apply.

New York DFS Part 500, where it applies

Entities operating under a license, registration or charter under New York's Banking, Insurance or Financial Services Law, such as a trust company or insurance affiliate in a capital markets group, are covered by 23 NYCRR Part 500, DFS's cybersecurity regulation. Many SEC-registered broker-dealers and advisers hold no such license, so check before you plan around it.

Frameworks that shape good practice

None of these is mandatory for a broker-dealer, but examiners and auditors recognize them.

• NIST Cybersecurity Framework 2.0 includes a supply chain risk management category (GV.SC) in its Govern function, which maps neatly to vendor tiering, contract requirements and monitoring.
• NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, describes secure development practices for the code firms write themselves.
• CISA's 2026 Minimum Elements for an SBOM, released on 29 July 2026 with NSA, FBI and international partners, replaces the 2021 NTIA minimum elements and adds fields such as component hash, license, SBOM tool name and generation context. It is the right reference when you ask a vendor for an SBOM.
• EU DORA applies to EU financial entities. US firms with EU affiliates meet it in group policy; it is context here.

How the rules fit together

Real public incidents from the last three years

These come from regulators and official reporting, and stay within what the sources say.

Ransomware cuts a broker-dealer off from its clearing firms (November 2023)

On 8 November 2023 ICBC Financial Services, a US broker-dealer wholly owned by the Industrial and Commercial Bank of China, found that malicious software had encrypted data and programs across its network. According to the SEC's order of 2 December 2024, the attack disrupted its access to its books and records and led it to terminate connectivity to its clearing firms and clearing agents, impeding trading. Between 8 November 2023 and 1 March 2024 the firm failed to keep its books and records current under Exchange Act Rule 17a-3(a) and did not send some trade confirmations on time under Rule 10b-10(a). The SEC censured the firm and imposed no civil penalty, citing its cooperation and remediation. A Treasury official described the attack the following week as having affected the firm's client clearing business. The order says the violations indicate the firm needed to be better prepared for a severe cyber incident.

Exchange group fined for late Regulation SCI notice of a VPN intrusion (order of May 2024)

On 22 May 2024 the SEC announced that Intercontinental Exchange agreed to pay a 10 million dollar penalty to settle charges that it caused nine subsidiaries, including the New York Stock Exchange, to fail to inform the SEC of a cyber intrusion in time. According to the SEC's order, a third party told ICE in April 2021 that it was potentially affected by a system intrusion involving a previously unknown vulnerability in its VPN. ICE found that a threat actor had inserted malicious code into a VPN device used for remote access to its corporate network. The order found that ICE personnel did not tell the subsidiaries' legal and compliance officials for several days, contrary to ICE's own procedures. The intrusion started in a vendor device at the network edge; the violation was in the internal reporting chain.

The XZ Utils backdoor (March 2024)

On 29 March 2024 CISA reported that malicious code had been embedded in versions 5.6.0 and 5.6.1 of XZ Utils, a compression library present in many Linux distributions (CVE-2024-3094), and advised downgrading to an uncompromised version. Trading and risk platforms run on Linux, so every firm faced a simple question that was often hard to answer: which hosts and images carry those versions?

Compromised GitHub Actions expose CI secrets (March 2025)

In March 2025 CISA reported that the widely used tj-actions/changed-files GitHub Action had been compromised (CVE-2025-30066), allowing disclosure of secrets such as access keys, GitHub personal access tokens, npm tokens and private RSA keys from workflow logs, and that the compromise was potentially enabled by an earlier compromise of reviewdog/action-setup (CVE-2025-30154). CISA added both to its Known Exploited Vulnerabilities catalog on 26 March 2025. Client portals and data pipelines are often built with exactly this kind of step.

The Shai-Hulud worm in npm (September 2025)

On 23 September 2025 CISA described a widespread compromise of the npm registry by a self-replicating worm that had compromised over 500 packages. After initial access, the actor scanned for credentials, targeted GitHub tokens and cloud API keys, and used compromised developer accounts to publish infected versions of other packages. CISA advised reviewing all npm-based software, checking lock files and artifact caches, and pinning dependencies to releases from before 16 September 2025, a review every firm with a JavaScript client portal had to run.

The personas who own the problem

Supply chain work in a broker-dealer or asset manager crosses at least six desks, each with its own need and moment.

CISO

The CISO needs one answer under pressure: are we affected, and how badly? It feeds the Regulation S-P assessment, the materiality question for a public firm and the board. What they need: an inventory that joins vendors, systems and data; a tested runbook with vendor notice built in; and metrics that hold up before the audit committee. When: every incident, every board pack and the annual report.

Chief compliance officer and GRC

The CCO owns the written policies the SEC and FINRA will read, including the Regulation S-P incident response program and the WSPs covering vendors. What they need: policies that cite the rules in force (not the withdrawn proposals), due diligence files that show what was asked and answered, and monitoring records. When: exam request letters, the annual compliance review and FINRA's exam cycle.

Head of trading or platform technology

This person owns OMS, EMS, connectivity and in-house platforms. What they need: changes that do not threaten the trading day, a way to know which applications carry a vulnerable library, and fixes that arrive as reviewed changes, not a ticket backlog. When: the moment an advisory lands, and every release window.

Head of AppSec or product security

AppSec owns scanning, triage and the developer relationship. What they need: findings ranked by real exposure, CI gates that block the worst problems without stopping every build, and evidence for compliance. When: every pull request, and every client questionnaire about third-party code.

Vendor risk and procurement

This desk owns the vendor list, tiering, due diligence and contract terms. Under Regulation S-P they now hold a concrete requirement: providers that maintain customer information systems must notify the firm within 72 hours of a breach. What they need: a list of which vendors touch customer information, a contract addendum with the notice clock, SBOM and advisory requests for critical software, and a renewal calendar. When: onboarding, renewal and every vendor incident.

SRE and infrastructure

SRE owns hosts, images, CI/CD and remote access. What they need: an inventory searchable by package version, CI that does not leak secrets, and a rollback plan when an upgrade misbehaves. When: every patch window and every build chain incident, as tj-actions and Shai-Hulud showed.

Step by step: a 30/60/90-day plan that works with or without Safeguard

The plan assumes a mid-sized broker-dealer or adviser with in-house development; smaller firms can compress it and larger ones run it per business line. Spreadsheets, open source tools and existing ticketing are enough.

Days 1 to 30: inventory and the plan you actually have

1. Pull the Regulation S-P documents. Collect the written safeguards policy, the incident response program and the service provider procedures. Check that each cites amended Rule 30 and that the compliance date for your firm size is noted.
2. Build the vendor and data map. Start from accounts payable, not the vendor risk tool. List every provider that receives, stores or can access customer information or runs software in the trading path, and mark the Regulation S-P service providers.
3. Tier the vendors. Use four tiers: critical (customer information plus trading or settlement), high (customer information or trading), medium and low. Tie the tier to the depth of due diligence.
4. Read critical and high vendor contracts. Record any breach notice clock, its recipient and whether it covers sub-vendors.
5. Inventory the code you build. For each in-house application (strategy code, portals, data pipelines, internal tools), generate an SBOM in CycloneDX or SPDX from the repository or the built image.
6. Run a first vulnerability pass. Match those SBOMs against public advisories. Mark anything on CISA's KEV catalog and anything with a high EPSS score.
7. Check CI. List third-party build steps (such as GitHub Actions) and how they are pinned. Record which secrets each workflow can see.

Days 31 to 60: contracts, intake and the incident drill

1. Send the addendum. For critical and high vendors without a 72-hour clock, send a contract addendum or written assurance (template below). Track responses.
2. Ask for SBOMs and advisories. For software you install or embed (OMS components, SDKs, desktop tools), request an SBOM aligned with CISA's 2026 minimum elements, plus the vendor's advisory channel in CSAF or a VEX format if available.
3. Set CI gates. Fail builds on known exploited vulnerabilities and on critical findings in reachable code; warn on the rest. Define an exception process with an owner and an expiry.
4. Pin build dependencies. Pin third-party CI actions to a full commit hash, and lock package versions with lock files.
5. Run a tabletop on a vendor breach. A Tier 1 vendor reports unauthorized access to a system holding your customer data at hour 60 of its 72. Walk through who receives the notice, how affected customers are identified, how the 30-day clock is tracked, and how legal decides materiality.
6. Run a tabletop on a poisoned package. A popular npm package in your client portal is reported compromised. Can you find every application that carries it within an hour?

Days 61 to 90: evidence, monitoring and the next review

1. Close the top findings. Upgrade or replace components with exploited or reachable critical vulnerabilities in customer-facing and trading systems first.
2. Set monitoring. Re-scan SBOMs on new advisories rather than on a fixed calendar; review Tier 1 vendors at least quarterly.
3. Write the evidence pack. For each rule in the table above, file the policy, the inventory, the due diligence files, the drills and the remediation records in one place.
4. Update the WSPs. Make sure FINRA supervisory procedures name the vendor review steps you actually perform.
5. Draft the Item 106 language (public firms). Describe the third-party process you have, in plain terms, and avoid hypothetical framing for risks that have already occurred.
6. Report to the board. Show coverage (critical vendors with a notice clock, in-house apps with SBOMs), exposure (open exploited vulnerabilities) and time to answer "are we affected."

Template: service provider addendum for Regulation S-P

Use this as a starting point for counsel. It is not legal advice.

Checklist: the first hour after a vendor breach notice

• Record the time the notice arrived and who received it.
• Identify which of your systems and data the vendor holds, from the vendor and data map.
• Ask the vendor for the time window, systems affected and data types, in writing.
• Open a Regulation S-P incident record and start the 30-day clock tracking.
• Tell legal and, for public firms, the disclosure committee, so materiality can be assessed.
• Check whether the vendor's software runs inside your environment, and if so which versions.
• Decide whether to suspend the integration, rotate shared credentials or cut access.
• Record every decision with the time and owner.

Decision table: the vendor will not provide an SBOM

How does Regulation S-P apply to open source packages?

Regulation S-P speaks of service providers, not open source maintainers, and a library has no contract or 72-hour clock. But open source inside your client portal still processes customer information, so it sits under your safeguards and incident response duties. Treat it as your own code: keep an SBOM, track advisories and own the fix.

What if the vendor is also a critical market utility?

Clearing agencies and exchanges are SCI entities with their own duties. You cannot audit them like a software vendor, but you can map your dependency on them in your Rule 4370 BCP, know their incident channels and rehearse an outage. The ICBC Financial Services order shows the reverse case too: a broker-dealer that had to cut its own clearing links.

How Safeguard does this

Safeguard puts the inventory, vendor requests, gates, fixes and evidence in one place. Commands and YAML below are copied from docs.safeguard.sh as of 25 October 2026 and were not run for this post.

1. Inventory the code you build. In the web app, open Integrations and connect repositories, container registries or a manifest. SBOM generation and analysis (GA) and software composition analysis (GA) produce an SBOM per project across the full transitive dependency tree, in CycloneDX or SPDX.

2. Scan where code cannot leave the building. Trading code often cannot be connected to a cloud service. The Safeguard CLI (GA) includes a local runner (GA). The docs say the runner polls the platform over outbound HTTPS, nothing connects to it, it runs scans locally and uploads only the resulting SBOM and findings, never source code. Install and sign in as the docs show:

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash
safeguard

Then type /login and approve the session in your browser. For a one-off scan of a directory or an existing SBOM:

safeguard scan --dir .
safeguard scan --sbom sbom.json

3. Validate vendor SBOMs and advisories. The CLI checks CycloneDX and SPDX SBOMs and CSAF and OpenVEX documents against their specifications:

safeguard validate sbom.json --strict -o report.json

4. Run vendor intake in TPRM. In TPRM (GA), add vendors with a risk tier and SBOM status, or import them in bulk. From a vendor, choose Request SBOM, select products and a template, set a deadline and send. The docs describe status tracking from Sent through Viewed, In Progress and Submitted to Validated or Rejected, reminders before and after the deadline, and validation on receipt (format, completeness and compliance checks), with a revision request when a submission falls short. Risk assessment scores vendors from their SBOM analysis, and continuous monitoring flags new vulnerability disclosures across vendors.

5. Load vendor advisories. With CSAF and VEX upload (GA), go to Integrations, filter by Upload and choose Upload CSAF/VEX. A vendor's "not affected" statement then sits next to the findings for that product version.

6. Map to the rules you report against. The compliance and GRC suite (GA) has no SEC Regulation S-P or FINRA framework in its docs today. The closest fits are the GLBA framework, whose controls include service provider oversight and incident response planning and whose scan requirements check product SBOMs, and the SOX ITGC framework, which checks for an inventory of financially relevant software and change management evidence and includes a third-party IT service provider policy template. Use them as a starting structure and map each control to Rule 30 and Rule 3110 yourself.

7. Gate what you ship. With policies and gates (GA), create a policy under Settings, Policies with conditions such as vulnerability severity, CVSS, EPSS or license. The docs define three actions: Block (the gate fails), Warn (the gate passes with a warning naming the policy) and Notify (the gate passes and a notification is sent). A legitimate exception goes through the exception workflow with a business justification and approver notification. In GitHub Actions, the docs show:

name: Safeguard
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Safeguard scan
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
          SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
        run: |
          set -eu
          curl -fsSL https://cli.safeguard.sh/install | bash
          "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

The docs add that adding --fail-on-gate all fails the job on a policy gate instead of a severity threshold.

8. Rank by real exposure. Vulnerability management (GA) adds EPSS and CISA KEV. Reachability analysis (GA) labels findings reachable, conditionally reachable, unreachable or unknown, and treats unknown as potentially reachable.

9. Fix with pull requests. Autonomous remediation (GA) uses Griffin to open tested, policy gated pull requests that move a vulnerable dependency to a fixed version, one repository at a time or in bulk. It ships switched off, with every category set to Manual, so nothing changes until your team turns it on, which suits a change-controlled trading environment.

10. Share security documents. Trust Center (GA) publishes a page for clients and counterparties, with documents released through access requests you approve.

11. Choose where it runs. On-prem and air-gapped deployment (GA) run the platform in your environment, and Zero AI mode (GA) runs with no LLM in the loop, for firms with a policy against sending code or data to AI services.

Safeguard becomes one of your vendors once you adopt it, so assess it under the same procedures. Safeguard is designed for FedRAMP High, and its SOC 2 Type II audit is in progress.

What Safeguard does not do

• It does not make you compliant with Regulation S-P, the SEC disclosure rules or FINRA rules. It produces inventories, findings, gates and evidence. Your examiners judge compliance.
• It has no SEC or FINRA framework in its docs today. The GLBA and SOX ITGC frameworks are the closest; the mapping to Rule 30 and Rule 3110 is your work.
• It does not decide materiality or send customer notices. Whether an incident is material, and whether and when to notify individuals, are decisions for the firm and its counsel.
• It does not write or negotiate contracts. TPRM tracks vendors, tiers and SBOM requests; the 72-hour clause is between your counsel, procurement and the vendor.
• It does not fix vendor code. Autonomous remediation opens pull requests in repositories you own. A vulnerability inside a vendor's hosted platform needs the vendor's fix.
• It does not replace your incident response tooling. Detecting an intrusion like the one in the ICE order sits with your security operations stack.
• It does not scan vendor SaaS from the inside. For hosted services, you work from what the vendor discloses: SBOMs, advisories, VEX and audit reports.

Common mistakes

• Citing the withdrawn proposals. Policies written in 2023 sometimes reference proposed Rule 10 or the adviser outsourcing proposal. Both were withdrawn in June 2025.
• A vendor list from one system. Procurement, the CMDB and engineering each see a different slice. Build the map from payments and data flows.
• No clock in the contract. A breach notice "promptly" is not 72 hours. Write the number.
• Forgetting embedded SDKs. A vendor SDK in a mobile app is part of your code, and it belongs in your SBOM.
• Unpinned CI steps. A third-party build step referenced by a moving tag can change under you, as the March 2025 tj-actions compromise showed.
• Hypothetical risk language after an incident. The October 2024 SEC orders turned on exactly this.

FAQ

Does Regulation S-P require a 72-hour vendor notice?

The amended Rule 30 requires policies and procedures for service provider oversight designed to ensure that providers notify the firm as soon as possible, and no later than 72 hours, after becoming aware of a breach resulting in unauthorized access to a customer information system they maintain. How you get that assurance, by contract or otherwise, is up to the firm.

When did the Regulation S-P amendments take effect?

The SEC adopted them on 16 May 2024. Larger entities had to comply by 3 December 2025 and smaller entities by 3 June 2026.

Who must notify customers under Regulation S-P, the firm or the vendor?

The firm. It can arrange for a service provider to send notices on its behalf, but the obligation stays with the firm. Notice is due as soon as practicable and no later than 30 days after the firm becomes aware of the incident.

Does Form 8-K Item 1.05 apply to my broker-dealer?

Only if the firm, or its parent, is an SEC registrant filing periodic reports, such as a listed holding company. Registration as a broker-dealer alone does not trigger it. Regulation S-P applies regardless.

Did the SEC adopt a cybersecurity rule for broker-dealers?

No. The 2023 proposal for broker-dealers and other market entities was withdrawn on 12 June 2025, together with the 2022 adviser and fund cybersecurity proposal and the adviser outsourcing proposal.

Does FINRA require vendor due diligence?

FINRA Rule 3110 requires a supervisory system, and Regulatory Notice 21-29 reminds firms that it covers functions outsourced to vendors and sub-vendors, including risk-based due diligence and ongoing supervision.

Do broker-dealers need SBOMs?

No US securities rule requires an SBOM today. SBOMs are a practical way to meet the safeguards, incident response and vendor oversight duties, and CISA's 2026 minimum elements set out what a good one contains.

Are open source maintainers service providers under Regulation S-P?

Generally they are not, because they do not receive or maintain your customer information. The open source in your applications is covered by your own safeguards and incident response duties instead.

Everything above helps you see what you run and who you depend on. The block below covers the next step for the code and containers you build: getting known vulnerable components out quickly, even when an upstream fix is slow.

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 the local runner: you set it up on your own machine, approve it with its device code, then scan from the terminal. For a trading firm, this is the route for strategy and platform repositories that cannot be connected to a cloud service, because only the SBOM and findings leave the machine.

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

The second demo is a real CLI session: asked to fix the lodash CVE in a repository, it 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, and pushes nothing. The same flow applies to a client portal that needs a dependency upgrade inside a change window.

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

Quick check

Related reading

• The SEC cyber incident disclosure rule in year two
• Financial services supply chain controls for 2026
• Third-party risk management for fintech SaaS vendors
• GLBA and financial software security
• Related in this series: 90-day plan for electric utilities and 90-day plan for logistics and freight.

Sources

• SEC press release 2024-58, Regulation S-P amendments
• Regulation S-P adopting release, 89 FR 47688 (govinfo)
• Cybersecurity disclosure adopting release, 88 FR 51896 (govinfo)
• SEC Withdrawal of Proposed Regulatory Actions, 90 FR 25531 (govinfo)
• SEC order, ICBC Financial Services, Release No. 34-101794
• US Treasury remarks on catastrophic cyber risk, November 2023
• SEC press release 2023-139, cybersecurity disclosure rules
• SEC press release 2024-63, ICE and Regulation SCI
• SEC press release 2024-174, disclosure orders
• FINRA Regulatory Notice 21-29
• FINRA 2026 Annual Regulatory Oversight Report
• FINRA 2026 report, cybersecurity
• NYDFS cybersecurity resource center
• CISA alert on XZ Utils
• CISA alert on tj-actions and reviewdog
• CISA alert on the npm compromise
• CISA 2026 SBOM Minimum Elements bulletin
• NIST Cybersecurity Framework 2.0, CSWP 29
• NIST SP 800-218, SSDF version 1.1
• Safeguard docs, Policies and Gates
• Safeguard docs, TPRM SBOM Requests
• Safeguard docs, GLBA framework
• Safeguard docs, SOX ITGC framework
• Safeguard docs, Generate SBOM
• Safeguard docs, Local Runner
• Safeguard docs, CLI usage
• Safeguard docs, GitHub Actions
• Safeguard docs, TPRM Vendor Management
• Safeguard docs, TPRM Risk Assessment
• Safeguard docs, TPRM Monitoring
• Safeguard docs, CSAF/VEX Upload
• Safeguard docs, Reachability Analysis
• Safeguard docs, AI Remediate
• Safeguard docs, Trust Center
• Safeguard docs, Air-Gapped Deployment

Start with the free tier at safeguard.sh/download and read the Safeguard docs.

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