Hospital Software Supply Chain Security: Rules, Incidents, 90-Day Plan

A hospital secures its software supply chain by knowing which components sit inside every system that touches patient data or patient care, holding vendors to written SBOM and disclosure terms, and folding that inventory into the HIPAA risk analysis it already owes. In practice that means one inventory, one vendor process and one evidence trail, built over about 90 days and kept current after that.

This guide is written for the people who carry that work inside a health system: the CISO, the leader of the applications and integration team, the HIPAA security and compliance lead, the vendor risk and procurement owner, and clinical engineering. The first two thirds work with whatever tools you already have. Safeguard only enters at the section titled "How Safeguard does this".

Key takeaways

• The HIPAA Security Rule already requires an accurate and thorough risk analysis and risk management (45 CFR 164.308(a)(1)(ii)(A) and (B)). Third-party and open source software inside your systems is part of that risk, whether or not anyone has listed it.
• The proposed Security Rule update (published 6 January 2025 at 90 FR 898) is still a proposal. The Fall 2025 Unified Agenda lists final action for July 2027. Plan for it, but do not describe it as law.
• HHS's voluntary Healthcare and Public Health Cybersecurity Performance Goals (CPGs) make "Vendor/Supplier Cybersecurity Requirements" an essential goal and "Third Party Vulnerability Disclosure" an enhanced one. The 2021 HITECH amendment lets OCR weigh recognized security practices that were in place for the previous 12 months.
• For connected medical devices, section 524B of the FD&C Act requires manufacturers of cyber devices to supply an SBOM covering commercial, open source and off-the-shelf components. Hospitals can ask for it during purchasing.
• Safeguard capabilities used in this guide, all GA: TPRM (Third-Party Risk Manager) with vendor SBOM requests and continuous monitoring, SBOM generation and analysis, SCA with deep transitive dependency scanning, vulnerability management with EPSS and CISA KEV enrichment, reachability analysis, policies and gates, license compliance, CSAF and VEX upload, the Compliance and GRC suite with HIPAA Security Rule evidence mapping, autonomous remediation (ships switched off, every category set to Manual), the CLI and local runner, and on-prem and air-gapped deployment with Zero AI mode.

The situation

Hospitals rarely start this work because someone read a framework. They start it because something lands on a desk with a date attached.

It might be the annual HIPAA risk analysis, with an auditor asking how third-party components are covered. It might be an EHR or imaging renewal, with legal asking what security terms to add. Or it might be a board member asking which vendor could stop billing for a month.

A bad week looks like this. A widely used open source library gets a critical advisory on Monday. By Tuesday the CISO is asked whether the portal, the integration engine and the bedside devices are affected. The application team can answer for its own code after some searching. Vendors answer slowly. Clinical engineering knows the device models but not their software. By Friday the honest answer is still "we think we are fine", which nobody wants to tell a regulator or a board.

The rest of this guide is about turning that answer into "here is the list, here is the status, and here is the evidence".

What software a hospital actually runs

A health system is one of the most software-dense organizations in the economy, and most of that software is bought rather than built. That matters, because the components inside bought software are invisible unless you ask for them.

Two points follow from this table.

First, the code you write yourself is the easiest part to secure and, for most hospitals, the smallest part. A plan that covers only in-house code covers a sliver of the risk.

Second, the systems that carry the most clinical and financial weight (the EHR, the clearinghouse, the devices) are the ones where you have the least direct visibility. The lever there is contract terms and vendor process, not scanning.

The regulations and frameworks that apply

This section summarizes primary sources as they stood on 25 October 2026. It is not legal or regulatory advice. Your counsel and compliance team decide how each rule applies to your organization.

The HIPAA Security Rule as it stands today

The Security Rule at 45 CFR Part 164, Subpart C, is the binding baseline for covered entities and business associates. Four of its provisions do most of the work for software supply chain risk.

• Risk analysis, 164.308(a)(1)(ii)(A), Required. The text asks for "an accurate and thorough assessment" of risks and vulnerabilities to the confidentiality, integrity and availability of electronic protected health information (ePHI). A vulnerable component inside the EHR, the portal or an interface engine is a vulnerability to ePHI. If your risk analysis cannot see components, it is hard to call it thorough.
• Risk management, 164.308(a)(1)(ii)(B), Required. You must implement security measures that reduce risks and vulnerabilities to a reasonable and appropriate level. A patching and upgrade process for components, with a record of decisions, is one of those measures.
• Evaluation, 164.308(a)(8). A periodic technical and nontechnical evaluation, repeated in response to environmental or operational changes. A major vendor upgrade or a new critical advisory in a widely used component is that kind of change.
• Business associate contracts, 164.308(b)(1) and 164.314(a). A covered entity may let a business associate handle ePHI only with satisfactory assurances, written into a contract. Under 164.314(a), the contract must require the business associate to report security incidents it becomes aware of. That clause is the legal hook for asking vendors how they will tell you about vulnerabilities in their software, not only about breaches.

Read together, these provisions mean a hospital is already expected to understand the risk that third-party software brings, even though the rule never uses the word SBOM.

The proposed Security Rule update

On 6 January 2025, HHS published a notice of proposed rulemaking to modify the Security Rule (90 FR 898). Its abstract says the changes respond to the shifting environment in which care is delivered, significant increases in breaches and cyberattacks, and common deficiencies OCR has observed in its investigations. Read the proposed regulatory text itself before planning around any single provision, because summaries of it vary and the final rule may differ.

The status matters more than the content for planning. The Spring 2025 Unified Agenda listed final action for May 2026. The Fall 2025 Unified Agenda, for the same rule (RIN 0945-AA22), lists final action for July 2027. As of today it is a proposal, nothing in it binds anyone, and any final rule may differ. A sensible approach is to build the inventory and vendor process now because the current rule already justifies them, and to treat the proposal as a signal of where OCR's expectations are heading.

Recognized security practices under HITECH

Public Law 116-321, signed 5 January 2021, added section 13412 to the HITECH Act (42 U.S.C. 17941). When OCR makes certain enforcement decisions, it must consider whether a covered entity or business associate had recognized security practices in place for "not less than the previous 12 months". Those practices can mitigate fines, support early and favorable termination of an audit, and mitigate the remedies in a resolution agreement.

The law defines recognized security practices to include standards developed under the NIST Act and the approaches promulgated under section 405(d) of the Cybersecurity Act of 2015. That second reference is why the 405(d) program matters to hospitals in legal terms, not only technical ones. The 12-month clock is also why starting now matters: a practice you begin next quarter only starts counting next quarter.

HHS 405(d) and the Health Industry Cybersecurity Practices

The 405(d) program, run by HHS with industry, publishes the Health Industry Cybersecurity Practices (HICP). HICP is organized as practices and sub-practices sized for small, medium and large organizations. The ones that touch software supply chain risk include IT asset management (inventory of endpoints and servers, and procurement), vulnerability management (host and web application scanning), and cybersecurity oversight and governance (cybersecurity risk assessment and management, sub-practice 10.M.B). HHS hosts these resources on its cyber gateway for the Healthcare and Public Health sector.

The HPH Cybersecurity Performance Goals

HHS published voluntary Cybersecurity Performance Goals for the Healthcare and Public Health sector in early 2024. They come in two tiers. Each goal is mapped to HICP sub-practices, NIST SP 800-53 controls and CISA's cross-sector goal IDs. The ones that bear directly on the software supply chain are:

The goals are voluntary, but they give boards, auditors and vendors a shared vocabulary.

FDA section 524B for connected medical devices

Section 524B of the Federal Food, Drug, and Cosmetic Act (21 U.S.C. 360n-2), added by the Consolidated Appropriations Act, 2023, applies to manufacturers submitting premarket applications for "cyber devices". Among other duties, the manufacturer must provide FDA with a software bill of materials, "including commercial, open-source, and off-the-shelf software components". FDA's premarket cybersecurity guidance explains how the agency expects that SBOM and the related documentation to look; check FDA's guidance page for the current edition before quoting it.

The duty falls on manufacturers, not hospitals, but it changes what a hospital can reasonably ask for during purchasing.

SBOM and disclosure formats

CISA maintains the federal government's SBOM resources, including its current Minimum Elements guidance for what an SBOM should contain. For vulnerability status, the common formats are CSAF advisories and VEX (Vulnerability Exploitability eXchange) statements, which let a vendor say "this component is present but not affected" in a machine-readable way. When you write vendor terms, name the formats you accept (SPDX or CycloneDX for SBOMs; CSAF or VEX for status) rather than "an SBOM in a standard format".

Real public incidents from the last three years

The incidents below are drawn from official statements and primary reporting. They are summarized only as far as the sources go. None of them is used here to say what a named organization should have done.

Change Healthcare, 2024

Change Healthcare handles claims, eligibility and pharmacy transactions for a very large number of US providers. Its systems went down in February 2024, and the outage was widely reported to have disrupted claims and pharmacy work for providers across the country. In its 22 April 2024 update, UnitedHealth Group said its review had found files containing protected health information or personally identifiable information that "could cover a substantial proportion of people in America". OCR keeps a Change Healthcare FAQ that tracks the breach report filed with it; check it for the current count rather than relying on early figures.

The lesson most often drawn is about concentration: one business associate sat in the payment path of a very large number of providers. "What happens if this vendor is down for weeks" is a vendor risk question before it is a technical one.

XZ Utils, 2024

On 29 March 2024, CISA reported that malicious code had been embedded in XZ Utils versions 5.6.0 and 5.6.1 and that the activity was assigned CVE-2024-3094. XZ Utils is a small data compression library that ships in many Linux distributions. It is the kind of component nobody lists in a contract, yet it can sit underneath an imaging server, an interface engine or a container base image.

The question for a hospital was where it ran a distribution that could have pulled in those versions. Teams with a component inventory answered by searching; others had to ask every vendor.

Ascension, 2024

Ascension, one of the largest US health systems, disclosed a ransomware attack that began on 8 May 2024. Reporting on its December 2024 notice puts the number of affected people at 5,599,699 and says the attackers obtained medical, insurance, government identification and payment information. The same reporting cites Ascension's earlier statement that attackers accessed seven of its roughly 25,000 servers.

It was not a software supply chain attack in the narrow sense, but it shows how much hospital operations depend on software being available.

Contec CMS8000 patient monitor, 2025

On 30 January 2025, CISA and FDA released a fact sheet (revised 13 February 2025) on the Contec CMS8000, a patient monitor used in the US Healthcare and Public Health sector. Analysts found an embedded backdoor function with a hard-coded IP address (CWE-912, hidden functionality, CVE-2025-0626) and functionality that enables patient data spillage (CWE-359, CVE-2025-0683) in all three firmware versions they examined. CISA also warned that the device may be relabeled and sold by resellers, and pointed to FDA's safety communication for a list of known relabeled models.

That last detail is the supply chain lesson. A hospital that buys a monitor under one brand may not know that its firmware came from another manufacturer. Asset records that track the device's actual origin, and procurement questions that ask for it, are the only way to find those devices quickly.

Shai-Hulud npm worm, 2025

On 23 September 2025, CISA described a widespread compromise of the npm registry by a self-replicating worm, publicly known as Shai-Hulud, which had compromised over 500 packages. According to CISA, the malicious code scanned environments for credentials and targeted source code hosting tokens and cloud API keys.

Hospitals with portal, research or integration developers use npm packages, and so do many of their vendors. Teams that could list which builds had pulled affected versions, and rotate their credentials quickly, had a much shorter week.

What the incidents have in common

Across these cases, three questions decided how long the bad week lasted:

1. Do we know which of our systems contain the affected component, device or vendor?
2. Do our vendors have a written duty, and a working channel, to tell us what they know?
3. Can we record what we decided, so the risk analysis and any later inquiry can see it?

Those questions shape the persona section and the plan that follow.

The personas who own the problem

Software supply chain risk in a hospital has no single owner. It is split across roles that report to different leaders and work on different calendars. The table summarizes who needs what and when; the subsections explain each role.

Three patterns sit behind the table. The CISO and the Security Officer need the same facts in different shapes: one as a board-readable risk view, the other as dated evidence mapped to clauses. The applications leader and IT operations will accept controls that ride along with releases and patch cycles, and will resist anything that adds a manual review to every change. Procurement and clinical engineering hold the strongest position over bought software and devices, because contracts and purchasing are where SBOM and disclosure terms get agreed.

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

This plan works with or without Safeguard. It assumes a health system with an existing HIPAA program, some in-house development, and a vendor list of a few hundred entries. Adjust the scope to your size; a critical access hospital might cover the same steps with a much shorter list.

Days 1 to 30: see what you have

1. Name an owner and a working group. One accountable owner (often the CISO or the Security Officer) and one representative each from applications, vendor risk, clinical engineering and IT operations. Meet weekly for 30 minutes.
2. Pull the vendor list from accounts payable and the BAA register. Do not start from the CMDB alone. Contracts and payments find the vendors that IT does not manage.
3. Tier vendors by impact. Use a simple four-level scale. A worked tiering model is below.
4. Inventory in-house code. List every repository and container image your teams build, including research and analytics code. Generate an SBOM for each in SPDX or CycloneDX, using whatever tooling you have.
5. Collect what vendors already publish. Many vendors post security pages, SBOMs, CSAF advisories or VEX statements. Gather what exists before asking for more.
6. Pull device records from clinical engineering. For each device model: manufacturer, actual origin if relabeled, firmware version, network connection, and whether a manufacturer SBOM is available.
7. Write the first entry in the risk analysis. Add "third-party and open source software components" as a named risk, with the current state honestly described. Date it.

Template: vendor tiering

Days 31 to 60: set terms and gates

8. Adopt standard contract language. Work with counsel to add SBOM and vulnerability disclosure terms to new contracts and renewals, starting with Critical and High tiers. A clause checklist is below.
9. Send SBOM requests to Critical vendors. Ask for an SBOM in SPDX or CycloneDX, the date it was produced, the product version it covers, and a named security contact. Set a deadline and a reminder schedule.
10. Set a rule for in-house builds. Decide what blocks a release (for example, a critical vulnerability listed in CISA's Known Exploited Vulnerabilities catalog in a reachable component), what produces a warning, and what only notifies. Write down who can approve an exception and for how long.
11. Rank findings by exploitability. Use EPSS scores and the KEV catalog to put exploited and likely-to-be-exploited issues first. A long list of medium findings is not a plan.
12. Agree a device exception process with clinical engineering. For devices that cannot be patched quickly, record the compensating controls (segmentation, access restriction, monitoring) and the manufacturer's stated timeline.

Checklist: contract clauses for software vendors

• SBOM delivered in SPDX or CycloneDX, covering commercial, open source and third-party components, for each major release and at least on the cadence for the vendor's tier.
• Vulnerability status statements (CSAF or VEX) for advisories affecting components in the SBOM, within a stated number of days.
• A named security contact and a coordinated vulnerability disclosure policy.
• Notification of security incidents that may affect the hospital's systems or ePHI, consistent with 164.314(a), with a stated time window.
• Support and end-of-support dates for the product and its major components.
• Right to request evidence of the vendor's secure development practices.
• For hosted services: subcontractor disclosure for services in the ePHI path.

Days 61 to 90: prove it and rehearse

13. Map evidence to Security Rule clauses. For each of 164.308(a)(1)(ii)(A), 164.308(a)(1)(ii)(B), 164.308(a)(8) and 164.308(b)(1), list the artifacts that show the work: the tiering, the SBOMs received, the scan results, the decisions and exceptions.
14. Run a tabletop exercise. Pick a realistic scenario (a critical advisory in a common library, or a critical vendor offline for two weeks) and walk through it with the working group. Time how long the first answer takes.
15. Set continuous monitoring. New advisories against components you already know about should reach the owner without anyone running a manual search.
16. Report to leadership. One page: vendors by tier, SBOM coverage for Critical and High tiers, open critical findings in in-house code, device exceptions, and the time-to-answer from the tabletop. Decision table: a new advisory lands

What do we do with devices we cannot patch?

Record them as known risks in the risk analysis, with the compensating controls you apply and the manufacturer's stated plan. Network segmentation, restricted remote access and monitoring are the usual controls. The goal is a documented, dated decision, not a pretense that the device is fixed.

How Safeguard does this

The steps above can be done with spreadsheets, open source tools and discipline. Safeguard puts them in one platform. Every capability named below is GA. Commands and screens are described only as Safeguard's documentation shows them; the commands were not run for this article.

1. Tier vendors and request SBOMs in TPRM (GA). Third-Party Risk Manager keeps a vendor directory with contacts, contracts and SLAs, and risk categorization. Its documented risk tiers match the model above: Critical (SBOM required, quarterly updates), High (required, annual updates), Medium (recommended) and Low (optional). From a vendor's page you choose Request SBOM, select the products, pick a request template, set a deadline and send. Bulk requests go to several vendors at once. The standard template asks for SPDX or CycloneDX and lists required fields.
2. Track responses without a spreadsheet. Each request moves through documented statuses: Sent, Viewed, In Progress, Submitted, Validated and Rejected. Automated follow-ups send a reminder 7 days before the deadline, another at the deadline, and an escalation 7 days after. Vendors can submit by email attachment, a secure upload portal, API or direct integration.
3. Validate and analyze what arrives. When an SBOM is received, TPRM checks the format, checks completeness against required fields, runs a vulnerability scan and notifies the requester. If a submission falls short, you choose Request Revision and say what needs fixing. Vendors' CSAF and VEX documents can be uploaded too (CSAF and VEX upload, GA), so a vendor's "not affected" statement sits next to the component it covers.
4. Monitor critical vendors continuously. TPRM monitoring watches for new vulnerabilities affecting vendor SBOMs, severity changes, exploit availability and CISA KEV additions. You can set alerts for a new critical CVE, a KEV addition, a risk score dropping below a threshold, or an SBOM older than a threshold. Re-scans can run daily for critical vendors, or weekly, monthly or quarterly, and re-assessment can be triggered by contract renewals or security incidents. Scheduled and ad hoc reports export as PDF or Excel for the board pack.
5. Build SBOMs for in-house code (SBOM generation and analysis, SCA with deep transitive dependency scanning, both GA). Connect repositories and registries from the Integrations page, or scan locally with the CLI (GA). The CLI documentation shows these forms; each takes exactly one target:

# A local directory
safeguard scan --dir .

# A container image
safeguard scan --image myregistry.azurecr.io/myapp:v1

# An SBOM you already have, such as one a vendor sent
safeguard scan --sbom sbom.json

# Check an SBOM or VEX document against its specification
safeguard validate sbom.json --strict -o report.json

Results are written as JSON under ./output by default. Per the docs, safeguard scan does not fail on findings and has no severity threshold flag; gating is done by policy gates in the platform.

6. Keep source code on hospital machines with the local runner (GA). Some health systems will not grant a cloud service access to repositories that sit near PHI workflows. The local runner is part of the CLI: you sign in once with a device code, and the machine polls the platform for scan jobs. The docs state that it runs each job locally and uploads only the resulting SBOM and findings, never source code, and that all traffic is outbound HTTPS that the runner opens.
7. Rank findings so engineers fix what matters (vulnerability management with EPSS and KEV enrichment, reachability analysis, both GA). Findings carry EPSS and KEV context, and reachability analysis ranks the vulnerable code paths your application actually calls. That gives the applications team a short list instead of a long one.
8. Set release rules with policies and gates (GA). Policies evaluate SBOMs and generate findings; gates enforce them. Each policy's action decides what a failure does: Block fails the gate, Warn passes it with a warning naming the policy, and Notify passes it and sends a notification. Legitimate exceptions go through a documented request: select the policy and finding, give a business justification, set an expiry date and submit for approval, with an audit trail recorded. With policy outcomes on for your workspace, the docs show a CI job failing on a gate like this:

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

License policies (license compliance, GA) can sit in the same gates.

9. Open fixes as pull requests (autonomous remediation, GA). Griffin can open tested, policy-gated upgrade pull requests, one repository at a time or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs on its own and what waits for a human.
10. Map the evidence to HIPAA clauses (Compliance and GRC suite, GA). The HIPAA Security Rule framework in Compliance maps automated tests to Security Rule controls such as 164.308(a)(1), 164.308(a)(6), 164.308(a)(7) and 164.312(b). Open the framework under Compliance › Frameworks, and its Connectors tab shows which connected systems answer its tests and whether each connection is healthy. Tests run on a schedule or immediately with Run now under Compliance › Tests. The docs are explicit that a passing result is evidence toward a control, not proof that the control is met, and that automated tests are switched on per workspace by the Safeguard team.
11. Deploy where your data rules require. Safeguard runs as SaaS, in a private VPC, on premises or fully air-gapped (GA). The air-gapped deployment documentation describes signed snapshot bundles delivered on a cadence you choose, with no component inside the perimeter calling out. Zero AI mode (GA) runs the platform with no LLM in the loop, and bring your own model (GA) lets you use a model you already approved.

Requirement versus what Safeguard does versus what you still own

What Safeguard does not do

• It does not patch vendor products or devices. When a vulnerable component lives inside an EHR, a hosted clearinghouse or a patient monitor's firmware, the fix comes from that vendor or manufacturer. Safeguard helps you find it, track the vendor's answer and record your decision.
• It does not inventory medical devices on your network. Device discovery and clinical asset management remain with clinical engineering and the tools they use. Safeguard works with the device SBOMs you obtain.
• It does not make vendors respond. TPRM sends requests, reminders and escalations. Whether a vendor delivers depends on your contract and your position at renewal.
• It does not write or sign your risk analysis or BAAs. The Security Officer and counsel own those documents. A passing automated test is evidence toward a control, not proof that the control is met.
• It does not decide clinical trade-offs. Whether to take a device offline, delay an upgrade during a go-live, or accept a risk is a decision for clinical, IT and compliance leaders together.
• It does not replace incident response or backups. Ransomware recovery, downtime procedures and restore testing are separate programs.
• It does not make your organization compliant on its own. Safeguard's own posture is designed for FedRAMP High, and its SOC 2 Type II audit is in progress; neither says anything about your HIPAA compliance.

Common mistakes

• Starting from the CMDB alone. IT's asset list misses departmental purchases and hosted services. Start from contracts, payments and the BAA register.
• Asking every vendor for an SBOM at once. Requests to hundreds of vendors produce a few dozen files nobody reads. Start with Critical and High tiers.
• Accepting a PDF of package names. Ask for SPDX or CycloneDX so the SBOM can be loaded and matched against advisories.
• Treating every finding as urgent. Without EPSS, KEV and reachability, the list is too long to act on, and engineers stop listening.
• Not recording decisions. OCR and auditors ask what you decided and when. A fix with no record looks the same as no fix.
• Treating the Security Rule proposal as final. It is still a proposal. Build to the current rule and watch the agenda.

FAQ

Does HIPAA require hospitals to have SBOMs?

Not by name. The Security Rule requires an accurate and thorough risk analysis and risk management (164.308(a)(1)(ii)(A) and (B)). An SBOM is one of the most direct ways to show that third-party and open source components are covered by that analysis.

Is the 2025 HIPAA Security Rule proposal final?

No. The proposal was published on 6 January 2025 at 90 FR 898. The Fall 2025 Unified Agenda lists final action for July 2027. Until a final rule appears in the Federal Register, nothing in the proposal is binding.

What are recognized security practices under HITECH?

Section 13412 of the HITECH Act, added in January 2021, requires OCR to consider whether a covered entity or business associate had recognized security practices in place for the previous 12 months. The law names NIST standards and the 405(d) approaches among those practices.

Are the HPH Cybersecurity Performance Goals mandatory?

No. They are voluntary goals published by HHS. They are still useful because they are mapped to HICP, NIST controls and CISA's cross-sector goals, which gives boards, auditors and vendors a common reference.

Can a hospital get an SBOM for a medical device?

Often, yes. Section 524B requires manufacturers of cyber devices to give FDA an SBOM that includes commercial, open source and off-the-shelf components. Hospitals can ask for it during purchasing and write the request into the contract.

Which vendors should get SBOM requests first?

The ones whose failure would stop care or revenue, or that hold large volumes of ePHI: typically the EHR, clearinghouse, imaging, pharmacy and integration platforms. Then High-tier vendors such as the patient portal platform and AI documentation tools.

How do we handle a vendor that refuses to provide an SBOM?

Record the refusal in the risk analysis, ask for alternatives (a third-party assessment, a vulnerability disclosure policy, CSAF or VEX statements), and raise the issue at renewal. The decision to keep the vendor is a business decision; the record shows you made it knowingly.

How quickly should we answer "are we affected?" after a major advisory?

No rule sets a number. A useful internal target is a first answer for in-house systems, and a vendor status request, within one business day. Measure your real time in a tabletop.

Most of what this guide asks of a hospital is about seeing and recording risk in software it buys. For the open source dependencies and container images that your own teams build and ship, you can also close the gap between a published fix and a deployed one, which is what the next section describes.

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, and then scan from the terminal. For a health system that does not want repositories near PHI workflows connected to a cloud service, this is the same flow described in step 6 above.

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

The second demo is a real CLI session. After install, safeguard opens the interactive terminal, and the user asks it to fix the lodash CVE in a repository. It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same pattern applies to a portal or research repository with a vulnerable package.

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

The third demo is a real Android session with the mobile app. Work is sent to a computer running the CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. An on-call engineer can approve a fix during an advisory without being at a desk.

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

Quick check

Related reading

• Software supply chain security for medical devices
• Securing EHR software supply chains
• FDA SBOM requirements under section 524B
• HIPAA supply chain evidence for business associates
• EHR integration vendor controls blueprint
• The Shai-Hulud npm supply chain attack explained

Sources

• eCFR: 45 CFR 164.308, Administrative safeguards
• eCFR: 45 CFR 164.314, Organizational requirements
• Federal Register: HIPAA Security Rule to Strengthen the Cybersecurity of ePHI, proposed rule, 6 January 2025
• Reginfo.gov: Unified Agenda entry for RIN 0945-AA22, Fall 2025
• Reginfo.gov: Unified Agenda entry for RIN 0945-AA22, Spring 2025
• GovInfo: Public Law 116-321, recognition of security practices
• GovInfo: 21 U.S.C. 360n-2, ensuring cybersecurity of devices
• HHS: Healthcare and Public Health Sector Cybersecurity Performance Goals
• HHS Cyber Gateway (405(d) and HICP resources)
• CISA: Software Bill of Materials
• CISA: Contec CMS8000 Contains a Backdoor
• CISA: Reported supply chain compromise affecting XZ Utils, CVE-2024-3094
• CISA: Widespread supply chain compromise impacting npm ecosystem
• UnitedHealth Group: updates on Change Healthcare cyberattack, 22 April 2024
• The Record: nearly 6 million people impacted by ransomware attack on Ascension
• Safeguard docs: Third Party Risk Manager
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: TPRM Monitoring
• Safeguard docs: Policies and Gates
• Safeguard docs: HIPAA Security Rule and connectors
• Safeguard docs: CLI usage
• Safeguard docs: Local Runner
• Safeguard docs: Generate SBOM
• Safeguard docs: Air-Gapped Deployment

To try the flows in this guide, download Safeguard at https://safeguard.sh/download and read the documentation at https://docs.safeguard.sh/docs .

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