Software Supply Chain Security for Law Firms: A 90-Day Plan

A law firm or professional services firm secures its software supply chain by knowing which document systems, cloud services, legal technology tools, AI assistants and open source components touch client information, by putting security asks into vendor contracts before signing, and by tracking known exploited flaws across all of it. No single statute tells a firm to do this. The duty arrives through several doors: the professional conduct rules on competence, confidentiality and supervision of outside services, the FTC Safeguards Rule for firms that prepare tax returns or otherwise fall under it, HIPAA when a firm handles health information for a client, and, most often, the security terms that clients now write into outside counsel guidelines and engagement letters.

This guide is for the firm CISO or IT director, the general counsel or risk management partner, the innovation and knowledge management lead, the procurement or vendor risk owner, the litigation support and eDiscovery manager, and the security questionnaire team. The first two thirds work with any tools, or none. It is general guidance, not legal, ethics or audit advice; your own ethics counsel, auditors and clients decide what a rule or contract means for you.

Key takeaways

• Client confidentiality is the anchor. ABA Model Rule 1.6(c) asks lawyers to make reasonable efforts to prevent unauthorized access to client information, and Rule 5.3 extends supervision duties to outside services such as cloud document storage.
• The FTC Safeguards Rule applies to non-bank financial institutions, which the rule's own examples say includes businesses that complete income tax returns. Its 2023 amendment added a 30-day FTC notice for breaches touching 500 or more consumers, effective 13 May 2024.
• ABA Formal Opinion 512 (July 2024) puts generative AI tools squarely inside competence and confidentiality duties, which makes the AI tools a firm buys part of its software supply chain.
• Recent incidents reached firms through remote access appliances, shared open source and social engineering that ends with remote access software on a firm laptop.
• Most firms buy far more than they build, so the first job is a vendor register with owners, data types and contract terms.
• Safeguard's Third-Party Risk Manager (GA) requests, validates and monitors vendor SBOMs; SBOM generation and software composition analysis (GA) cover the integrations and tools a firm builds; policies and gates (GA) enforce Block, Warn or Notify, with approval handled through exceptions.
• Trust Center (GA) and the compliance suite (GA) help a firm answer client security questionnaires from one set of evidence; AI-BOM discovery (GA) inventories AI tools in code and cloud.
• The local runner (GA), Zero AI mode (GA) and on-prem or air-gapped deployment (GA) suit firms whose engagement terms forbid sending client-adjacent code to outside services.

The situation

The trigger in a law firm is rarely a regulator. It is a client. A bank, insurer, health system or technology company sends its annual outside counsel security assessment, or a new matter comes with guidelines that ask for a vendor inventory, patch timelines, breach notice within a set number of hours and the right to audit. Sometimes it is the cyber insurance renewal form, or a vendor's notice that client data may have been accessed.

Who asks, and by when:

• A client's vendor risk team wants a completed questionnaire, often within 30 days, and may want evidence rather than yes or no answers.
• The cyber insurer wants the renewal application before the policy lapses, with answers the firm can stand behind if a claim is later disputed.
• The firm's general counsel or risk partner wants to know whether a vendor's breach triggers duties to notify clients under the firm's ethics obligations and state breach laws.
• The management committee wants to know whether a new AI drafting tool is safe to roll out to every lawyer, and what goes into it.

A bad week looks like this. A vendor notice lands on a Monday. By Tuesday three clients have asked whether their files were involved. Nobody can say which matters used the affected product or which version the firm ran. The security team is two people, and the managing partner wants a client letter by Friday.

What software law firms and professional services firms run

A firm's supply chain is mostly bought. A mid-sized firm may build little beyond integrations and scripts; a large firm or consulting practice may run its own development team.

Document and email systems. The document management system holds every draft, executed agreement and privileged memo, and connects to email and Office add-ins. A flaw or a compromised update here reaches everything.

Practice management, time and billing. Intake, conflict checking, time entry and billing systems hold client and adverse party names and billing narratives that can reveal strategy.

eDiscovery and litigation support. Review platforms and processing tools handle the largest volumes of client data a firm touches, often including other parties' data under protective orders.

Deal and transaction tools. Data rooms, e-signature services and contract lifecycle tools carry non-public transaction data.

Client portals and extranets. File sharing sites and managed file transfer products move documents in and out of the firm, and file transfer products have a history of mass exploitation.

Remote access and identity. VPN gateways, remote desktop services and single sign-on are how lawyers work from home and court, and the appliances sit on the internet edge.

Legal research and AI tools. Generative AI drafting, transcription and contract review tools receive client documents as prompts or uploads, bringing model providers, plug-ins and retention terms into the chain.

Tax, audit and advisory software. Accounting and consulting firms run tax preparation software and audit workpaper platforms, and hand clients deliverables that are themselves code.

In-house code. Integration scripts, Office add-ins, website intake forms and innovation team prototypes. This is the part the firm can fix itself, and it usually depends on open source packages nobody tracks.

The regulations and frameworks that apply

The rules below were read on the primary source for this guide. Where a rule is a model rule, each state adopts its own version, and the state text governs.

ABA Model Rules: competence, confidentiality and outside services

Three Model Rules of Professional Conduct shape how a lawyer must treat technology vendors.

Rule 1.1, competence, Comment 8. The comment asks lawyers to keep abreast of changes in the law and its practice, including the benefits and risks of relevant technology. Formal Opinion 483 notes that Rules 1.1, 1.6, 5.1 and 5.3 were amended in 2012 to address the risks that come with technology. This comment is the reason a managing partner cannot treat software risk as purely an IT question.

Rule 1.6(c), confidentiality. A lawyer must make reasonable efforts to prevent the inadvertent or unauthorized disclosure of, or unauthorized access to, information relating to the representation of a client. The comments list factors for judging what is reasonable, including the sensitivity of the information, the likelihood of disclosure without added safeguards, the cost and difficulty of those safeguards, and whether they make the lawyer's work harder. The rule does not demand a specific control. It demands a judgment the firm can explain.

Rule 5.3, nonlawyer assistance. Lawyers with managerial authority must make reasonable efforts to ensure the firm has measures giving reasonable assurance that nonlawyers' conduct is compatible with the lawyer's obligations. The comments extend this to services outside the firm and give examples such as using an internet-based service to store client information. In plain terms, the document management vendor, the eDiscovery host and the AI tool are all within the scope of supervision.

ABA formal opinions on technology

Formal Opinion 477R (11 May 2017, revised 22 May 2017) addressed securing the communication of client information. It lists considerations that read like a vendor risk program: understand the nature of the threat, understand how client information is transmitted and stored, use reasonable electronic security measures, label confidential information, train lawyers and staff, and conduct due diligence on vendors providing communication technology. It also says a lawyer may need special precautions when a client agreement or the law requires them, or when the information calls for a higher degree of security.

Formal Opinion 483 (17 October 2018) addressed a lawyer's obligations after an electronic data breach or cyberattack. It says lawyers must make reasonable efforts to monitor technology connected to the internet, external data sources and external vendors providing services relating to data. After a breach, it describes duties to stop the intrusion, make reasonable efforts to determine what occurred, and notify current clients when a breach involves, or has a substantial likelihood of involving, material client information. A firm cannot meet the "determine what occurred" duty for a vendor incident without knowing which vendor products it runs.

Formal Opinion 512 (July 2024) addressed generative AI tools. It applies competence, confidentiality, communication, supervision and fee rules to their use. On confidentiality, it says a client's informed consent is required before information relating to the representation goes into a self-learning tool, that boilerplate language in an engagement letter is not enough, and that lawyers should read the tool's terms of use, privacy policy and related contract terms, or consult someone who has. That makes the AI tool's data handling, its model provider and its plug-ins a supply chain question.

State rules and continuing education

States adopt and adapt the Model Rules, and their versions govern. State bar ethics committees also publish their own opinions on cloud services and generative AI; Formal Opinion 512 itself cites several state opinions and expects state committees to keep adding guidance. Check your own state's version of Rules 1.1, 1.6 and 5.3, its ethics opinions, and any technology requirement in its continuing legal education rules.

The FTC Safeguards Rule, for tax and financial work

The Gramm-Leach-Bliley Act Safeguards Rule, 16 CFR Part 314, covers financial institutions under the FTC's jurisdiction. The rule's definition section gives examples, and one is an accountant or other tax preparation service in the business of completing income tax returns. Accounting firms, tax practices and law firms with tax preparation services may fall within it; counsel decides.

The parts that touch the software supply chain:

• Section 314.4(c)(4) asks for secure development practices for in-house developed applications that handle customer information, and procedures for evaluating, assessing or testing the security of externally developed applications the institution uses.
• Section 314.4(d)(2) asks for continuous monitoring or, failing that, annual penetration testing and vulnerability assessments at least every six months.
• Section 314.4(f) asks the institution to oversee service providers: select and retain providers capable of maintaining appropriate safeguards, require them by contract to do so, and periodically assess them based on risk.
• Section 314.4(j), added by the amendment published in the Federal Register on 13 November 2023 (88 FR 77499) and effective 13 May 2024, asks the institution to notify the FTC as soon as possible and no later than 30 days after discovering a notification event involving the information of at least 500 consumers.

The IRS backs this up for tax professionals. IRS Publication 4557, Safeguarding Taxpayer Data, explains that the Safeguards Rule requires tax return preparers to create and maintain a written information security plan.

HIPAA, when a firm acts as a business associate

When a law, consulting or accounting firm performs services for a health plan, provider or clearinghouse that involve protected health information, it is generally a business associate. The HIPAA definition at 45 CFR 160.103 lists legal, actuarial, accounting, consulting and management services among the business associate functions. The same definition reaches further down the chain: a subcontractor that creates, receives, maintains or transmits protected health information on behalf of a business associate is itself a business associate. Your eDiscovery host processing medical records for a malpractice defense is in that chain, and so are the hosted tools it relies on.

Client contracts and outside counsel guidelines

For many firms, the most specific security rules are contractual. Outside counsel guidelines and engagement terms can address the security program, breach notice windows, subcontracting, offshore access and audit rights. They vary by client, and this guide quotes none. Read them as the binding spec they are, and keep a register of which clients impose which terms.

Frameworks firms use to organise the work

NIST Cybersecurity Framework 2.0 (February 2024) added a Govern function with a supply chain risk management category, GV.SC, which covers having a supply chain program, knowing your suppliers by criticality, writing requirements into contracts, monitoring suppliers through the relationship and planning for incidents involving them. It maps well onto what clients ask.

CISA's 2026 SBOM Minimum Elements (29 July 2026) replaced the NTIA 2021 minimum elements as the reference for what a software bill of materials should contain. A firm asking a vendor for an SBOM can point to it.

How the rules stack up for one system

Take one system, a hosted eDiscovery platform used on a health care defense matter for a bank-owned insurer.

Real public incidents from the last three years

The incidents below come from official advisories or primary statements. They show how software supply chain failures reach professional firms. They do not say what any victim should have done, and this guide does not either.

CitrixBleed, November 2023. CISA, the FBI and partners published advisory AA23-325A on 21 November 2023, describing LockBit 3.0 ransomware affiliates exploiting CVE-2023-4966, a flaw in Citrix NetScaler ADC and NetScaler Gateway appliances that let attackers take over valid user sessions without passwords or multi-factor prompts. The advisory says exploitation was seen as early as August 2023. Appliances of this kind are a common way for lawyers and staff to reach firm systems remotely. The advisory asked defenders to isolate NetScaler appliances until patches could be deployed, apply the updates, and hunt for malicious activity using its detection methods.

The xz Utils backdoor, March 2024. On 29 March 2024 CISA reported a supply chain compromise of the xz Utils data compression library, CVE-2024-3094, in which malicious code was embedded in versions 5.6.0 and 5.6.1, and advised downgrading to an uncompromised version and hunting for malicious activity. The library may be present in Linux distributions. The practical question it raised was where the library sat in each organisation's systems.

Callback phishing aimed at law firms, 2025. On 23 May 2025 the FBI issued Private Industry Notification 20250523-001, coordinated with CISA, warning that the Silent Ransom Group had consistently targeted U.S. law firms since spring 2023, likely because of the sensitivity of legal data. The group's older method was a fake subscription email that led the victim to call in and download remote access software; by April 2025 it was calling staff while posing as IT support. It steals data and extorts the firm rather than encrypting systems. No software flaw was needed. The supply chain element is legitimate remote management software turned against the firm.

The npm worm, September 2025. On 23 September 2025 CISA reported a widespread supply chain compromise in the npm JavaScript registry, a self-replicating worm known as Shai-Hulud that compromised over 500 packages. CISA describes malware that harvested developer tokens and cloud keys, then authenticated to npm as the compromised developer to inject code into other packages. Any firm with an innovation team, a client portal or an Office add-in built on JavaScript draws on that registry.

The same group, in person, 2026. On 26 May 2026 the FBI followed up with FLASH-20260526-01. It says the group now poses as the victim's own IT department by phone and phishing email, asks employees to grant a remote desktop session, and, when that fails, sends a person to the office to plug a storage device into a computer. It names legitimate file copy and sync tools as the usual way data leaves, often to cloud file sharing services. The FBI notes that antivirus products are unlikely to flag these intrusions because the tools involved are legitimate.

MOVEit Transfer, 2023, as context. Just outside the three-year window, CISA's advisory AA23-158A described the CL0P group's mass exploitation of CVE-2023-34362 in the MOVEit Transfer file transfer product beginning on 27 May 2023, in which a web shell was used to steal data from the product's databases. It remains a clear public case of one file transfer product reaching many organisations at once, and of customers learning about their exposure from a vendor's notice.

What these incidents have in common

The edge and the transfer layer. Remote access appliances and file transfer products sit between the firm and the internet, and they are where mass exploitation tends to begin.

Shared components. One library or one registry account can reach many products at once.

Legitimate tools used against the firm. Remote access software, valid sessions and trusted updates were the path in several cases. Inventory and allowed lists matter as much as scanning.

The first question is "which systems, which clients". For a firm, each of these cases starts with finding where the affected product runs and whose data it holds. That is the list this guide helps you build.

The personas who own the problem

Software supply chain risk in a firm does not sit with one person. These are the people who carry it, what each needs, and when.

Firm CISO or director of information security. Owns the program and the hardest client assessments. Needs a defensible inventory, proof that known exploited flaws are fixed on a timeline, and an incident playbook that starts with "which vendors and which clients". Pressure point: the client audit and the insurance renewal.

CIO or IT director. Owns the document system, remote access and most vendor relationships. Needs end-of-support dates and vendor advisories in one place. Pressure point: the next critical edge appliance advisory.

General counsel, risk management or loss prevention partner. Owns the ethics questions: is this vendor arrangement consistent with Rules 1.6 and 5.3, does this incident trigger client notice under Formal Opinion 483 and state law, does this AI tool need informed consent. Needs facts in writing, fast. Pressure point: the vendor breach notice and the client letter.

Innovation, knowledge management or legal technology lead. Buys and builds AI assistants, automation and add-ins. Needs a fast way to vet a tool and keep in-house open source current. Pressure point: a firmwide AI rollout request.

Procurement or vendor risk owner. Owns due diligence and contract terms. Needs a standard question set and tracking. Pressure point: a renewal with no security review on file, or a client guideline that vendors have never accepted.

Litigation support and eDiscovery manager. Oversees the platforms holding the most data. Needs hosting, sub-processor and deletion facts. Pressure point: a protective order or a client asking where its data lives.

Client security assessment team. In larger firms, answers client questionnaires and audits. Needs one current source of evidence. Pressure point: the questionnaire due in 30 days, every month.

Partner in charge of a tax or audit practice. Owns Safeguards Rule compliance and the written information security plan. Needs service provider oversight and vulnerability assessment evidence. Pressure point: filing season and the annual written report that section 314.4(i) asks for.

Step by step: a 30/60/90-day plan

This plan works with spreadsheets and free tools, or with a platform. It assumes a small security team and a firm with mostly bought software.

Days 1 to 30: see what you have

1. Build the vendor register. Start from accounts payable, the single sign-on application list and the IT asset system. For each vendor record the product, the data it holds (client documents, billing, health information, taxpayer data), the owner, the hosting model, contract renewal date and any client guideline that names it.
2. Rank by client data. Tier 1 holds or moves client documents or privileged data: document management, eDiscovery, file transfer, data rooms, AI tools, email. Tier 2 holds client identity or billing data. Tier 3 is everything else.
3. List the internet edge. Every VPN, gateway, remote desktop service and file transfer product, with version and end-of-support date. Subscribe to each vendor's advisory feed.
4. Find the in-house code. Ask the innovation team, the website owner and each practice group's technologists for repositories, scripts and add-ins. Generate an SBOM for each with an open source tool or a platform.
5. Check against the CISA Known Exploited Vulnerabilities catalog. Compare edge devices and in-house SBOMs with KEV and fix or isolate anything listed.
6. Collect client terms. Pull the security sections from outside counsel guidelines and engagement letters into one matrix: notice windows, offshore limits, subcontractor rules, audit rights, patch timelines.

Days 31 to 60: ask your suppliers

1. Send the Tier 1 question set (template below) with a deadline. Ask for an SBOM where the vendor ships software you run, and for a security advisory format such as CSAF where they publish one.
2. Record answers, not just receipt. Note who answered, what is missing and what the contract already says.
3. Review AI tools against Formal Opinion 512. For each generative AI tool, record the model provider, whether inputs are used for training, retention periods, sub-processors and whether client consent is needed for the way the firm uses it.
4. Map HIPAA and Safeguards Rule scope. Mark which vendors handle protected health information or covered customer information and check that business associate agreements and service provider contract terms are in place.
5. Write the incident lookup. A one-page procedure: when a vendor or a component is named in an advisory, how to find which matters, clients and systems are affected within hours.
6. Set release checks for in-house code. Fail builds on known exploited flaws and critical findings with a fix available, with a documented exception process.

Days 61 to 90: make it stick

1. Put the asks into contracts. Use the purchasing language below at every renewal and new purchase.
2. Turn monitoring on. Alert on new KEV entries and critical advisories for Tier 1 vendors and in-house components.
3. Run a tabletop. Use a vendor breach notice as the scenario. Include the general counsel, IT, the client assessment team and a practice leader. Time how long it takes to name affected clients.
4. Prepare the client evidence pack. Vendor register summary, monitoring evidence, exception records and the incident lookup procedure, ready for the next questionnaire.
5. Report to the management committee. One page: Tier 1 vendors reviewed, gaps, decisions needed, and the next 90 days.

Template: vendor question list

Send this to Tier 1 vendors. Adjust to your client terms.

1. Will you provide a software bill of materials in SPDX or CycloneDX for the product version we run, and update it with each release?
2. How do you publish security advisories, and do you offer machine-readable CSAF advisories or VEX statements?
3. What are your target times to fix critical and known exploited vulnerabilities?
4. How will you notify us of a security incident that may affect our data, and within what time?
5. Where is our data hosted and processed, and which sub-processors can access it?
6. Do you use generative AI on our data, and if so which model providers, and are inputs used for training?
7. How do you delete our data at the end of a matter or the contract, and how is deletion confirmed?
8. Which open source components in your product have reached end of life, and what is your plan for them?
9. Do you hold an independent attestation such as an ISO/IEC 27001 certificate or a SOC 2 report, and can we review it?
10. Will you accept flow-down of our clients' security terms where a client requires it?

Template: purchasing language

Adapt with counsel. These are starting points, not tested clauses.

• Supplier will provide a software bill of materials for each major release of the licensed software, in SPDX or CycloneDX format, within 30 days of release.
• Supplier will notify the firm of any security incident that affects or is reasonably likely to affect firm or client data within the period stated in the order form.
• Supplier will remediate known exploited vulnerabilities in the licensed software within the period stated in the order form or provide a documented mitigation.
• Supplier will disclose all sub-processors with access to firm data and give advance notice of changes.
• Supplier will not use firm or client data to train machine learning models without the firm's written consent.

Decision table: a new vulnerability in something you run

Worked example: sizing the inventory (illustrative scenario)

An illustrative firm with 400 lawyers runs 120 paid applications, 20 of them Tier 1, and 15 in-house repositories. At about four hours per Tier 1 review and one hour per repository, the first pass is roughly 95 hours. These numbers are invented; redo them with your own counts.

How Safeguard does this

Safeguard can carry the inventory, vendor, code and evidence parts of the plan above. The steps below come from Safeguard's offering documentation and docs.safeguard.sh. Commands are shown as the docs show them; they were not run for this post.

1. Build the in-house inventory with the Safeguard CLI (GA). SBOM generation and analysis (GA) and software composition analysis (GA) run from the command line against one target per scan. The docs show:

   # A local directory, such as an Office add-in or intake form project
   safeguard scan --dir .
   # A container image
   safeguard scan --image myregistry.azurecr.io/myapp:v1
   # An SBOM you already have (SPDX or CycloneDX)
   safeguard scan --sbom sbom.json
   

   Results land under ./output by default, and safeguard scan does not fail on findings; gating is a separate step.

2. Keep code on firm machines with the local runner (GA). Per the docs, the runner polls the platform over outbound HTTPS it opens itself, runs each scan locally and uploads only the SBOM and findings, never source code. That suits a firm whose engagement terms rule out giving an outside service repository access.

3. Load vendor SBOMs as they arrive. The Upload SBOM card on the Integrations page takes an SBOM made by another tool; Safeguard validates it, enriches it with vulnerability data and keeps monitoring it. To check a file locally first, the docs show safeguard validate sbom.json.

4. Request SBOMs from Tier 1 vendors with the Third-Party Risk Manager (GA). Request an SBOM from one vendor or use Bulk Request, from the standard or a custom template. Each request moves through Sent, Viewed, In Progress, Submitted, and Validated or Rejected, with reminders seven days before the deadline and at it.

5. Score and monitor vendors (GA). TPRM gives each vendor a 0 to 100 risk score, where 76 to 100 is low risk and 0 to 25 is critical. Monitoring alerts on a new critical CVE, a CISA KEV addition, a score drop below a threshold and a stale SBOM, with daily re-assessment available for critical vendors.

6. Record vendor statements as CSAF and VEX (GA). The docs support CSAF 2.0 and VEX in CycloneDX, OpenVEX and CSAF profiles. A vendor's "not affected" statement is recorded against its product, which is the evidence the decision table asks you to keep.

7. Prioritise with KEV, EPSS and reachability (GA). Vulnerability management (GA) enriches findings with EPSS and CISA KEV status. For in-house code, reachability analysis (GA) ranks the vulnerable paths your code actually calls.

8. Gate in-house releases with policies and gates (GA). Policies can be advisory or blocking. Each gate action is Block (the gate fails), Warn (it passes with a warning naming the policy) or Notify (it passes and sends a notification). Approval runs through exceptions: a developer requests one, approvers decide, and the history is kept. In CI, the docs show:

   safeguard ci scan --wait --fail-on-gate <gate>
   

9. Fix the open source in your own code with autonomous remediation (GA, ships off). Griffin can open tested, policy gated pull requests that move a vulnerable dependency to a fixed version. It ships switched off, with every category set to Manual.

10. Find the AI in your code and cloud with AI-BOM discovery (GA). Per the docs, an administrator switches it on, and it finds AI SDK imports, model files, prompt templates and MCP server configuration in code, managed AI services in cloud accounts, and unsanctioned AI services through connected SaaS integrations, assembled into an AI-BOM. For a risk partner working through Formal Opinion 512, that is evidence rather than a survey. The AI Gateway (GA), an LLM firewall that sits in front of model calls, can watch for prompt injection and personal data leaving in prompts, in monitor mode by default.

11. Answer client assessments from one evidence set with the compliance suite (GA) and Trust Center (GA). The framework library includes data protection laws and standards such as SOC 2 and ISO/IEC 27001, and the HIPAA Security Rule page maps controls, including business associate management, to tests and evidence. Trust Center publishes your frameworks, policies, sub-processors from your vendor register and documents, each Public or Restricted, with restricted ones released through access requests. Client security contacts can be notified when you publish an update.

12. Keep client-adjacent work inside the firm if you need to (GA). Zero AI mode (GA) runs the platform with no LLM in the loop, and bring your own model (GA) lets a firm use a model it has already approved. On-prem and fully air-gapped deployment (GA) are available; the docs describe signed snapshot bundles of feed updates delivered by one-way diode, signed removable media or a short scheduled sync. Safeguard is designed for FedRAMP High, and its SOC 2 Type II audit is in progress.

Which persona uses which part

What Safeguard does not do

• It does not secure email, identities or endpoints. Phishing defense, multi-factor authentication, endpoint protection and the controls that would stop a callback phishing call stay with your IT team and its other tools.
• It cannot inventory a closed vendor product on its own. For a hosted document system, eDiscovery platform or data room, Safeguard works from what the vendor provides: an SBOM, a CSAF advisory or a VEX statement. If a vendor supplies nothing, the register records the gap.
• It does not patch vendor products or SaaS. Fixes for a vendor's appliance, hosted platform or desktop software come from that vendor. Autonomous remediation applies to the open source dependencies in code you build.
• It does not make ethics or notice decisions. Whether a vendor arrangement meets Rules 1.6 and 5.3, whether client consent is needed for an AI tool, and whether an incident requires client or regulator notice are decisions for lawyers. Safeguard can supply facts; the judgment stays with the general counsel and the firm.
• It does not read your documents. Safeguard works on code, packages, images, SBOMs and vendor records. It is not a document classification or data loss prevention tool for the document management system.

Common mistakes

• Treating the vendor register as an IT asset list. The register must record which client data each vendor holds and which client terms apply. Without that, the incident lookup fails.
• Asking every vendor everything. Tier the vendors and send Tier 1 the short list.
• Forgetting the tools lawyers adopted themselves. Browser extensions, transcription apps and personal AI accounts carry client facts too.
• Approving AI tools on the vendor's marketing page. Formal Opinion 512 asks lawyers to understand how a tool uses and retains information. Get it in writing.
• Patching edge appliances and stopping there. The CitrixBleed advisory paired updates with isolation and a hunt for malicious activity. Plan for all three after a critical edge advisory.
• Leaving in-house code out of scope because it is small. Scripts and add-ins pull hundreds of open source packages, and they run with lawyers' permissions.
• Writing exceptions without expiry dates. An exception that never expires becomes the policy.

FAQ

Do the ABA Model Rules require a law firm to have a vendor risk program?

Not by that name. Rule 1.6(c) requires reasonable efforts to prevent unauthorized access to client information, and Rule 5.3 extends supervision duties to outside services. Formal Opinion 477R lists vendor due diligence among the considerations. Together they make a vendor review process the practical way to show reasonable efforts. Your state's version of the rules governs.

Does the FTC Safeguards Rule apply to law firms?

It applies to financial institutions under the FTC's jurisdiction. The rule's examples include tax preparation services that complete income tax returns, so a firm with a tax preparation practice may be covered for that work. Whether any other part of a law firm is covered is a legal question for your counsel.

What does ABA Formal Opinion 512 mean for buying AI tools?

It applies existing duties to generative AI. For confidentiality, it says lawyers should understand who can access what they put into a tool, and that a client's informed consent is required before information relating to the representation goes into a self-learning tool. In practice, that means vetting the model provider, training terms, retention and plug-ins before rollout.

Is a law firm a HIPAA business associate?

It can be. The HIPAA definition of business associate includes legal, accounting and consulting services that involve protected health information for a covered entity. The definition also covers a subcontractor that handles that information for the firm, such as an eDiscovery host, so the chain of agreements runs through your vendors too.

What should we ask a document management or eDiscovery vendor before buying?

Ask for an SBOM for the version you run, how they publish advisories, their fix times for known exploited flaws, incident notice terms, hosting and sub-processors, use of AI on your data, and how deletion is confirmed. The template above lists ten questions.

Our vendor says it cannot provide an SBOM. Now what?

Record the answer, ask for the next best evidence (a CSAF advisory feed, a VEX statement, an attestation report, a list of major open source components) and set a review date. Weigh the gap in your risk register, and add an SBOM clause at renewal.

How fast must a firm tell clients about a vendor breach?

Formal Opinion 483 describes a duty to notify current clients when a breach involves, or has a substantial likelihood of involving, material client information, without setting a number of days. State breach laws, HIPAA, the Safeguards Rule's 30-day FTC notice for covered institutions and client contracts may set specific windows. Your general counsel decides which apply.

Are AI drafting tools part of the software supply chain?

In practice, yes. Formal Opinion 512 asks lawyers to understand who can access what goes into a tool, which means its model provider, plug-ins and retention terms. Record them in the vendor register like any other Tier 1 system.

Most of what a firm runs is bought, so most fixes come from vendors. The part a firm can fix itself is the open source inside its own integrations, add-ins and client tools, and the section below covers that part.

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: setting it up on your own machine, approving it with its device code, then scanning from the terminal. For a firm whose engagement terms or ethical walls keep code on firm hardware, this is how a scan runs without giving an outside service access to the repository.

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

The second demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before any command that changes something, edit package.json to lodash 4.17.21, run npm install and npm test with approval, print a summary and push nothing. The same flow fits an Office add-in, a client intake form or an innovation team prototype.

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

Quick check

Related reading

• Related in this series: 90-day plan for hospitals and health systems
• Legal tech software security and compliance
• The legal sector's software supply chain in 2026
• A software supply chain legal risk assessment template
• Breach notification clocks across GDPR, SEC, HIPAA and state laws
• Safeguard's Third-Party Risk Manager

Sources

• ABA Model Rule 1.1, Comment
• ABA Model Rule 1.6, Confidentiality of Information
• ABA Model Rule 1.6, Comment
• ABA Model Rule 5.3, Responsibilities Regarding Nonlawyer Assistance
• ABA Model Rule 5.3, Comment
• ABA Formal Opinion 477R, Securing Communication of Protected Client Information
• ABA Formal Opinion 483, Lawyers' Obligations After an Electronic Data Breach or Cyberattack
• ABA Formal Opinion 512, Generative Artificial Intelligence Tools
• 16 CFR 314.2, Safeguards Rule definitions
• 16 CFR 314.4, Safeguards Rule elements
• Federal Register, Standards for Safeguarding Customer Information, 88 FR 77499
• IRS Publication 4557, Safeguarding Taxpayer Data
• IRS Publication 5708, Creating a Written Information Security Plan
• 45 CFR 160.103, HIPAA definitions
• NIST Cybersecurity Framework 2.0, NIST CSWP 29
• CISA, 2026 Minimum Elements for a Software Bill of Materials
• CISA advisory AA23-325A, LockBit 3.0 affiliates exploit CitrixBleed
• CISA alert, supply chain compromise affecting XZ Utils, CVE-2024-3094
• CISA alert, widespread supply chain compromise impacting npm
• CISA advisory AA23-158A, CL0P exploits MOVEit CVE-2023-34362
• FBI Private Industry Notification 20250523-001, Silent Ransom Group Targeting Law Firms
• FBI FLASH-20260526-01, Silent Ransom Group Impersonating IT Personnel
• Safeguard docs: CLI usage
• Safeguard docs: Local runner
• Safeguard docs: Existing SBOM upload
• Safeguard docs: TPRM SBOM requests
• Safeguard docs: TPRM risk assessment
• Safeguard docs: TPRM monitoring
• Safeguard docs: CSAF and VEX upload
• Safeguard docs: Policies and gates
• Safeguard docs: AI-BOM discovery
• Safeguard docs: Compliance
• Safeguard docs: HIPAA Security Rule
• Safeguard docs: Trust Center setup
• Safeguard docs: Air-gapped deployment

To try the flows above, download Safeguard and read the documentation.

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