Patch Dependencies in a 24x7 Clinical Service With Three SREs

A small SRE team keeps an always-on clinical service patched by making patching boring: split routine, urgent and emergency paths, batch low-risk upgrades into a weekly train that three people can review, canary every change with automatic rollback, and track patch lag so the work is visible. HIPAA asks for a tested contingency plan, not a downtime window, so the same pipeline that ships features should ship fixes.

This post is for the SRE who carries the pager for a service clinicians use at 3 a.m., on a team of three that will stay three, watching upgrades slip because every change feels risky.

Key takeaways

• Patching is a reliability problem before it is a security problem. If a dependency bump is scary, the fix is a safer release path, not more courage. NIST SP 800-40 Rev. 4 treats patching as preventive maintenance and recommends phased deployments with canary assets for routine patches.
• HIPAA does not set a patch deadline in the current rule, but it does require a contingency plan and periodic evaluation. 45 CFR 164.308(a)(7) requires backup, disaster recovery and emergency mode operation plans, and 164.308(a)(8) requires evaluation when operations change. A patch process that can break the service and cannot roll back is a contingency planning gap.
• Define three or four paths, not one. Routine (weekly train), urgent (days), emergency (hours) and emergency mitigation (when no fix exists or the fix is broken). Each has its own owner, approval and evidence.
• Batch by risk. One reviewable change per service for patch and minor upgrades; isolate majors and anything touching clinical logic.
• Canary and roll back automatically, on health checks that represent clinical work, not just HTTP 200.
• Measure patch lag by asset importance and vulnerability severity, as SP 800-40 recommends, not as a single "percent patched" number.
• Where Safeguard fits: vulnerability management with EPSS and KEV enrichment (GA), reachability analysis and prioritisation (GA), continuous scanning of connected projects (GA), policies and gates with Block, Warn and Notify actions (GA), notifications to chat and email (GA), and Griffin AI Remediate fix pull requests, single and bulk (GA, ships switched off with every category set to Manual). Safeguard does not deploy, canary or roll back anything, and it does not test clinical workflows.

The situation

The trigger is not an incident. It is the quieter moment when someone in leadership says the hiring plan for next year is flat, and the SRE team realises the backlog of dependency upgrades is not going to be cleared by a fourth person who is never coming.

The service is a clinical application that runs around the clock. Maybe it is a care coordination platform used by hospital nurses, a remote patient monitoring backend that relays device readings to clinicians, or an e-prescribing service that pharmacies call at all hours. Whatever the details, three facts hold:

1. There is no quiet hour. Night shifts, weekend clinics and time zones mean some clinician is always mid-task. A five minute outage at 2 a.m. still interrupts care somewhere.
2. The team is small. Three SREs share on-call, platform work, cost reviews, incident response and the occasional audit request. Dependency upgrades compete with all of it.
3. The dependency tree is large. A typical service carries hundreds of open source packages once transitive dependencies are counted, plus base images and language runtimes. New vulnerabilities land against that tree every week.

A bad week, illustrated: on Monday a high severity advisory lands against a parsing library three levels down in the results service. On Tuesday the fix turns out to need a framework bump that has been stuck for eight months behind a flaky lab interface test. On Wednesday the advisory joins CISA's Known Exploited Vulnerabilities catalog. On Thursday someone pushes the upgrade to every pod at once at the end of a shift, and a serialisation change breaks the HL7 result feed for forty minutes. On Friday leadership asks why a security fix caused an outage, and the team resolves to be more careful, which in practice means slower.

Every step was rational. The result is a team that patches less often, in bigger and riskier jumps. The way out is to change the shape of the work.

The rules behind it

This is general information about the rules and guidance that shape patching for a health tech service, not legal or compliance advice. Your counsel and compliance lead decide how they apply to you.

What HIPAA requires of an always-on service

If your company builds or runs software that creates, receives, maintains or transmits electronic protected health information for a covered entity, you are almost certainly a business associate, and the Security Rule's administrative safeguards in 45 CFR 164.308 apply to you directly. The rule text says these standards apply to "a covered entity or business associate".

Three parts of 164.308 matter most for patching.

Risk analysis and risk management, 164.308(a)(1)(ii)(A) and (B). Both are Required implementation specifications. Risk analysis means an accurate and thorough assessment of risks and vulnerabilities to the confidentiality, integrity and availability of ePHI. Risk management means implementing security measures sufficient to reduce those risks to a reasonable and appropriate level. An unpatched, known exploited vulnerability in a service that handles ePHI is the kind of risk an examiner would expect to see in the analysis, with a management decision attached.

Contingency plan, 164.308(a)(7). The standard requires policies and procedures for responding to an emergency or other occurrence that damages systems containing ePHI, and the rule's own examples include system failure. The implementation specifications are:

Addressable does not mean optional. Under the Security Rule, an addressable specification must be implemented if reasonable and appropriate, or the decision not to, and any alternative, must be documented. For a 24x7 clinical service it is hard to argue that testing your recovery path is unreasonable.

Evaluation, 164.308(a)(8). The standard requires a periodic technical and nontechnical evaluation and, after the initial one, evaluation whenever environmental or operational changes affect the security of ePHI. A major dependency change, a framework upgrade or a new base image is an operational change. You do not need a formal evaluation for every patch, but your process should show that significant changes are assessed and that the assessment is recorded somewhere.

What the current rule does not say. The current Security Rule does not set a number of days within which a vulnerability must be patched. HHS published a notice of proposed rulemaking on 6 January 2025 to strengthen the Security Rule, with comments closing on 7 March 2025. In a Federal Register search on 25 October 2026 we found no final rule replacing it. Treat any specific patch deadline you see attributed to HIPAA as either a proposal or someone's internal policy until a final rule is published, and check the Federal Register yourself before you plan around it.

NIST SP 800-40 Rev. 4: patching as preventive maintenance

NIST SP 800-40 Rev. 4, published April 2022, is the most useful document for a small team designing a patch process, because it is written about the process rather than about any one technology. Its framing is that patching is preventive maintenance, a cost of doing business, and it says plainly that routine patching "is often postponed and neglected".

Three sections map directly onto this post.

• Section 3.3, risk response scenarios. NIST names four: routine patching, emergency patching, emergency mitigation and unpatchable assets. It notes that delaying routine patching makes emergency patching harder, because you must first install the earlier patches the new one depends on. Every SRE who has tried to jump a library three minor versions in one night knows this.
• Section 3.4, maintenance groups. Assets with similar characteristics (outage restrictions, existing mitigations, impact if compromised) share a maintenance plan. NIST suggests defining groups by asset importance, including assets with life-safety impact. A clinical service is a natural group of its own.
• Section 3.5, maintenance plans. For routine patching NIST recommends phased deployments where a small subset of assets acts as canaries before the rollout expands. For emergency patching it recommends the same approach on an accelerated schedule, with a canary period of anywhere from a few minutes to a few hours. For emergency mitigation it says schedules should be set and enforced for both deploying the eventual patch and removing the mitigation. Section 3.5.5 says exceptions should be tracked, monitored and reviewed regularly.
• Section 3.6, metrics. NIST warns that overly simple metrics, such as the percentage of vulnerabilities patched, are not actionable, and shows a notional table that breaks performance down by asset importance and vulnerability severity.

CISA KEV and EPSS: two free prioritisation signals

CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with evidence of exploitation in the wild. It is free and machine readable, and you can use it whether or not you are a federal agency.

The Exploit Prediction Scoring System, maintained by an EPSS special interest group at FIRST, publishes a daily probability that a published CVE will be exploited in the next 30 days. It is also free.

Federal context only: CISA's BOD 26-04, issued 10 June 2026, replaced the older BOD 22-01 and sets risk-based remediation timelines for federal civilian agencies using four factors (asset exposure, KEV status, exploit automation and technical impact) in its Table 1. It does not apply to a private health tech company, and NIST SP 800-40's reference to BOD 22-01's two week deadline is now history. The four factors are still a sensible way to think about urgency, and you can borrow them for your own policy.

NIST SP 800-61 Rev. 3: when patching becomes incident response

NIST SP 800-61 Rev. 3, published April 2025, folds incident response into the NIST Cybersecurity Framework 2.0. It matters here for one reason: SP 800-40 notes that if a vulnerable asset has already been compromised, emergency patching may be part of incident response. Your emergency patch path and your incident response plan should point at each other, with one owner deciding when a patch becomes an incident.

Release engineering: the SRE view

Google's SRE book chapter on release engineering argues for hermetic builds, meaning builds that depend on known versions of tools and dependencies rather than whatever is installed on the build machine. That is the property that makes a dependency patch reproducible and reversible. The SRE workbook chapter on canarying releases describes a canary as a partial, time-limited deployment of a change, evaluated against a control. Its point is that canarying lets the pipeline catch defects with as little impact on the service as possible. Both ideas apply to a dependency bump exactly as they apply to a feature.

Step by step: a patch process three SREs can run

Everything in this section works with whatever CI, deploy and monitoring tools you already have.

Step 1: write down which services are clinical, and how clinical

You cannot pick a patch path without knowing what breaks if the service breaks. Do the applications and data criticality analysis that 164.308(a)(7)(ii)(E) describes, at service level, in one table.

This table is illustrative. Have a clinical or product owner sign off the impact column; the SRE team should not decide alone what clinicians can live without.

Step 2: split routine, urgent and emergency patch paths

This is the core of the process. Write it as a short policy that fits on one page.

The target times are yours to set. HIPAA does not set them today, and copying a number from someone else's policy without the capacity behind it creates a promise you will break. Start with numbers you can meet with three people, measure, then tighten.

Two rules make the paths work:

1. Emergency changes still canary. NIST says even emergency patches benefit from a short canary to confirm the patch is not corrupted and does not break the software. A ten minute canary is better than none.
2. Every mitigation has an end date. SP 800-40 Section 3.5.3 says to set and enforce schedules for both the patch and the removal of the mitigation. A feature flag that disables a vulnerable code path and is never removed becomes permanent technical debt.

To pick a path, ask four questions, borrowed loosely from the factors CISA uses in BOD 26-04 and from SP 800-40's scenarios:

1. Is it known exploited? KEV listed or confirmed exploited moves the finding to emergency for clinical critical services and urgent for the rest.
2. Is it likely to be exploited? A high EPSS score raises a finding one path.
3. Is it reachable and exposed? If your code calls the vulnerable function and the service is reachable from outside your network, raise it one path. If static analysis shows the vulnerable code is not called, it can usually stay on the routine train, with a note.
4. Does a working fix exist? If not, or if the fix breaks the service, the path is emergency mitigation with an expiry date, not "wait".

Write this as a decision table in your runbook so the on-call SRE at 3 a.m. does not have to make a judgment call alone.

Step 3: batch upgrades so three people can review them

Three people cannot review sixty single-package pull requests a week. They can review one or two well prepared changes per service.

The batching rules that work for small teams:

• One batch per service per week. Group every patch and minor upgrade for that service into one change. Reviewers see the full set of moves, and the canary tests them together.
• Keep majors out of the batch. A major version bump of a framework gets its own change, its own reviewer and, for clinical critical services, its own release.
• Keep clinical logic out of the batch. If a dependency is used directly in dosing, unit conversion, result interpretation or anything a clinician acts on, upgrade it alone, with a named reviewer who knows that code.
• Lockfile only, never floating. Every batch is a lockfile change. If your ecosystem allows ranges in manifests, the lockfile is what ships, and the build must use it. This is the hermetic build property from release engineering.
• Rebuild base images on the same train. Operating system packages inside your images age just like application dependencies. Rebuild images from a pinned, updated base on the weekly train.
• Cap the batch size. If a batch grows past what one person can read in thirty minutes, split it. An illustrative rule is twenty package moves per change.

A batch pull request description should follow a fixed template, so reviewers do not have to hunt:

Service: results-delivery
Path: routine (weekly train)
Packages moved: 14 (12 patch, 2 minor, 0 major)
Vulnerabilities closed: 3 (1 high, 2 medium), none KEV listed
Breaking change notes: minor bump of http client changes default timeout; set explicitly in config
Tests run: unit, contract tests against lab interface stub, end to end order-to-result path
Rollback: revert this commit; no schema or data migrations

If the rollback line ever says anything other than "revert this commit", the change does not belong on the routine train.

Run the train on a rota. One SRE drives it each week (open the batches Monday, review Tuesday, merge and canary Wednesday, handle fallout Thursday) and the other two review, so each person drives once every three weeks. Two practices keep review fast:

• Read the changelog for minors and anything clinical, skim for patches. Most patch releases are safe; minors are where defaults change.
• Trust tests you have written, not tests you hope exist. If a service has no end to end test of its clinical path, writing one is the most valuable patching work you will do this quarter.

Step 4: a canary, health check and rollback pattern for a clinical service

The canary is where three people get their confidence back. The goal is that a bad dependency bump reaches a small slice of traffic, is detected by automation within minutes and is rolled back without a human at the keyboard.

Health checks that mean something. HTTP 200 on a health endpoint tells you the process is alive. It does not tell you that lab results are flowing. Define a small set of service level indicators that represent clinical work:

Compare canary to control at the same time, the canarying chapter's central idea; absolute thresholds false-alarm on busy clinic mornings.

Canary sizing. For clinical critical services, start with a small share of traffic or one pod, bake long enough to see real clinical traffic patterns, then widen. NIST suggests multiple canary rounds for larger rollouts. For a 24x7 service, make sure the bake period covers at least one change in traffic shape, such as a shift handover.

Automatic rollback. The deploy system, not a person, should roll back when a canary signal trips. The person gets paged after the rollback, not before. Write down what "rolled back" means for each service: previous image, previous config, and confirmation that no data migration ran.

Data changes are different. If a dependency upgrade changes a schema, a serialisation format or a stored representation, it is not reversible by redeploying the old image. Treat it as a separate, planned change with backups confirmed, which is exactly what 164.308(a)(7)(ii)(A) and (B) are for.

Step 5: test the contingency plan by using it

The cheapest way to satisfy 164.308(a)(7)(ii)(D) for this part of the system is to rehearse rollback on purpose. Once a quarter, during a normal routine train, deliberately roll back a clean canary and confirm the service recovers within your target. Record the date, the service, the time to recover and anything that surprised you. That record is evidence that the plan is tested, and it keeps the rollback path from rotting.

Do the same for emergency mode operation: if rollback fails and the results service is down, your runbook and status page should say what clinicians do.

Step 6: track patch lag and report it

SP 800-40 recommends metrics that break performance down by asset importance and vulnerability severity. For a small SRE team, four measures are enough:

1. Fix-available lag. For each open finding with a fix available, days since the fix was published. Report the median and the worst case, per maintenance group.
2. Time to remediate by path. For findings closed this period, days from detection to production, grouped by path (routine, urgent, emergency).
3. Open KEV-listed findings in clinical critical services. The number should usually be zero. When it is not, each entry needs an owner and a mitigation.
4. Change failure rate for patch changes. Share of patch deployments rolled back. This number tells you whether the canary is working and whether batching is too aggressive.

A one-page monthly report might look like this, with illustrative round numbers:

Do not report "percent of vulnerabilities patched" on its own. SP 800-40 explains why: it hides whether the unpatched ones are on the most important assets. Keep the raw data (finding, detection date, fix date, deploy date, path) in one place you can query; a spreadsheet works for a quarter, after which the data has to come out of your tools automatically.

Step 7: tell clinical leadership what to expect from maintenance

Clinical leadership does not want to hear about lockfiles. They want to know three things: when might the system be slower or briefly unavailable, how will they know, and what should clinicians do.

A short note that works:

Subject: How we keep the clinical platform patched

We update the software components inside the platform every week.
Updates roll out to a small share of users first and are checked
automatically against real clinical activity (orders, results, alerts).
If anything looks wrong, the update is reversed automatically, usually
within minutes, and the on-call engineer is paged.

If an urgent security fix is needed,
we follow the same steps on a faster schedule and post a notice on the
status page. If the platform is unavailable, follow the downtime
procedure in the unit binder; results continue to be available by phone
from the lab.

Replace the downtime procedure with whatever your customers actually use. The point is that "maintenance window" stops meaning "the system will be down for an hour on Sunday", because for a 24x7 service there is no good hour. Your customer contracts may already specify notice periods for planned maintenance, and those win.

How Safeguard does this

Everything above works without Safeguard. This section shows which parts Safeguard can carry for a small SRE team, using only flows from Safeguard's documentation. Every capability below is generally available (GA).

1. Get every service's dependency tree into one inventory. Connect the repositories, or add one step to CI. Safeguard's CI/CD integration (GA) runs safeguard ci scan in a plain shell step on GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, Jenkins, Azure Pipelines or any CI that runs bash and curl. You create a key under Settings › Developer with the scopes scans:trigger and scans:read, store it as SAFEGUARD_API_KEY, and push. Each push becomes a new version of the project named after the branch and commit. If you cannot give a cloud service access to the repository, safeguard ci scan --local reads lockfiles and manifests on the runner and sends only results. SBOM generation in SPDX and CycloneDX formats (GA) and software composition analysis across the full transitive tree (GA) come from the same scan. Pin the CLI version on the install line with SAFEGUARD_VERSION, as the docs recommend, so a CLI release does not change a build unexpectedly.

2. Let continuous scanning re-check what you already shipped. The Vulnerabilities docs say Safeguard performs daily continuous scanning (GA) of all your projects and re-evaluates them when new CVEs are published. That covers the Monday-shipped, Thursday-vulnerable case without a new build.

3. Triage with exploit and reachability signals, not severity alone. Vulnerability management (GA) shows findings in Critical, High, Medium, Low and Exploitable categories, with CVE ID, CVSS, EPSS, whether it is actively exploited, affected component and version, fixed version and reachability for each. Reachability analysis and prioritisation (GA) classifies each finding as Reachable, Conditionally reachable, Unreachable or Unknown, and combines reachability with EPSS, KEV, runtime context and business context into one priority. The docs say you can declare, via policy, which assets are regulated (HIPAA is one of their examples) so findings on those assets rank higher. On the Vulnerabilities page you can filter by severity, EPSS range, exploitable status, fix availability and reachability status, or ask in plain English, for example the docs' own example "Show me critical vulnerabilities in production that are actively exploited". Those filters map directly onto the four path questions above.

4. Encode the patch paths as policies and gates. Policies, gates and guardrails (GA) let you turn the Step 2 table into rules. Go to Settings › Policies, click Create Policy, define conditions with the visual builder or YAML (the docs list vulnerability severity, CVSS score, EPSS score, license, component age and maintenance among the conditions), set the action, and save. Each policy's Action decides what a failure does to the gate:

   • Block: the gate fails. Use it for the emergency path, for example any exploitable critical finding in a clinical critical service.
   • Warn: the gate passes with a warning naming the policy. Use it for the urgent path.
   • Notify: the gate passes and Safeguard sends a notification to the in-app bell, connected chat integrations and email according to each person's preferences. Notify fires when a policy goes from passing to failing and again when new matching issues appear, not on every evaluation, which keeps the noise down for an on-call team.

   To make CI respect the gate, the docs show safeguard ci scan --wait --fail-on-gate <gate>, which exits non-zero when the gate is not Passed or Warning. Policy outcomes are turned on per workspace by Safeguard; if you do not see an Outcome column on the Gates and Policies tables, the docs say to ask your Safeguard contact to turn it on. Gates are evaluated in the platform, not by the CLI.

5. Run exceptions and mitigations with expiry dates. When the emergency mitigation path applies, the policy exception flow records it: click Request Exception, select the policy and finding, give the business justification, set an expiration date and submit for approval. The docs describe a notification to approvers, a decision and an audit trail. On the Vulnerabilities page, Accept Risk also takes an expiration date. That is the SP 800-40 Section 3.5.5 requirement (track and review exceptions) and the 3.5.3 requirement (schedule mitigation removal) in one place.

6. Prepare the weekly batch with fix pull requests. Griffin AI Remediate, part of autonomous remediation (GA), generates fixes and opens pull requests. The docs describe the flow as analysis, solution generation, impact assessment, pull request creation and validation. Bulk AI Remediate lets you select vulnerabilities, click AI Remediate Selected, and Griffin batches compatible fixes and creates one pull request per repository, which lines up with the one-batch-per-service rule in Step 3. Each pull request includes the CVE reference, a description, a summary of changes, breaking change warnings and test results if configured. Griffin classifies breaking change risk as Safe, Minor, Major or Critical. In Settings › AI Remediate you choose whether to require approval before pull requests, whether to run tests before creating them, the breaking change policy and the branch naming convention. Autonomous remediation ships switched off, with every category set to Manual, so nothing is opened or applied until your team enables it and chooses how far it goes. The docs' own advice matches a clinical team's instincts: enable tests, start with safe fixes, review major changes and do not auto-merge breaking changes.

7. Route alerts to where the on-call SRE already is. Notifications (GA) go to Slack, Microsoft Teams, Google Chat and Discord. The Slack card under Integrations › Notification accepts a bot token or an incoming webhook, and the docs recommend a webhook tied to one channel for least privilege. For Teams, read the current docs first: they say the dialog accepts only Microsoft 365 connector webhook URLs today, which Microsoft is retiring, and that Workflows webhook URLs are not accepted yet.

8. Keep scans on your own machines when you need to. The local runner (GA) is built into the Safeguard CLI (GA). It polls the platform for jobs over outbound HTTPS, runs scans locally and uploads only the SBOM and findings, never source code. For a headless runner the docs show safeguard runner start --workspace ./path/to/repo, with safeguard runner status and safeguard runner stop. For a quick local check before you open a batch, safeguard scan builds an SBOM and matches it against vulnerability databases.

9. Deploy, canary and roll back with your own pipeline. Safeguard's job ends at the merged pull request and the gate result. Your deploy system runs the canary, watches the clinical signals and rolls back. The next scan after deploy shows whether the finding closed.

Requirement, what Safeguard does, what you still own

What Safeguard does not do

• It does not deploy, canary or roll back. Safeguard opens pull requests and evaluates gates. Your CI and deploy system ship the change, run the canary and reverse it. If your rollback is broken, Safeguard will not save the night.
• It does not test clinical workflows. Griffin can run your configured tests before creating a pull request, but it cannot know that a dosing calculation or an HL7 mapping is clinically correct. Clinical safety testing and sign-off stay with your team and your clinical owners.
• Fix pull requests need review, and they are off until you enable them. Autonomous remediation ships switched off with every category set to Manual. Even when enabled, the docs recommend reviewing major changes and not auto-merging breaking ones. A pull request with passing tests is a proposal, not a release decision.
• It does not write your HIPAA risk analysis or contingency plan. Safeguard's findings, exceptions and scan history are inputs to those documents. The documents, the decisions in them and their sign-off belong to your compliance lead and leadership.
• It does not patch what you do not build. A vulnerability in a hosted database service, an EHR vendor's interface engine or a medical device's firmware has to be fixed by that vendor. Safeguard covers the open source dependencies and container images in the services you build.
• It does not give you a staffing number. We make no claim about hours saved or people replaced. If you want to justify the work to leadership, build the estimate from your own numbers using the worked example below.
• Teams notifications currently need an existing connector webhook. If your team lives in Teams and has no working connector webhook, use Slack, email or another supported channel until the docs say otherwise.

A worked example you can redo with your own numbers

Illustrative, with round invented numbers. Twenty services each get three single-package upgrades a week, and each takes about 20 minutes between review, merge and watching the deploy: 60 changes and roughly 20 person-hours a week, so most of them wait. Batched weekly, the same moves arrive as 20 changes; at 45 minutes each that is about 15 person-hours. The bigger change is that the canary and automatic rollback do the watching, so time goes into reading changes rather than babysitting deploys. Replace every number with your own before you show it to anyone.

Common mistakes

• One path for everything. If every finding is urgent, nothing is, and the steady upgrades that make emergencies cheap never happen.
• Batching majors with patches. A framework major hidden in a batch of twenty patch bumps is how a routine change becomes an outage.
• Health checks that only check liveness. A process that answers 200 while the result feed is broken will pass every canary.
• Untested rollback. If you have not rolled back on purpose this quarter, assume rollback is broken.
• Reporting percent patched. It hides where the unpatched findings sit. Report by maintenance group and severity.
• Citing a HIPAA patch deadline that does not exist. The current rule sets none. Quoting a proposed rule as law damages trust with the auditors and customers who know better.
• Auto-merging fix pull requests on clinical services. Even when tests pass, a human who knows the service should approve it.

FAQ

How often should a small SRE team patch dependencies in a clinical system?

Weekly for routine upgrades, with faster paths for urgent and emergency findings. A weekly train keeps each change small enough to review and roll back, and it stops the backlog from piling up into risky jumps. NIST SP 800-40 Rev. 4 warns that delaying routine patching makes emergency patching harder.

Does HIPAA require patching within a set number of days?

Not in the current Security Rule. 45 CFR 164.308 requires risk analysis, risk management, a contingency plan and periodic evaluation, but no fixed patch deadline. HHS proposed changes to the Security Rule on 6 January 2025; check the Federal Register for its current status before quoting any deadline.

Can we patch a 24x7 clinical service without a maintenance window?

Usually yes, for dependency upgrades that do not change data. Roll out gradually behind a canary that compares clinical signals against a control, and roll back automatically. Schema and data format changes need a planned change with confirmed backups.

What should a canary check for in a healthcare application?

Signals that represent clinical work: error rates on order and result paths, end to end result delivery latency, interface acknowledgement rates, outbound queue depth and a synthetic transaction through the full clinical path. Compare canary to control at the same time.

How do we decide whether a CVE is an emergency?

Ask whether it is known exploited (CISA KEV), likely to be exploited (EPSS), reachable and exposed in your service, and whether a working fix exists. Known exploited plus a clinical critical service is an emergency; no working fix means emergency mitigation with an expiry date.

How do we report patch lag to leadership?

Report fix-available lag, time to remediate by path, open KEV-listed findings in clinical critical services and the rollback rate of patch changes, broken down by maintenance group. Avoid a single "percent patched" figure.

Should we let a tool automatically merge dependency upgrades?

Not for clinical critical services. Automated pull requests and passing tests save preparation time, but a reviewer who knows the service should approve the merge, and the canary should still run. Safeguard's autonomous remediation ships switched off with every category set to Manual for this reason.

Is a health tech SaaS company covered by the HIPAA Security Rule?

If it creates, receives, maintains or transmits ePHI on behalf of a covered entity, it is typically a business associate, and 45 CFR 164.308 applies to business associates directly. Confirm your status with counsel.

What if a dependency has no fixed version yet?

Use the emergency mitigation path: reduce exposure with configuration, isolation or a feature flag, record it as an exception with an expiry date, and watch for the fix. The options below cover getting a fix sooner.

For a three-person team, the slowest step is often not the deploy but getting a safe version to deploy at all, especially when the fixed release is a major jump or does not exist yet. The options below are how Safeguard approaches that gap; they sit alongside the canary and rollback discipline above, not in place of it.

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 is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal with safeguard, asks it to "fix the lodash CVE in this repo", and shows the assistant reading the finding and advisory, asking before any command that changes something, editing package.json to lodash 4.17.21, and running npm install and npm test with approval before printing a summary and pushing nothing. For an SRE preparing a weekly batch, the same flow is how you would reproduce and check a single risky upgrade locally before it joins the train.

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

The second demo sets up the runner on your own machine, approves it with its device code, and then scans from the terminal. If some clinical services live in repositories you cannot connect to a cloud service, this is how scans run next to the code while only the SBOM and findings reach the platform.

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

The third demo shows the Safeguard desktop app, which the docs describe as the hosted web app paired with a local panel that can reach your filesystem, a local shell and MCP servers. For a small team it puts the Vulnerabilities page, gate results and a local scan in one window.

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

For related reading, see how to canary a dependency fix before full rollout, whether you can patch during a change freeze, supply chain security for SRE teams, and how to keep a maintenance-mode product patched with a skeleton team.

Quick check

Sources

• 45 CFR 164.308, Administrative safeguards (eCFR)
• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning (CSRC)
• NIST SP 800-40 Rev. 4 full text (PDF)
• NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations (CSRC)
• HIPAA Security Rule notice of proposed rulemaking, 6 January 2025 (Federal Register)
• CISA Known Exploited Vulnerabilities Catalog
• CISA BOD 26-04, Prioritizing Security Updates Based on Risk
• FIRST, Exploit Prediction Scoring System
• Google SRE book, Release Engineering
• Google SRE workbook, Canarying Releases
• Safeguard docs, Vulnerabilities
• Safeguard docs, AI Remediate
• Safeguard docs, Policies and Gates
• Safeguard docs, Policy outcomes and actions
• Safeguard docs, CI/CD Integration
• Safeguard docs, Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs, Continuous Scanning
• Safeguard docs, Slack integration
• Safeguard docs, Microsoft Teams integration
• Safeguard docs, Local Runner
• Safeguard docs, Safeguard CLI
• Safeguard docs, Desktop Application

To try the flows above, download Safeguard and start with the Safeguard docs.

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