Medical Device Supply Chain Security: Rules, Incidents and a 90-Day Plan

If you make a medical device that runs software and can reach a network by any route, section 524B of the FD&C Act already requires three things in your premarket submission: a plan to find and handle postmarket vulnerabilities, processes that keep the device and its related systems secure and patched, and a software bill of materials covering commercial, open source and off-the-shelf components. FDA's February 2026 guidance spells out what reviewers expect. The work that makes those three things true belongs to product security, engineering, regulatory and supplier quality together, and a 90-day plan can get a device maker from scattered spreadsheets to evidence it can defend.

This guide covers the software a device maker runs, the rules that apply today, public incidents from the last three years, who owns each part of the problem, and a 90-day plan that works with any tools. Safeguard appears only near the end.

Key takeaways

• Section 524B is law, not guidance. It has applied to premarket submissions for cyber devices made on or after 29 March 2023, and FDA's refuse-to-accept grace period ended on 1 October 2023.
• FDA's current guidance is dated 3 February 2026. It replaced the June 2025 edition, ties cybersecurity to the Quality Management System Regulation (QMSR), and asks for a machine-readable SBOM plus each component's level of support and end-of-support date.
• The QMSR took effect on 2 February 2026. It incorporates ISO 13485:2016 by reference, so design verification, configuration management and purchasing controls now carry your cybersecurity evidence.
• The SBOM baseline moved in July 2026. CISA's 2026 Minimum Elements replaced the 2021 NTIA list, while FDA's February guidance still cites the NTIA document. Build to the newer fields and keep the FDA addendum fields as well.
• "Connect to the internet" is read broadly. FDA counts network, Wi-Fi, cellular, Bluetooth, magnetic inductive links and hardware ports such as USB as the ability to connect.
• Recent incidents are about components you did not write. A patient monitor with hidden functionality, a backdoored compression library, an OpenSSH regression and a self-replicating npm worm all arrived through firmware, operating system packages or app dependencies.
• The plan below needs no product. Inventory and classify in the first 30 days, put triage and gates in place by day 60, and rehearse and package evidence by day 90.
• Where Safeguard fits (all GA): SBOM generation and analysis (GA), software composition analysis with EPSS and CISA KEV enrichment (GA), reachability analysis and prioritisation (GA), policies and gates with Block, Warn and Notify actions (GA), license compliance (GA), CSAF and VEX upload (GA), Portal for SBOM publishing and sharing (GA), Third-Party Risk Manager (GA), the Compliance and GRC suite (GA), Trust Center (GA), autonomous remediation through Griffin pull requests (GA, ships switched off with every category set to Manual), the CLI and local runner (GA), and Zero AI mode with on-prem and air-gapped deployment (GA).

The situation

Device makers rarely start this work on a quiet afternoon. It usually lands as one of five triggers, and each comes with a clock.

• A submission date. A 510(k), De Novo or PMA for a connected device is due, and the cybersecurity section has to hold a plan, process evidence and an SBOM that matches the build being submitted.
• An FDA request. A reviewer asks for an SBOM addendum, a justification for a component near end of support, or the assessment behind a known exploited vulnerability you listed as not applicable.
• A public advisory. CISA publishes an ICS medical advisory, or a widely used open source library is found compromised, and hospital customers start asking within hours which of your models and firmware versions are affected.
• A hospital procurement review. A health system asks for a machine-readable SBOM, a disclosure contact and end-of-support dates before it signs.
• A design change. Engineering upgrades the embedded Linux base, and regulatory must decide whether the change affects cybersecurity.

A bad week is a hand-built SBOM that no longer matches the firmware in the field, a Bluetooth stack whose supplier nobody can name, and one person who knows the answers. This guide is about making that week shorter.

This guide summarises public rules and guidance. It is not legal, regulatory or audit advice, and your regulatory affairs team and counsel decide how the rules apply to your devices.

What software a medical device maker runs

The SBOM for one product is rarely one file. A modern connected device is a system, and FDA's guidance talks about the "medical device system" for that reason: the device, the software that talks to it, and the infrastructure that updates and services it. Here is what typically sits in scope.

Two points matter for scope. FDA's guidance treats firmware and programmable logic as software, so microcontroller code counts. And section 524B speaks of "the device and related systems", so the update service and the pairing app are in the story a reviewer will ask about.

The regulations and frameworks that apply

US rules lead here, because FDA is the regulator a US device maker answers to. Each row below was checked against the primary text on 25 October 2026.

Section 524B in plain terms

Subsection (b) of the statute gives four duties to the sponsor of a cyber device submission:

1. Submit a plan to monitor, identify and address postmarket cybersecurity vulnerabilities and exploits "in a reasonable time", including coordinated vulnerability disclosure.
2. Design, develop and maintain processes that give reasonable assurance the device and related systems are cybersecure, and make updates and patches available on a "reasonably justified regular cycle" for known unacceptable vulnerabilities, and "as soon as possible out of cycle" for critical vulnerabilities that could cause uncontrolled risks.
3. Provide an SBOM, including commercial, open source and off-the-shelf software components.
4. Comply with any other requirements FDA sets by regulation.

Subsection (c) defines a cyber device as one that includes software validated, installed or authorized by the sponsor, has the ability to connect to the internet, and contains technological characteristics that could be vulnerable to cybersecurity threats. All three criteria must be met.

How FDA reads "ability to connect to the internet"

The February 2026 guidance, section VII.B, reads the connectivity test broadly. FDA says a device that can connect, whether intentionally or not, has the ability to connect. Its illustrative list includes network, server or cloud connections; radio frequency links such as Wi-Fi, cellular and Bluetooth; magnetic inductive communication; and hardware connectors capable of connecting to the internet, such as USB and ethernet. A footnote gives the example of a device serviced over USB: even a brief connection counts. If your team has been treating a device as out of scope because it "only talks Bluetooth to a phone", that assumption deserves a second look with regulatory.

What FDA wants in the SBOM

Section V.A.4(b) of the guidance asks for machine-readable SBOMs that meet the minimum elements in the 2021 NTIA document. On top of those elements, for each component, FDA asks for:

• the level of support the component's maker provides (actively maintained, no longer maintained, abandoned), and
• the component's end-of-support date.

You can put those two fields in the SBOM or in a separate addendum. If you cannot provide SBOM information, FDA asks for a justification. The guidance also asks you to identify all known vulnerabilities in the device and its components, including those in CISA's Known Exploited Vulnerabilities catalog, and to explain how each was found so the reviewer can judge whether the assessment was thorough enough.

The guidance goes further on the customer side. Section VI.A recommends that labeling give users an SBOM in a machine-readable format, kept current on a continuous basis, plus information about end of support and end of life for the device and its components. In other words, the SBOM is not just a submission artefact. Hospitals are expected to receive it too.

The SBOM baseline changed in July 2026

FDA's guidance was issued in February 2026 and points to the 2021 NTIA minimum elements. In July 2026, CISA, NSA, FBI and international partners published the 2026 Minimum Elements for a Software Bill of Materials, which CISA says updates and replaces the NTIA list. CISA's announcement names new requirements for component hash, license, SBOM tool name and SBOM generation context.

There is no conflict to resolve so much as a gap to close. A practical approach is to produce SBOMs that meet the 2026 CISA fields, which cover more than NTIA did, and to keep FDA's two extra fields (level of support and end-of-support date) in an addendum. That satisfies a reviewer reading the guidance and a hospital security team reading CISA. Confirm the exact field list against the CISA PDF before you change your templates.

Testing expectations

Section V.C lists the testing FDA expects evidence of, including security requirement testing, threat mitigation testing, vulnerability testing (with reference to ANSI/ISA 62443-4-1) including fuzz testing, attack surface analysis, vulnerability chaining, software composition analysis of binary executable files, static and dynamic code analysis including checks for hardcoded and default credentials, and penetration testing with stated tester independence, scope, duration and methods. For third-party test reports, FDA asks for the original report.

Supplier controls

The guidance's discussion of third-party components (section V.A.4) is where supplier quality enters. FDA notes that some suppliers will not grant source code access, and suggests manufacturers consider adding to their purchasing controls the acquisition of source code should purchased software reach end of support before the device does. Source code escrow is described in a footnote. Under the QMSR, purchasing controls come from ISO 13485, so this is a quality system activity, not just a security preference.

Your customers' rules and the standards that help

HIPAA binds covered entities and business associates, not device makers as such. The January 2025 proposal to amend the Security Rule would require regulated entities, including your hospital customers, to keep a technology asset inventory and network map; it was not final as of 25 October 2026, so check the HHS regulatory agenda. IEC 81001-5-1:2021 gives you a secure lifecycle structure for health software that maps onto what FDA asks for. Check FDA's Recognized Consensus Standards database for the recognition status of any standard you cite in a submission.

Real public incidents from the last three years

These incidents are drawn from official advisories and records. The aim is to show where risk entered, not to judge the organisations involved. Where a source does not say something, neither do we.

Contec CMS8000 patient monitors

On 30 January 2025, FDA issued a safety communication about cybersecurity vulnerabilities in Contec CMS8000 and Epsimed MN-120 patient monitors. FDA said the software included a backdoor, that a device could be remotely controlled by an unauthorised user or made to malfunction, and that once connected to the internet the monitor sent patient data outside the health care environment. CISA's advisory ICSMA-25-030-01, last revised 25 February 2025, lists CVE-2024-12248 (out-of-bounds write, CVSS v3.1 9.8), CVE-2025-0626 (hidden functionality), CVE-2025-0683 (privacy leakage of plaintext patient data to a hard-coded public IP address) and CVE-2025-1204. CISA noted, per FDA's recommendation, that users should remove the devices from their networks, and that the device may be relabeled and sold by resellers.

FDA updated the communication on 2 July 2025 to say the manufacturer had released a patch that removes networking functionality entirely, leaving the devices for local monitoring only, and that facility staff rather than patients should install it. FDA said it was not aware of related incidents, injuries or deaths at the time of the original notice.

The record shows the behaviour lived in firmware, was reported by outside researchers after deployment, affected a device sold under more than one name, and was fixed by removing a capability. Each point maps to a 524B duty: knowing your firmware, a disclosure route, tracking every product name a build ships under, and a working field update path.

XZ Utils and OpenSSH

CISA's 29 March 2024 alert advised downgrading XZ Utils to an uncompromised version such as 5.4.6 Stable. The OpenSSH CVE record, published 1 July 2024, describes a regression of an older issue that an unauthenticated remote attacker may be able to trigger. Both live in the kind of embedded Linux images device makers ship. The question each time was the same: which firmware, gateway, build container or service laptop image carries the affected version? Teams with a per-build SBOM answered it with a search.

The npm worm

On 23 September 2025, CISA described a widespread compromise of the npm registry by a self-replicating worm known as Shai-Hulud. CISA said it searched compromised environments for credentials, exfiltrated them, and used stolen npm access to publish compromised versions of more than 500 packages. CISA recommended reviewing lock files including nested dependencies, searching artifact repositories for cached copies, pinning to versions released before 16 September 2025, rotating developer credentials and enforcing phishing-resistant MFA. A device maker's exposure here is usually the companion app, the clinician portal and the build tooling, all of which are "related systems" in 524B terms. Our explainer on the Shai-Hulud attack covers the mechanics.

The personas who own the problem

No single role owns this. The table names the usual owners, what each needs, and when. Titles vary; the jobs do not.

Two patterns matter more than titles. Product security and regulatory must agree on one triage vocabulary, because FDA's guidance separates "known unacceptable vulnerabilities", patched on a justified regular cycle, from "critical vulnerabilities that could cause uncontrolled risks", patched out of cycle as soon as possible. And supplier quality must own the binary components from chipset makers and OTS suppliers, because nobody else can get their SBOMs, support dates or source code terms into a contract.

Step by step: a 30, 60 and 90-day plan

This plan works with spreadsheets and open source tools as well as with a platform. Each phase ends with something a reviewer or customer could inspect.

Days 1 to 30: know what you ship

1. List every marketed product and version. Include every name a build ships under (OEM and relabeled variants), the firmware and app versions in the field, and the related systems each one depends on (cloud services, gateways, service tools).
2. Classify each product against 524B(c). Record the three criteria and your reasoning for each, using FDA's illustrative connectivity list. Have regulatory sign the record.
3. Generate an SBOM from each build, not from memory. Use the build pipeline or the image itself. Keep one SBOM per released version, stored with the release, in SPDX or CycloneDX.
4. Add the FDA fields. For every component, record level of support and end-of-support date. Where the supplier will not say, record "unknown" and open a supplier action.
5. Match against known vulnerabilities, including KEV. Run every SBOM against public vulnerability data and mark KEV entries. Record how each finding was found.
6. Name owners. Fill in the persona table above with real names for each product line.
7. Stand up disclosure intake. Publish how researchers and customers report vulnerabilities, and route reports to a monitored queue with an acknowledgment target.

A template for step 4, which you can use as an SBOM addendum:

Days 31 to 60: make it a process

1. Write the triage procedure. For each new vulnerability, decide whether it could cause uncontrolled risk to patients. Use the decision table below and record each decision.
2. Define and justify the regular patch cycle. Pick a cadence your update mechanism and validation can support, and write down why it is reasonable for the device's risk profile.
3. Define the out-of-cycle path. Who decides, how a fix is built and validated, how hospitals are told, and how the update reaches the field.
4. Put gates in the pipeline. Fail builds that add a component with a known exploited vulnerability, a disallowed license, or an abandoned upstream, with a documented exception route that names an approver and an expiry.
5. Ask suppliers for SBOMs. Send a standard request with format, required fields and a deadline. Add support level, end-of-support notice and source code access terms to contract renewals.
6. Refresh the threat model and architecture views. Make sure related systems (cloud, app, update server) appear, because the guidance's architecture views include updatability and patchability.
7. Plan the testing evidence. Map your current testing to the list in section V.C, including software composition analysis of binaries, fuzzing and penetration testing with stated independence.

A triage decision table for step 1:

Days 61 to 90: prove it works

1. Run a tabletop. Replay a real advisory, such as the XZ Utils alert, against your SBOMs. Time how long it takes to answer "which products and versions are affected" and "what do we tell hospitals".
2. Assemble a submission-ready package. For one product, collect the 524B plan, process evidence, SBOM with addendum, known vulnerability assessments, test reports and labeling SBOM, ordered to match the guidance's sections.
3. Publish customer SBOMs. Give hospitals a current, machine-readable SBOM per version through a controlled channel, with end-of-support statements.
4. Tie it into the QMSR. Make SBOMs part of configuration management, add cybersecurity impact to the change assessment form, and route vulnerability findings that meet your criteria into CAPA.
5. Plan for legacy devices. For products near end of support, write down what support remains, what you will tell customers, and when.
6. Set three metrics. Time to answer "are we affected", count of marketed versions with an unassessed KEV entry, and median time from fix available to fix shipped.

A one-page 524B evidence checklist:

• Cyber device classification record per product, signed by regulatory
• Postmarket vulnerability plan with coordinated disclosure procedures
• Triage procedure separating controlled and uncontrolled risk
• Written, justified regular patch cycle and out-of-cycle procedure
• Machine-readable SBOM per marketed version, with support level and end-of-support date
• Known vulnerability list with KEV status and how each was found
• Testing evidence mapped to guidance section V.C
• Supplier SBOMs and support commitments on file
• Customer-facing SBOM and end-of-support information in labeling

How Safeguard does this

This section shows how the plan runs in Safeguard, using only what Safeguard's offering and documentation describe. Every capability named here is generally available (GA).

1. Connect the sources for each product (GA). In the web app, Integrations lets you connect GitHub, GitLab, Bitbucket or any Git repository, container registries (Amazon ECR, Docker Hub, GCP, OCI registries), Hugging Face models, and uploads of manifests, APKs, SBOMs and CSAF or VEX files. Each connection becomes a project with a name, version and branch or tag, so one firmware release, one app release and one cloud service release can each map to a project.

2. Generate SBOMs per release (GA). SBOM generation and analysis produces SPDX and CycloneDX output. The generation options include the project version (auto-detected from Git tags), the branch or tag, and whether to include development dependencies. Safeguard's docs say it rescans every project daily for newly disclosed vulnerabilities, and you can add triggers on push, on a schedule, or on release when new tags are created.

3. Scan where the code lives, if it cannot leave (GA). Device source code is sensitive. The Safeguard CLI and local runner scan on your own machine. The docs show:

# Install the CLI
curl -fsSL https://cli.safeguard.sh/install | bash

# Scan a local directory, writing results under ./output
safeguard scan --dir .

# Scan an SBOM you already produced in your firmware build
safeguard scan --sbom sbom.json

The docs say a scan from the interactive terminal while signed in uploads the SBOM and findings to the platform, and your source never leaves the machine. They also note that safeguard scan does not fail on findings; gating is done by policy gates. We did not run these commands for this post. For firmware built outside a supported package ecosystem, the second command is the route: produce the SBOM in your build and bring it in.

4. Match vulnerabilities and rank them (GA). Software composition analysis inventories direct and transitive dependencies, and vulnerability management enriches findings with EPSS and CISA KEV. Reachability analysis and prioritisation ranks the vulnerable code paths your application actually calls, which gives the product security lead a defensible order of work. It does not replace the patient-harm judgment in your triage table.

5. Record exploitability with VEX (GA). CSAF and VEX upload lets you bring in advisories and VEX documents. Safeguard's compliance frameworks include a CycloneDX VEX framework whose scan requirements check, among other things, that components carry package URLs, exact versions and hashes so VEX statements can be matched to the right artefact.

6. Set gates that stop risky components (GA). Policies evaluate SBOMs and produce findings; gates enforce them. Policy conditions in the docs include vulnerability severity, CVSS score, EPSS score, license, component age and maintenance (no abandoned packages). Each policy's action is Block (the gate fails), Warn (the gate passes with a warning) or Notify (the gate passes and a notification is sent). When a team needs an exception, the docs describe a request with a business justification and an expiry date that goes to approvers, with an audit trail. In CI, the docs show this GitHub Actions step, which we did not run:

- name: Safeguard scan
  env:
    SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
    SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
  run: |
    set -eu
    curl -fsSL https://cli.safeguard.sh/install | bash
    "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

The docs list --fail-on-gate all as the option to fail the job on a policy gate instead of a severity threshold.

7. Check licenses (GA). License compliance parses SPDX expressions and supports policy on license types, which matters for code shipped inside a device you sell.

8. Open fix pull requests, under your control (GA). Autonomous remediation lets Griffin open tested, policy-gated pull requests that move a dependency to a fixed version, on one repository or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs on its own. For a regulated device, keep it on Manual for firmware and use the pull requests as engineering input to your normal design change and verification process.

9. Request SBOMs from suppliers (GA). Third-Party Risk Manager handles SBOM requests to vendors, one at a time or in bulk, with a standard template that sets SPDX or CycloneDX format, required fields and a deadline. Requests move through Sent, Viewed, In Progress, Submitted, Validated or Rejected, with automatic reminders before and after the deadline. Received SBOMs are checked for format and completeness and scanned for vulnerabilities, and a rejected submission goes back to the supplier with the corrections needed.

10. Share SBOMs with hospitals (GA). Portal, meaning here the SBOM publishing and sharing product rather than the free entry tier, lets you share SBOMs with named recipients at View, Download or Full permission, create links with expiry, download limits and password protection, require NDA acceptance, track who accessed what, and revoke access immediately. It also offers a branded customer portal. Its compliance checks score each SBOM against minimum element fields such as supplier, component identifier, version, dependencies and hashes, with gap analysis and exportable reports.

11. Map evidence and publish posture (GA). The Compliance and GRC suite holds frameworks, controls, evidence, tests, risks and questionnaires. Trust Center publishes a public posture page, and nothing goes live until you publish it.

12. Keep code and models in your environment (GA). Zero AI mode runs with no LLM in the loop, or you bring your own model, and Safeguard deploys as SaaS, private VPC, on-prem or fully air-gapped.

A summary of how the plan maps:

What Safeguard does not do

• It does not decide whether your device is a cyber device or what FDA will accept. Classification, risk acceptability and submission content are regulatory decisions your team signs.
• It does not judge patient harm. Reachability and EPSS help order the work. Whether a vulnerability could cause uncontrolled risk to a patient is a clinical and engineering judgment documented in your quality system.
• It does not analyse closed firmware binaries for you. Safeguard's documented inputs are source repositories, container images, AI models, manifests, APKs, SBOMs and CSAF or VEX files. For a chipset stack delivered as a binary, you need the supplier's SBOM or a binary analysis tool, and FDA's guidance asks for software composition analysis of binary executables as part of testing.
• It does not invent end-of-support dates. Policy conditions can flag abandoned packages and old components, but a supplier's end-of-support date has to come from that supplier.
• Its documented SBOM compliance checks use the NTIA field list. The Portal docs describe checks against NTIA minimum elements. If you are building to CISA's 2026 fields, check the extra fields against the CISA document yourself.
• It does not ship your update. Fix pull requests stop at your repository. Verification, validation, release and field deployment stay in your design control and update process.
• It does not write your submission or your labeling. It gives you evidence to draw from, not the regulatory narrative.
• It does not perform penetration testing or fuzzing of the device. Those are separate activities FDA expects, often with independent testers.

Common mistakes

• Treating "it only uses Bluetooth" as out of scope. FDA's illustrative list counts radio links and service ports as the ability to connect.
• Building the SBOM by hand for the submission. A spreadsheet SBOM drifts from the build within one release. Generate it from the build and store it with the release.
• Leaving out related systems. Section 524B covers the device and related systems. The companion app, the cloud back end and the update server all belong in the threat model and, where relevant, the SBOM set.
• Skipping the two FDA addendum fields. Level of support and end-of-support date are what reviewers look for after the minimum elements.
• Listing a KEV entry as "not applicable" without evidence. FDA asks how each vulnerability was found and assessed. Record the configuration or reachability evidence.
• Supplier contracts with no support terms. If a chipset stack reaches end of support before your device does, you need a plan written before that day.

FAQ

Is an SBOM legally required for medical devices in the US?

Yes, for cyber devices. Section 524B(b)(3) of the FD&C Act requires sponsors of premarket submissions for cyber devices to provide an SBOM covering commercial, open source and off-the-shelf components. It has applied to submissions made on or after 29 March 2023.

What makes a device a "cyber device"?

The statute uses three criteria, all of which must be met: it includes software validated, installed or authorised by the sponsor; it has the ability to connect to the internet; and it has characteristics that could be vulnerable to cybersecurity threats. FDA reads connectivity broadly, including Wi-Fi, cellular, Bluetooth, magnetic inductive links and ports such as USB and ethernet.

What is the latest FDA cybersecurity guidance for medical devices?

"Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions", issued 3 February 2026. It supersedes the edition issued 27 June 2025 and includes a section on section 524B.

What fields does FDA want in a medical device SBOM?

A machine-readable SBOM meeting the NTIA minimum elements, plus, for each component, its level of support and end-of-support date. These can sit in the SBOM or an addendum. FDA also asks for known vulnerabilities, including those on CISA's KEV catalog, and how they were found.

Do the CISA 2026 SBOM minimum elements apply to medical devices?

They are guidance for all software producers, published 29 July 2026, and CISA says they replace the 2021 NTIA list. FDA's February 2026 guidance still cites NTIA. Building to the CISA fields and keeping FDA's two extra fields covers both readers.

How fast does a device maker have to patch?

The statute sets two speeds: a reasonably justified regular cycle for known unacceptable vulnerabilities, and as soon as possible out of cycle for critical vulnerabilities that could cause uncontrolled risks. It gives no number of days, so your plan must justify your cadence.

Does section 524B apply to devices already on the market?

It applies to new premarket submissions. According to FDA's FAQ, for a previously authorised cyber device it applies when a change requires a new premarket submission. Your postmarket monitoring and customer obligations still depend on knowing what marketed devices run.

How does the QMSR change cybersecurity work?

The QMSR took effect 2 February 2026 and incorporates ISO 13485:2016. FDA's guidance ties cybersecurity to design verification and validation, configuration management and purchasing controls, so SBOMs and security testing become quality system records.

The steps in this guide shorten the time from "we know about a vulnerability" to "a fixed build is ready for verification". Where a fix exists upstream or must be made without waiting for one, the options below apply to the open source components inside your firmware, apps and cloud services.

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 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. For a device team, the same pattern applies to a companion app or portal dependency: the change arrives as a reviewable edit that then goes through your own verification.

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

The second demo sets up the local runner on your own machine, approves it with a device code, then scans from the terminal. This is the route for firmware and SaMD source that should not leave your network, since the scan happens where the code is.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. A product security lead could use the same connection to ask questions across projects during an advisory, with access limited to the tools you allow.

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

Quick check

Related reading

• FDA SBOM requirements under section 524B for medical device manufacturers
• Medical device firmware SBOM and coordinated vulnerability disclosure
• Software supply chain security for medical devices
• Buyer's guide: selecting an SBOM tool for medical device compliance
• SBOM for embedded systems

Sources

• 21 U.S.C. 360n-2, Ensuring cybersecurity of devices (FD&C Act section 524B), Legal Information Institute
• FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (guidance page)
• FDA, Cybersecurity in Medical Devices guidance document, issued 3 February 2026 (PDF)
• FDA, Cybersecurity in Medical Devices Frequently Asked Questions
• FDA, Quality Management System Regulation (QMSR)
• FDA, Cybersecurity Vulnerabilities with Certain Patient Monitors from Contec and Epsimed: FDA Safety Communication
• CISA, ICSMA-25-030-01 Contec Health CMS8000 Patient Monitor (Update A)
• CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM)
• CISA bulletin announcing the 2026 Minimum Elements for an SBOM, 29 July 2026
• CISA, Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094
• CISA, Widespread Supply Chain Compromise Impacting npm Ecosystem
• CVE Program record, CVE-2024-6387
• HHS, HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (NPRM), Federal Register via GovInfo
• IEC 81001-5-1:2021, IEC Webstore
• Safeguard Docs, Generate SBOM
• Safeguard Docs, Policies and Gates
• Safeguard Docs, CLI usage
• Safeguard Docs, GitHub Actions
• Safeguard Docs, TPRM SBOM Requests
• Safeguard Docs, Portal Sharing
• Safeguard Docs, Portal Compliance
• Safeguard Docs, CycloneDX VEX framework
• Safeguard Docs, Trust Center setup

To try the flow on your own code, 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.