Treat each dependency group as an asset that touches electronic protected health information, then record threats, likelihood, impact and the control you rely on. The Security Rule asks for an accurate and thorough assessment of risks and vulnerabilities, so a risk analysis that ignores third party code has a visible gap.
What the rule asks for
45 CFR 164.308(a)(1)(ii)(A) requires an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of electronic protected health information. The next item, risk management, asks you to implement measures sufficient to reduce those risks to a reasonable and appropriate level. The flexibility clause in 164.306(b) lets you weigh your size, technical capabilities, cost and the probability and criticality of risks.
Nothing there names open source. It does not need to. If code in your product handles ePHI, it is in scope.
A worked structure
Group dependencies instead of listing thousands of rows. A group is a set of components with the same role and exposure.
| Group | Role | ePHI exposure | Main threat | Control relied on |
|---|---|---|---|---|
| Web framework and middleware | Request handling | Direct, all traffic | Remote code execution, auth bypass | Scanning, update policy, WAF |
| Serialization and parsing libraries | Reads untrusted input | Direct | Injection, deserialization flaws | Scanning, input validation |
| Crypto and TLS libraries | Protects data at rest and in transit | Direct | Weak or outdated algorithms | Version pinning, review |
| Logging libraries | Writes records | Indirect, may hold ePHI | Leakage, log injection | Log scrubbing, access control |
| Build and test tooling | Produces releases | None at runtime | Tampering with releases | Pipeline controls |
The likelihood and impact columns come from your own judgment, and the table above leaves them out on purpose. Use whatever scale your existing analysis uses so the pages stay consistent.
Steps
- Generate a current inventory, including transitive components.
- Cluster by role and by whether the code is on a path that handles ePHI.
- For each group, list realistic threats from advisories you have seen, not generic ones.
- Score likelihood and impact with your existing scale.
- Name the control, the owner and the review date.
- Record the date and the version of the inventory you used.
Update the analysis when something changes. The rule asks for periodic evaluation and a response to environmental or operational changes (164.308(a)(8)), and for documentation to be reviewed and updated as needed (164.316(b)(2)(iii)).
Common mistakes
- Using a list of direct dependencies only, which misses most of the code that ships.
- Scoring every group "high" so nothing can be prioritized.
- Attaching a scan report instead of a risk statement. A scan is evidence, not an analysis.
- Forgetting build tooling, which can alter what you ship.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how findings are grouped and prioritized, which is the same move you make when you cluster dependencies by exposure.
Safeguard produces dependency inventories and reachability results that can feed steps 1 to 3, and its compliance and evidence automation keeps dated records. The risk judgments remain yours.
Quick check
Do we need to list every transitive package in the risk analysis?
No. Keep the full inventory as supporting data and analyze groups. Reviewers read the analysis, and the inventory proves it is grounded.
How often should the analysis be updated?
The rule ties updates to change and periodic evaluation rather than a fixed day. Many teams review at least annually and after major releases or incidents.
Sources
- 45 CFR 164.308 Administrative safeguards, eCFR
- 45 CFR 164.306 Security standards: General rules, eCFR
- 45 CFR 164.316 Policies and procedures and documentation, eCFR
Last reviewed: 19 October 2026.
