HIPAA's Security Rule never names open source software, but 45 CFR 164.308(a)(1)(ii)(A) requires an accurate risk analysis of every system handling electronic protected health information (ePHI) — and a system's risk includes every third-party component compiled into it, which makes your dependency tree a regulated artifact. Developers at covered entities and business associates often assume HIPAA is the compliance team's problem, all policies and training modules. Then a critical CVE lands in a library inside the patient portal, and the question "was this a reasonable and appropriate safeguard failure" suddenly has a version number attached. Here's how the Security Rule actually reaches your package.json, and what evidence holds up when the Office for Civil Rights (OCR) comes asking.
Where the Security Rule touches dependencies
The Security Rule is deliberately technology-neutral, built on "reasonable and appropriate" safeguards. Three provisions do the work for third-party components:
| Provision | Requirement | Dependency-tree translation |
|---|---|---|
| 164.308(a)(1)(ii)(A) | Risk analysis | Know what components exist in ePHI systems and their vulnerabilities |
| 164.308(a)(1)(ii)(B) | Risk management | Remediate or mitigate those vulnerabilities to a reasonable level |
| 164.308(a)(8) | Evaluation | Periodically re-evaluate as software and threats change |
OCR's enforcement history says risk analysis is the provision that bites: it has appeared in the majority of significant settlements, from Anthem's $16 million (2018) onward. And OCR's own guidance defines risk analysis as covering all systems containing ePHI — an analysis that inventories servers but not the software running on them is incomplete on its face. A dependency inventory per ePHI-handling application, refreshed continuously rather than annually, is the engineering answer. If you don't have one, an SBOM generated in CI is the fastest path; the SBOM primer covers the mechanics.
"Reasonable and appropriate" patching, in practice
HIPAA sets no patch deadlines. What it sets is a negligence standard: if a patch existed, the vulnerability was known, exploitation was foreseeable, and you did nothing, that's a risk management failure under 164.308(a)(1)(ii)(B). The 2017 breach era made this concrete — unpatched, internet-facing systems with known CVEs featured in multiple OCR resolution agreements and state attorney general actions.
A defensible program looks like: continuous software composition analysis across ePHI applications, documented severity-based SLAs (a common choice: critical fixes within 15 days, high within 30, with compensating controls documented when upgrade is infeasible), and tickets proving the SLAs operate. The documentation matters as much as the patching — 164.316(b)(1) requires maintaining written records of actions and assessments, and OCR requests them by date range. "We patched it quickly" is an assertion; a Jira export showing median time-to-remediate is evidence.
BAAs and the vendor chain
Third-party services follow a different rule than third-party code. Any vendor that creates, receives, maintains, or transmits ePHI on your behalf is a business associate and needs a Business Associate Agreement under 164.308(b) — that includes your cloud provider (AWS, Azure, and GCP all sign BAAs covering specific services), your error-tracking SaaS if stack traces can contain ePHI, and your analytics vendor if identifiers leak into events. Subcontractors inherit the obligation down the chain.
Open source libraries need no BAA — no entity is handling ePHI on your behalf; you're running their code as your own. The flip side: there is no BAA to point at when it fails. The library's risk is entirely yours, which is precisely why component inventory and scanning belong in the risk analysis. A dry observation from audit experience: teams can usually produce every BAA within an hour, and the list of libraries inside the ePHI system within a week. OCR notices the asymmetry too.
The breach math nobody wants to do
If a vulnerable component leads to unauthorized access to unsecured ePHI, the Breach Notification Rule (164.400 onward) starts the clock: individuals notified within 60 days, HHS notified (immediately for 500+ individuals, annually below that), media notified for large breaches, and your organization added to the public HHS breach portal — the "wall of shame." Civil penalties are tiered by culpability, reaching $50,000+ per violation with annual caps above $1.9 million per violation category, and willful neglect uncorrected draws the top tier.
February 2024's Change Healthcare attack, which disrupted claims processing across a substantial share of US healthcare, is the current reminder that a single technology supplier can become a sector-wide dependency — and that the post-incident questions ("what did you know about this vendor's security, and when") land on whoever signed the risk analysis. Vendor due diligence records, not just BAAs, are part of the defensible file.
A concrete program for a development team
Keep it small enough to actually run: (1) generate an SBOM per release for every ePHI-touching application and retain it; (2) scan continuously, triage on a defined SLA, and record risk acceptances with an owner and review date; (3) reference the component inventory explicitly in the enterprise risk analysis so the documents connect; (4) verify BAAs exist for every service in the data path, including logging and observability; (5) re-run the loop after major architecture changes, because 164.308(a)(8) expects evaluation on change, not just calendar. Teams using Safeguard typically wire steps 1–2 into CI and export the evidence for step 3, which keeps the compliance file current without a quarterly scramble.
Frequently asked questions
Does HIPAA require vulnerability scanning?
Not explicitly — the Security Rule predates modern scanning practice and stays technology-neutral. But OCR guidance and enforcement treat identification of technical vulnerabilities as inherent to the required risk analysis, and scanning is the only scalable way to identify them in third-party components.
Do open source libraries need a Business Associate Agreement?
No. BAAs apply to entities handling ePHI on your behalf, and a library you embed is your own system component, not a vendor relationship. Its vulnerabilities are your direct responsibility under the risk analysis and risk management provisions.
What evidence does OCR actually request after a breach?
Typical data requests include the current and historical risk analyses, risk management plans, policies and procedures, audit logs, patch and remediation records for the affected systems, and relevant BAAs. Requests are date-ranged, so retroactively created documents are easy to spot.
We're a health-tech startup, not a hospital. Does this apply?
If you handle ePHI for covered entities, you're a business associate and directly liable under the Security Rule since the 2013 Omnibus Rule. Your customers' compliance teams will also contractually require the same evidence OCR would, usually during sales security review.