The Invisible Inventory
When you think about your practice's technology footprint, you probably think about your EHR, your practice management system, your email, maybe a handful of SaaS tools. That is the visible inventory. The invisible inventory is much larger: every one of those systems is built on top of dozens or hundreds of third-party libraries, frameworks, and open-source components. A flaw in any one of them becomes a flaw in your environment.
The 2020 SolarWinds compromise, the 2021 Log4Shell vulnerability, and the steady drumbeat of npm and RubyGems supply-chain incidents since have made one thing clear: the attack surface does not end where your vendor's product ends. It extends all the way down into the dependency tree they built on.
How Supply Chain Risk Shows Up in Healthcare
Three patterns dominate the healthcare incidents we see:
1. The vulnerable dependency
A widely used open-source library ships a patch for a critical vulnerability. Your EHR vendor is using an older version. Between the time the vulnerability is disclosed and the time your vendor rolls out the patch to your tenant, you are exposed. If the vulnerability is already on the CISA KEV list, you may be exposed to active exploitation.
2. The compromised package
An attacker takes over a legitimate open-source package — often by phishing or buying the credentials of a maintainer — and publishes a malicious version. Every downstream consumer who pulls the package in a build pipeline gets the poisoned code. This has happened dozens of times in the last three years across Python, JavaScript, and Ruby ecosystems.
3. The compromised update channel
The most serious variant. The vendor's own software distribution infrastructure is compromised, and malicious code is pushed out to customers disguised as a routine update. SolarWinds is the canonical example. Healthcare-specific variants have hit EHR vendors and remote-access tools.
The Questions HIPAA Officers Should Be Asking
You do not need to audit your vendors' source code. You do need to ask vendors specific questions that surface whether they are taking supply chain risk seriously. When you renew a Business Associate Agreement this year, add these to the conversation:
Dependency hygiene
- Do you maintain a Software Bill of Materials (SBOM) for this product?
- How quickly do you patch critical vulnerabilities in your dependencies? What is your SLA?
- Do you subscribe to CVE and KEV feeds and automatically match them against your dependency tree?
Build pipeline integrity
- Are your build artifacts signed? How do customers verify signatures?
- Do you require MFA on developer and release-engineer accounts?
- What prevents a single compromised developer account from shipping malicious code to production?
Third-party risk
- What sub-processors do you rely on? (This should already be listed in your BAA.)
- How do you monitor your sub-processors for breaches?
- Will you notify us if one of your sub-processors is compromised, even if our data was not directly affected?
What Your Own Practice Should Do
You cannot outsource all supply chain risk to your vendors. There are concrete steps the practice itself needs to take:
Know what runs on your network
An endpoint agent that inventories installed software gives you the ground truth. When a high-profile CVE lands, you want to know within hours whether the affected software is running anywhere in your environment. A practice that cannot answer that question within a working day is flying blind.
Match KEV against your inventory automatically
The CISA Known Exploited Vulnerabilities catalog is the most operationally useful threat feed available for free. Match every new KEV entry against your software inventory the day it is added. If there is a match, open a remediation ticket immediately.
Require breach notification clauses in every BAA
HIPAA requires business associates to notify you of breaches. Make sure the clause in your BAA specifies a timeline (ideally within 24 hours of the vendor's own discovery, certainly within 72) and requires them to notify you of supply-chain incidents affecting their vendors, not just yours.
Document your vendor review cadence
OCR is increasingly interested in whether practices actively review vendor security, not just sign BAAs and forget about them. An annual vendor review cycle — even a light one — demonstrates active risk management and produces the audit trail investigators want to see.
A Note on Open-Source Maturity
Not every supply-chain story is negative. The open-source ecosystem has invested heavily in supply-chain security tooling over the last several years: Sigstore, SLSA provenance, and reproducible builds are now standard in mature projects. When you evaluate a vendor, ask whether they are using those tools. If a vendor has never heard of SBOM or SLSA in 2026, that is a signal about the maturity of their security program.
What OCR Expects
The HIPAA Security Rule does not mention “supply chain” by name. It does require you to conduct a risk analysis that covers “reasonably anticipated threats,” and in 2026 supply-chain risk is firmly in that category. Enforcement cases over the last three years have repeatedly cited failures to assess third-party risk as aggravating factors. Treating your software stack as a closed box labeled “our EHR vendor's problem” is no longer a defensible position.
The Bottom Line
Your practice's security posture is a composite of every piece of software you touch and every piece of software those pieces touch. You cannot audit the whole tree yourself, but you can pick vendors who do, you can know what is running on your network, and you can respond quickly when something goes wrong. That combination is what separates practices that survive the next supply-chain incident from the ones that become the case study.