The First 72 Hours of a Dependency Incident at a Digital Health Company

When a library you run in production is being exploited, the first 72 hours belong to four decisions, not one: where are we exposed, what do we contain now, could this be a breach of health data under HIPAA or the FTC Health Breach Notification Rule, and who hears what, how often. Running a vulnerable library is not, on its own, a breach. Whether it becomes one depends on evidence you start collecting in hour one, so the security leader's job is to set the cadence, start the clock log and protect the record while engineering ships the fix.

This post is for the CISO at a US digital health company that handles protected health information (PHI) for hospitals and payers as a business associate, runs a consumer health app outside HIPAA, or both. The plan works with any tools; Safeguard enters near the end.

This is not legal advice. It describes the shape of the HIPAA and FTC rules from their published text; your counsel makes the breach determination and owns the notification decisions.

Key takeaways

• Separate the vulnerability from the breach. An exploited library becomes a reportable breach only if health information was acquired, accessed, used or disclosed without permission. Your 72 hours are about finding out and writing down how.
• The clock may already be running. Under 45 CFR 164.410(a)(2) a business associate's breach is treated as discovered on the first day it is known, or would have been known with reasonable diligence. The FTC rule is similar (16 CFR 318.3(c)). Log when you knew what.
• Run two analyses if you live in both worlds. HIPAA covers the data you handle for covered entities. The FTC Health Breach Notification Rule can cover your direct to consumer app, and it does not apply to the extent you act as a business associate.
• Fix the cadence before the content. Executive updates every four hours on day one, then twice a day. Customers get a holding statement within hours and a fixed next update.
• Patching is not the end. When a flaw is exploited in the wild, also check whether you were compromised, as CISA's BOD 26-04 requires of federal agencies for the most urgent cases.
• Safeguard capabilities covered (all GA): software composition analysis and vulnerability management with EPSS and CISA KEV enrichment; reachability analysis and prioritisation; in-app Griffin search across your projects; AI Remediate and autonomous remediation with Griffin fix pull requests (autonomous remediation ships switched off, every category set to Manual); mitigations with approvals and audit history; policies and gates (Block, Warn, Notify, with approval through exceptions); CSAF and VEX upload; the CLI, MCP server, and the desktop and mobile apps.

The situation

A widely used open source library, the kind that sits three levels deep under your web framework or your HL7 and FHIR integration service, gets a critical advisory and lands on CISA's Known Exploited Vulnerabilities (KEV) catalog. Your engineers confirm that you run it.

Then the questions arrive in parallel.

• Your general counsel asks whether this is a breach, and whether the clock on any notice has started.
• Your CEO wants a status every few hours, and wants to know whether to call the two largest hospital customers before they call you.
• Hospital and payer security teams send emails and questionnaires: are you affected, is our data involved, when will you be patched, send us your incident contact.
• Engineering wants a decision: take a service offline, apply a workaround or push an emergency release.

A bad week looks like this. Someone tells a hospital "no patient data was affected" before anyone has looked at a log. The fix misses a forgotten integration worker. Nobody wrote down when the team first knew, so a month later nobody can say when "discovery" happened. Access logs roll over on normal retention while everyone patches.

A good week is one where, a month later, you can show a regulator, a hospital auditor and your board what you knew, when, what you decided and why.

The rules behind the first 72 hours

Three sets of rules shape these 72 hours: the HIPAA Breach Notification and Security Rules for business associates, the FTC Health Breach Notification Rule for consumer health products outside HIPAA, and NIST and CISA incident guidance. State breach laws and your contracts sit on top; counsel adds them.

Is a vulnerable library a HIPAA breach?

Not by itself. The definition at 45 CFR 164.402 turns on what happened to the information, not on what software you run. A breach is "the acquisition, access, use, or disclosure" of PHI in a manner not permitted under the Privacy Rule "which compromises the security or privacy" of that PHI.

Two consequences follow for your first 72 hours.

First, a vulnerable component is a security risk, and possibly a security incident. HIPAA defines a security incident at 45 CFR 164.304 as "the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations." Note the word attempted: failed exploitation attempts can count. The Security Rule at 164.308(a)(6)(ii) requires you to identify and respond to suspected or known security incidents, mitigate harmful effects where practicable, and "document security incidents and their outcomes."

Second, once there is evidence that PHI was accessed or acquired by someone who should not have it, the rule flips the default. Under paragraph (2) of the 164.402 definition, an impermissible use or disclosure "is presumed to be a breach" unless the covered entity or business associate shows a low probability that the PHI has been compromised, based on a risk assessment of at least four factors:

1. The nature and extent of the PHI involved, including the types of identifiers and the likelihood of re-identification.
2. The unauthorized person who used the PHI or to whom the disclosure was made.
3. Whether the PHI was actually acquired or viewed.
4. The extent to which the risk to the PHI has been mitigated.

And 164.414(b) puts the burden of proof on you: the covered entity or business associate must be able to show that notifications were made, or that the use or disclosure was not a breach. If you conclude "no breach", you need records that prove it. The three narrow exclusions in the definition (good faith workforce access, inadvertent internal disclosure, and disclosure to someone who could not retain the data) rarely fit an outside attacker.

The duty to notify attaches to unsecured PHI, meaning PHI not rendered unusable or unreadable by the methods in HHS guidance. Be careful here: if the exploited component runs inside your application, with its access to decrypted data, encryption at rest may not help. Counsel and your forensic lead decide that on evidence.

When does a business associate's notice duty start under 164.410?

If you are a business associate, your duty runs to the covered entity, your hospital or payer customer, not directly to patients or HHS. Under 45 CFR 164.410:

• Trigger. Following discovery of a breach of unsecured PHI, you notify the covered entity (164.410(a)(1)).
• Discovery. A breach is treated as discovered on the first day it is known to you or, by exercising reasonable diligence, would have been known. You are deemed to know if any employee, officer or other agent knows, other than the person committing the breach (164.410(a)(2)).
• Timing. Without unreasonable delay and in no case later than 60 calendar days after discovery, unless a law enforcement delay under 164.412 applies (164.410(b)).
• Content. To the extent possible, each affected individual's identity plus other information the covered entity needs for its own notices, given at the time or promptly as it becomes available (164.410(c)).

Sixty days is the ceiling, not the target. And the Security Rule at 164.314(a)(2)(i)(C) requires your business associate agreement (BAA) to make you "report to the covered entity any security incident of which it becomes aware, including breaches." Many BAAs set a far shorter window for security incidents. Pull every BAA for the affected product in hour one and write the shortest window on the whiteboard.

The covered entity then has its own duties: notice to individuals (164.404), to the HHS Secretary (contemporaneous for 500 or more individuals, an annual log for fewer, under 164.408) and, for large breaches, to media (164.406). The quality of your information decides how hard their job is, which is why hospitals email on day one. More in when a business associate must tell a covered entity about a breach.

When does the FTC Health Breach Notification Rule apply, and what changed in 2024?

A consumer app for sleep, fertility, mental health or diet that people download directly is often outside HIPAA. The FTC's Health Breach Notification Rule at 16 CFR Part 318 may apply instead.

The scope line matters most. Under 318.1(a), the rule applies to vendors of personal health records, PHR related entities and third party service providers. It "does not apply to HIPAA-covered entities, or to any other entity to the extent that it engages in activities as a business associate." One company can be a business associate for its hospital product and a vendor of personal health records for its consumer app. Map each affected product to a regime before drafting anything.

The FTC finalised amendments on 26 April 2024, published on 30 May 2024 (89 FR 47054) and effective 60 days later, to make clear the rule covers health apps outside HIPAA. In the current text:

• Health care services or supplies (318.2) now includes "any online service such as a website, mobile application, or internet-connected device" that tracks conditions, medications, symptoms, fitness, fertility, sleep, mental health, diet and more. A covered health care provider definition was added.
• Breach of security (318.2) is unauthorised acquisition of unsecured PHR identifiable health information, now expressly including acquisition "as a result of a data breach or an unauthorized disclosure." Unauthorised access is presumed to be acquisition unless the entity has reliable evidence otherwise.
• Notice methods and content were expanded, including electronic notice and naming third parties that acquired the information.
• Timing (318.4): notice to individuals and to media without unreasonable delay and no later than 60 calendar days after discovery. For 500 or more individuals, the FTC must be notified contemporaneously with the individual notices. For fewer than 500, a log may be submitted annually, within 60 days of the end of the calendar year.
• Discovery (318.3(c)): the first day the breach is known or reasonably should have been known to any employee, officer or agent.

That presumption puts the same premium on logs as HIPAA's 164.414(b).

What NIST and CISA add

NIST SP 800-61 Rev. 3 (April 2025) recasts incident response as a CSF 2.0 Community Profile. Several outcomes map onto these 72 hours:

• RS.MA-01: execute the plan with relevant third parties; designate an incident lead.
• RS.AN-03 and RS.AN-08: establish what happened and validate the magnitude, including indicators of compromise.
• RS.AN-06 and RS.AN-07: record investigation actions and preserve the integrity and provenance of records and data.
• RS.CO-02, RS.MI-01 and RS.MI-02: notify stakeholders, contain and eradicate.
• RC.CO-03 and RC.CO-04: update senior leadership regularly, follow contract rules for sharing with suppliers, and follow your breach notification procedures.

CISA's KEV catalog lists vulnerabilities known to be exploited in the wild. Binding Operational Directive 26-04 (10 June 2026) replaced BOD 22-01 and binds federal civilian agencies, not private companies, but it is a useful benchmark. It sets remediation timelines from KEV status, exploit automation, technical impact and asset exposure, and for the most urgent cases pairs a three day timeline with "forensic triage" to assess whether the system is already compromised. Patching closes the door; you still check whether someone walked through it.

HHS's 405(d) program, now at the HHS Cyber Gateway, publishes the Health Industry Cybersecurity Practices (HICP), a shared vocabulary for hospital security teams.

Step by step: the 72 hours, with or without any particular tool

The plan assumes a mid-sized company with a small security team and an on-call rotation. Adjust the hours; keep the order.

Hour 0 to 1: declare, assign, start the log

1. Declare an incident even if you do not yet know whether you are exploitable. Name one incident lead (security) and one engineering lead.
2. Open the incident log. Timestamped, append only. First entries: advisory date, KEV date, when anyone in the company first saw it, when you confirmed presence. This is your discovery record under 164.410(a)(2) and 318.3(c).
3. Bring counsel in now and ask how they want the investigation structured. Do not decide breach or no breach in this hour.
4. Freeze log deletion. Extend retention on every log source for affected services: edge and firewall, application, database audit, identity provider and cloud control plane logs. It is the cheapest decision with the largest payoff.

Hour 1 to 4: how do you confirm exposure across every product and environment?

Work outward from the inventory you already have, then verify against what is actually running.

1. Search the inventory. If you keep software bills of materials (SBOMs) or a dependency inventory, search it for the package name across every project and version. Include transitive dependencies; the library you are worried about is rarely a direct dependency.
2. Check what is deployed, not just what is in the repository. A repository on main may already be fixed while production runs a container image built three weeks ago. Scan the images actually running, by digest, in each environment.
3. Do not forget the edges. Integration workers, interface engines, scheduled jobs, admin tools, data pipelines, and any on-premises agents you ship to hospitals, which customers ask about first and teams forget first.
4. Record version and path. For each hit, write the product, service, environment, image digest or build, component version, and the dependency path that brought it in.
5. Classify exposure. For each hit: is the service internet facing, internal or air-gapped; does it process PHI or PHR identifiable health information; is the vulnerable code path used in your configuration.
6. Check the advisory's preconditions. Many critical library flaws need a specific feature, parser or configuration to be exploitable. Write down which preconditions apply to you and who confirmed it.

This exposure register becomes the backbone of every update and customer answer.

Illustrative example with invented entries.

Hour 2 to 6: decide containment

Containment is a business decision with clinical consequences: taking down an intake API can delay care, leaving it up can expose PHI. Decide explicitly with the CEO or delegate and log the reasoning.

Do not rebuild a possibly compromised host before preserving it; you destroy the evidence you need under 164.414(b). A firewall rule is containment, not a fix.

Hour 4 to 24: investigate, fix, and start the breach analysis

1. Hunt for exploitation. Search preserved logs for the advisory's indicators and unusual behaviour from before the advisory date onwards; many flaws are exploited before disclosure. Engaging a forensic firm is a normal step under RS.MA-01, not an admission.
2. Ship the fix for every confirmed exposure, highest risk first: internet facing plus PHI plus reachable.
3. Start the breach risk assessment document for each product, even if you expect the answer to be "no breach". For HIPAA products, structure it around the four factors in 164.402. For FTC products, structure it around whether there was unauthorised acquisition and what reliable evidence you have that there was not. Leave conclusions blank until the evidence is in.
4. Check your BAAs and consumer terms for notice windows and named contacts.

Hour 24 to 48: verify and narrow

1. Rescan what is running, not what you think is running, and confirm the fixed version in each environment.
2. Close the side doors. Make sure a new build cannot reintroduce the vulnerable version from a lockfile, a base image or a cached artifact. Add a pipeline gate.
3. Update the breach assessment with what the hunt found. If there are indicators of access to PHI, counsel owns notification; your job is complete facts, fast.

Hour 48 to 72: hand off from incident to record

1. Decide with counsel whether the investigation supports a "no breach" conclusion, a breach conclusion, or a need for more time. If more time, set the next decision date in writing.
2. Write the interim incident summary: timeline, exposure register, containment and fixes, investigation findings so far, open items.
3. Move to recovery cadence: daily executive updates, and the next customer update on a fixed date.
4. Schedule the post-incident review for one to two weeks out, when the facts are settled.

What goes in an executive status update, and how often?

The CEO's request is reasonable. The mistake is meeting it with ad hoc messages that each say something slightly different. Fix cadence and format in hour one.

Cadence. Every four hours during waking hours on day one, plus an immediate message if one of the trigger events below happens. Twice a day on day two. Daily from day three until closure. NIST's RC.CO-03 puts regular senior leadership updates on recovery status into the incident response outcomes for major incidents.

Out of cycle triggers: evidence of exploitation or data access, taking a customer facing service offline, a regulator inquiry, media interest, or a slipped fix timeline.

Template. Keep it to one screen.

INCIDENT [ID]  Update [n]  [date, time, time zone]
Status: [Investigating | Contained | Fixed, monitoring | Closed]

1. What we know
   - Component and advisory: [name, version range, advisory ID, KEV listed yes/no, date]
   - Exposure: [x] services affected, [y] internet facing, [z] process PHI or health data
   - Exploitation evidence so far: [none found | indicators under review | confirmed on ...]

2. What we did since the last update
   - [containment step, time]
   - [fix deployed to ..., time]

3. Decisions needed from you
   - [e.g. approve taking service X offline for 2 hours]

4. Customer and regulatory position
   - Customers contacted: [list or count], next update promised for [time]
   - Breach determination: not yet made; counsel reviewing; next decision point [time]

5. Next update: [time]

Never write a conclusion the evidence does not support ("no data was accessed"); write what you found and how far you have looked. Keep the breach determination line in every update, even when it says "not yet made", so the decision stays with a process, not whoever replies first.

What do hospital and payer customers need to hear, and when?

Covered entities need to know whether their data or users are affected, what you are doing, and when they will hear next. Their own notification clock depends partly on what you tell them.

Within the first business day: a holding statement to every customer of an affected product, not only those who asked, from a named security contact.

Subject: [Company] security update: [advisory or library name]

We are aware of [advisory ID], a vulnerability in [library], which is being
actively exploited. We have confirmed that [product] uses this library.

What we have done so far:
- [time]: began investigation under our incident response plan
- [time]: applied [containment step] to [product] in production
- [fix status]

What we know about your data: our investigation is ongoing. We will tell you
promptly, and in line with our agreement with you, if we find that your data
or your users were affected.

Next update: [date, time, time zone], or sooner if anything changes.
Security contact for this incident: [name, email, phone]

Follow-ups on the promised schedule, even when nothing has changed. Silence after a holding statement reads as concealment.

On request, technical detail: affected versions, whether their tenant runs one, what you changed, and whether anything you ship into their environment needs their action.

What not to send: a "no impact" letter before the investigation supports it, a formal breach notice before counsel decides, or a list of every CVE in the product. If a customer reads its BAA differently, route it to counsel.

For more on wording, see what to tell hospitals when a library you use has an advisory.

Which records should be kept from hour one?

Each record answers a question a hospital auditor, HHS's Office for Civil Rights, the FTC or your board will ask later. Start them in hour one.

The Security Rule requires you to document security incidents and their outcomes (164.308(a)(6)(ii)) and to retain that documentation for six years from creation or from when it was last in effect, whichever is later (164.316(b)(2)(i)). Ask counsel about privilege and labelling before you start. For the longer term, see adding software dependencies to your HIPAA risk analysis.

How Safeguard does this

Safeguard does not run your incident, decide on breach or send notices. It shortens and documents the parts of the 72 hours that depend on knowing which components you run, where, whether the vulnerable code is reachable, and whether a fix shipped and stayed shipped. Every capability below is GA. Commands come from docs.safeguard.sh and were not run for this post.

1. Know where the library is before you are asked

Safeguard's software composition analysis and vulnerability management (GA) build a full transitive inventory of your projects, including container layers, and match it against NVD, GitHub Security Advisories, OSV, CISA KEV and vendor bulletins, with EPSS scores. Per the Vulnerabilities docs, connected projects are re-evaluated when new CVEs are published, so a KEV listing shows up against affected projects without anyone starting a scan.

In the ESSCM Vulnerabilities tab, the Exploitable category marks known active exploitation. Each finding shows CVSS, EPSS, the affected component and version, the fixed version and reachability, and you can filter by exploitable status, component, fix availability and reachability.

For the hour one question, use Search (GA), Griffin powered natural language search across your SBOMs, components and vulnerabilities. Type the package name or CVE ID, or ask "Which projects have exploitable vulnerabilities?". Component results list the projects where each is used, and results export as JSON, CSV or PDF: your hour one snapshot for the incident log. Search covers processed scan data only, a reason to scan before an incident, not during it.

For anything not connected, such as a production image or an SBOM, the CLI scans one target at a time, as the CLI usage docs show:

# A container image
safeguard scan --image nginx:latest

# An SBOM you already have (SPDX or CycloneDX, detected automatically)
safeguard scan --sbom sbom.json

# A local directory
safeguard scan --dir .

Results land as JSON, including vuln.json, under ./output. safeguard scan does not fail on findings: it exits 0 when the scan ran, 1 when the command failed, and 2 when results were written but the vulnerability scan did not run. Gating happens in the platform. Scanning from the signed in interactive terminal (/scan .) uploads the SBOM and findings, never your source.

2. Rank exposure by reachability, exploitation and data

Reachability analysis and prioritisation (GA) answers "is the vulnerable path used?" with more than a best guess. The docs describe static analysis (a call graph from source, lockfile and bytecode), dynamic analysis (a runtime collector recording what actually loads in production) and configuration analysis. Findings are classed Reachable, Conditionally reachable, Unreachable or Unknown, and Unknown is treated as potentially reachable, not suppressed.

These combine with EPSS, KEV, runtime and business context into a priority score. In a health setting, context labels can include a PHI data class, and policy can mark assets as regulated under HIPAA so their findings rank higher; reachable plus KEV listed plus production sits at the top. The docs say quality varies by language and is weakest with reflection, dynamic dispatch and data driven flaws. Use it to order work and document why a service is lower priority, not as sole proof of safety.

3. Fix with pull requests, not tickets

AI Remediate (GA) is how a finding becomes a pull request. Per the docs, from a single vulnerability you click AI Remediate, review the proposed changes and click Create Pull Request. For several at once, select them and choose AI Remediate Selected; Griffin batches compatible fixes into one pull request per repository. Each pull request carries the CVE reference, a description, the changes made, any breaking change warning (rated Safe, Minor, Major or Critical) and test results if configured.

Autonomous remediation (GA) is the hands-off version, and it ships switched off: every category starts at Manual until an administrator turns on the master toggle. Settings › AI Remediate controls automatic creation for safe fixes, required approval, tests first and breaking change handling. During an incident, keep a human reviewing every merge; the defaults support that.

4. Record workarounds, accepted risk and "not affected" decisions properly

Mitigations, part of vulnerability management (GA), record what does not get a code fix in 72 hours. On a finding in the Vulnerabilities tab, Add Mitigation offers Risk Acceptance, False Positive, Workaround Applied and Not Applicable. The form requires a justification, approver and scope, and takes evidence and, for risk acceptances, an expiry. Every action is logged on the History tab, and Reports › Mitigations exports PDF, CSV or Excel.

"Vendor workaround applied to the intake API at 14:20, approved by the CISO" becomes a Workaround Applied mitigation with evidence, not a chat message. Risk acceptances expire with advance notice, so a 2 a.m. decision does not quietly become permanent.

If you or a supplier issue a Vulnerability Exploitability eXchange (VEX) statement that a product is not affected, CSAF and VEX upload (GA) brings it in (CSAF 2.0, CycloneDX VEX, OpenVEX and the CSAF VEX profile, through Integrations, filtered by Upload). Before sending a VEX document to a hospital, the CLI can check it:

safeguard validate sbom.json
safeguard validate ./sboms --recursive

The docs say safeguard validate checks CycloneDX and SPDX SBOMs and VEX documents in CSAF and OpenVEX form. Writing the VEX statement, and deciding that a product is truly not affected, stays your job.

5. Stop the vulnerable version from coming back

Policies and gates (GA) close the side door. In Settings › Policies you create a policy with the visual builder or YAML, set its conditions (for example severity, CVSS or EPSS score) and choose its action. A failed policy can Block the gate, Warn while letting it pass, or Notify while letting it pass. When a team needs a temporary exception, they request one against the specific policy and finding with a business justification and an expiry date; approvers decide, and the exception is recorded in the audit trail. Active mitigations exclude a vulnerability from gate failures, and expired ones do not.

To make a CI job fail when a gate fails, the Policies and Gates docs show this command, with policy outcomes on for your workspace:

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

6. Approve fixes and commands from wherever the incident lead is

The Safeguard desktop app (GA) for macOS, Windows and Linux pairs the web app with a local panel for scans, a terminal for allowlisted commands, MCP and tasks. The Safeguard mobile app (GA) for iOS and Android can send work to a computer running the Safeguard CLI and approve each command on the phone with Allow once, Allow for turn or Deny. Since CLI v11.10.0 the CLI asks before any command that changes something, not before every command. An on-call engineer can start the fix at night while every change still needs a human approval.

If your team works through an AI assistant, the Safeguard MCP server (GA) lets Claude or another assistant query findings and projects with the permissions you grant. Safeguard is listed in Claude's connector directory as a community connector.

7. Keep the timeline for the post-incident review

Per the Continuous Scanning docs, each asset keeps a timeline of scans: when each ran, what triggered it, and which findings were added or resolved. That answers "when did the vulnerable version appear here, and when did it leave?" With mitigation, exception and pull request history, it is the component side of your evidence pack.

The 72 hours, mapped

What Safeguard does not do

• It does not decide whether a breach occurred. The HIPAA four factor assessment and the FTC rule's acquisition analysis are legal determinations made by your counsel on evidence. Safeguard can show that a component was present, reachable and fixed; it cannot tell you whether PHI was accessed.
• It does not see data access. Safeguard scans components, images, SBOMs and code. It does not read your database audit logs, identity provider logs or application access logs, and it is not a forensic tool. Hunting for exploitation and establishing what an attacker touched needs your logging stack and, often, a forensic firm.
• It does not send notices. Notices to covered entities, individuals, HHS, the FTC, media or state regulators are yours, written with counsel. Safeguard sends product notifications to your team's channels, not regulatory notices.
• It does not merge or deploy fixes on its own by default. Autonomous remediation ships switched off, every category set to Manual. Even when you enable it, pull requests should be reviewed and tested, and deployment remains your pipeline's job.
• It only sees what it scans. A vendor's hosted service, appliance firmware or software you never connect stays outside its view.
• It does not write your VEX conclusions. It takes in and validates VEX documents; deciding that a product is not affected, and standing behind that statement, is your call.

Common mistakes

1. Answering "are we breached?" on day one. The honest answer on day one is almost always "we do not know yet, here is when we will". Saying no early creates a correction later.
2. Treating the advisory date as the discovery date. Discovery for notification purposes is about the breach, and depends on when your people knew or should have known. Log your own timeline from your own first knowledge.
3. Letting logs expire. The most common evidence failure is routine retention deleting the logs you needed, while the team is busy patching.
4. Rebuilding before preserving. Replacing a possibly compromised container or host destroys the evidence that could support a "no breach" conclusion.
5. Missing the second regime. A company that is a business associate for one product and a personal health record vendor for another runs one analysis and forgets the other.
6. Ignoring the BAA's security incident clause. The regulation's 60 day ceiling is for breaches. Your contract may require security incident reports much sooner, including attempts.
7. Closing the incident at "patch merged". Merged is not deployed, and deployed today is not guaranteed next month. Verify the running version and gate against reintroduction.

FAQ

Is running a vulnerable library a HIPAA breach?

No. Under 45 CFR 164.402 a breach is an impermissible acquisition, access, use or disclosure of PHI that compromises it. A vulnerable library is a risk, and exploitation attempts may be a security incident under 164.304. Once there is evidence PHI was impermissibly accessed, a breach is presumed unless a four factor risk assessment shows a low probability of compromise.

How long does a business associate have to notify a covered entity of a breach?

Under 164.410(b), without unreasonable delay and no later than 60 calendar days after discovery, unless a law enforcement delay applies. Your business associate agreement may require faster reporting, especially of security incidents, so read it in the first hour.

Does the FTC Health Breach Notification Rule apply to my health app?

It can, if the app is outside HIPAA and is a personal health record or a PHR related entity under 16 CFR Part 318, which since the 2024 amendments expressly reaches websites, mobile applications and connected devices that track health information. It does not apply to HIPAA covered entities, or to you to the extent you act as a business associate. Ask counsel to map each product.

How often should a CISO update the CEO during a dependency incident?

A fixed cadence works better than ad hoc updates: every four hours during day one, twice on day two, daily after that, plus an immediate message on trigger events such as evidence of data access or a decision to take a service offline. Use the same template each time.

What should we tell hospital customers on day one?

That you are aware of the vulnerability, whether their product uses the component, what you have done so far, that the investigation is ongoing, when the next update will come, and who to contact. Do not state that no data was affected until the investigation supports it.

Should we patch first or investigate first?

Both, in parallel, with one rule: preserve before you rebuild. Contain and fix as fast as safely possible, but snapshot any service where exploitation is suspected and extend log retention before the change goes out.

Do we need a forensic investigation if we patched quickly?

If the flaw was exploited in the wild and you ran it on an exposed service handling health data, run at least a targeted check for compromise. BOD 26-04 calls this forensic triage for federal agencies, and the HIPAA and FTC presumptions make evidence of no access valuable.

How long should incident records be kept?

The HIPAA Security Rule requires covered entities and business associates to retain required documentation, which includes documentation of security incidents and their outcomes, for six years from creation or from when it was last in effect, whichever is later (164.316(b)(2)(i)). Your contracts and counsel may set longer periods.

When the fix is not a version bump

Sometimes the exploited library has no fixed release on day one, or the fix sits in an upstream project that moves slower than your 72 hour clock. The block below explains the options for closing that gap, and it is the same block we publish on every post.

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 Android session with the Safeguard mobile app: you send work to a computer running the Safeguard CLI and approve the command on the phone with Allow once, Allow for turn or Deny. At night, an engineer can start the fix while each change still needs approval.

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

The second demo shows Claude connected to the Safeguard MCP server with OAuth, and how you choose which Safeguard tools Claude can use. During an incident, a security leader can ask an assistant which projects carry the affected component, within the permissions granted.

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

The third demo is a real Safeguard CLI session: install, run safeguard and ask it to "fix the lodash CVE in this repo". It reads the finding and 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, then shows /permissions, /model and /scan. The change is made and tested locally, and a person decides what ships.

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

To try it on your own code, download Safeguard from https://safeguard.sh/download and read the docs at https://docs.safeguard.sh/docs .

For the engineer's side of the same incident, see the first hour after a platform flags a critical dependency flaw and the incident response playbook for a compromised dependency.

Quick check

Sources

• eCFR: 45 CFR Part 164 Subpart D, Notification in the Case of Breach of Unsecured PHI (164.400 to 164.414)
• eCFR: 45 CFR 164.304, Security Rule definitions
• eCFR: 45 CFR 164.308, Administrative safeguards
• eCFR: 45 CFR 164.314, Organizational requirements
• eCFR: 45 CFR 164.316, Policies, procedures and documentation requirements
• eCFR: 45 CFR 164.530, Administrative requirements
• eCFR: 16 CFR Part 318, Health Breach Notification Rule
• FTC: FTC Finalizes Changes to the Health Breach Notification Rule (26 April 2024)
• NIST SP 800-61 Rev. 3 publication page
• NIST SP 800-61 Rev. 3 (PDF)
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: Minimum Requirements for Vulnerability Exploitability eXchange (VEX)
• FIRST: Exploit Prediction Scoring System
• HHS 405(d): HHS Cyber Gateway
• Safeguard docs: ESSCM Vulnerabilities
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: AI Remediate
• Safeguard docs: Mitigations
• Safeguard docs: Search
• Safeguard docs: Policies and Gates
• Safeguard docs: CSAF/VEX Upload
• Safeguard docs: Continuous Scanning
• Safeguard docs: CLI Usage
• Safeguard docs: Desktop Application
• Safeguard Gold Open Source

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