Legacy medical applications need secure update pipelines, not patch delay

At a glance

What this is: This is an analysis of why postmarket medical applications need more secure update processes, with SBOMs, dependency tracking, and mirrored libraries at the centre of the fix.

Why it matters: It matters to security and identity practitioners because regulated software change depends on controlled access, auditable pipelines, and governance patterns that also underpin secure IAM and NHI operations.

👉 Read Kusari's guidance on securing postmarket medical software updates

Context

Legacy medical software creates a governance gap when organisations treat validation overhead as a reason to defer change. In regulated environments, that inertia leaves applications exposed to dependency risk, supply-chain drift, and slower remediation even as threat activity keeps rising. The article's primary focus is the update problem for medical applications, with a clear secondary identity angle in the access controls and audit logging needed to run secure build and deployment pipelines.

The core issue is not that medical software should change for novelty's sake. It is that software which processes patient records, device data, and clinical workflows cannot remain secure if the release process itself is fragile, opaque, or dependent on uncontrolled developer access. For identity teams, the lesson is familiar: when privileged access to build systems and artefact stores is not governed, every downstream control becomes harder to trust.

Key questions

Q: How should security teams secure update pipelines for regulated medical applications?

A: Use centralised source, build, and deployment systems with tightly scoped access, build signing, audit logging, and dependency governance. The goal is to make every release traceable and repeatable, so validation becomes a controlled process rather than a reason to freeze updates indefinitely.

Q: Why do SBOMs matter for legacy software maintenance?

A: SBOMs reveal what is actually inside a build, including transitive dependencies that are easy to miss in older codebases. That visibility lets teams map new vulnerabilities to affected products quickly and avoid guessing which applications need urgent attention.

Q: What breaks when privileged access is not continuously governed?

A: When privileged access is not continuously governed, standing privilege persists, dormant accounts remain usable, and the attack surface expands across human and machine identities. In practice, that creates a larger blast radius for credential theft and a weaker ability to prove who had access, when, and why. The result is operational drift, not just security exposure.

Q: Who should own vulnerability triage for medical application dependencies?

A: Security, engineering, and quality teams should share ownership, but the decision should be driven by exploitability evidence and release impact. VEX and SBOM data help define which findings are actionable, which lowers noise and keeps accountability tied to the actual shipped code path.

Technical breakdown

Why regulated software updates stall in medical environments

Medical software is often trapped by validation burden. In regulated settings, even a small code change can trigger re-validation, documentation, and approval work that slows release cycles and creates a strong incentive to defer updates. That delay is manageable only when dependencies are stable and threat exposure is low. Once vulnerable libraries, insecure build practices, or changing regulatory requirements enter the picture, the cost of inaction grows faster than the cost of controlled change. The practical challenge is building a release model that treats validation as a repeatable control, not a reason to freeze the software.

Practical implication: establish a release process that can absorb smaller changes continuously rather than forcing large, risky update batches.

How SBOMs, dependency tracking, and VEX reduce supply-chain blind spots

A software bill of materials gives teams a structured inventory of components, including transitive dependencies that are otherwise easy to miss. When that inventory is generated at build time, vulnerability monitoring can map newly disclosed issues to affected products quickly. VEX then adds context by stating whether a known vulnerability is actually exploitable in the shipped code path. Together, SBOM and VEX shift security from guesswork to evidence-based triage, which is especially important in legacy applications where source code ownership, library provenance, and runtime reachability may not be straightforward.

Practical implication: generate SBOMs automatically and pair them with VEX so remediation decisions are tied to actual exploitability.

Why secure build pipelines matter for medical software governance

The build and deployment pipeline becomes part of the control plane for the application. Centralised source control, build systems, and release tooling with strong access controls and audit logging reduce the risk of shadow changes, untracked artefacts, and unmanaged dependencies. This is where identity governance matters most. Privileged access to code repositories, signing keys, package mirrors, and deployment systems should be tightly scoped and recorded. Without that, the security team cannot reliably prove what was built, who changed it, or whether the artefact shipped to customers matches the reviewed code.

Practical implication: treat pipeline access as privileged access and enforce auditability for every build, sign, and release action.

Threat narrative

Attacker objective: The attacker aims to exploit software supply-chain weakness to reach regulated healthcare environments through trusted application updates or unmanaged dependencies.

1. Entry occurs through unvetted software dependencies or weakly controlled build pipelines that allow risky code into the release process.
2. Escalation follows when a vulnerable component is shipped repeatedly because the organisation lacks timely dependency monitoring and exploitability context.
3. Impact is delivered through exposed patient-facing, clinical, or device-management applications that can undermine confidentiality, integrity, or availability.

NHI Mgmt Group analysis

Validation inertia has become a security control failure, not just a delivery delay. In regulated medical software, the incentive to avoid updates can leave known weaknesses in place for too long. That creates a predictable exposure window where attackers benefit from stable, unpatched dependencies while defenders wait for approval. The governance mistake is treating slow change as safety when it can actually preserve risk.

SBOM without lifecycle governance is only partial visibility. An inventory is useful only when teams can connect component data to dependency feeds, exploitability context, and release decision-making. The real value comes from using SBOMs to drive prioritisation, not from treating them as compliance artefacts. Practitioners should align this with supply-chain controls in NIST CSF and secure software lifecycle expectations.

Secure medical release pipelines are also identity systems. Centralised code, build, and deployment platforms depend on privileged access, service accounts, and audit trails. That puts IAM and PAM into the middle of medical software assurance, especially where build signing, repository access, and release approvals are concerned. The named concept here is validated release latency, the gap between a known fix and the time it takes to safely ship it. Teams should shorten that gap with governed access and repeatable controls.

Internal mirrors reduce procurement-style trust in public libraries. Pulling dependencies directly from public repositories turns the build process into a trust decision at runtime. Mirroring vetted packages internally creates a control point for review, approval, and provenance tracking. In regulated environments, that is not just a supply-chain improvement, it is a governance prerequisite for medical software that must be both safe and maintainable.

What this signals

This topic signals that regulated software programmes are moving toward continuous governance of change, not occasional approval gates. For identity teams, the parallel is clear: build and release systems now behave like high-value identity infrastructure, so access control, auditability, and service-account governance need the same rigour as production systems.

Validated release latency: the time between identifying a fix and safely shipping it becomes a measurable security risk in regulated software. Teams that cannot shorten that interval will keep paying a hidden tax in exposure, rework, and remediation backlog.

For practitioners

• Build a controlled release pipeline for regulated software Centralise source control, build, and deployment systems, then restrict access to a small set of named roles with full audit logging. Include build signing, artefact provenance, and change approval records so every release can be traced end to end.
• Generate SBOMs automatically at build time Create an SBOM for every build and store it with the release artefact so downstream teams can identify affected components immediately when a vulnerability is disclosed. Use the SBOM as the starting point for dependency monitoring, not as a compliance afterthought.
• Pair vulnerability data with VEX statements Maintain VEX documentation that explains whether a disclosed vulnerability affects the shipped code path. This reduces noise in remediation queues and helps clinical, quality, and security teams focus on exploitable exposure rather than theoretical risk.
• Mirror approved open source dependencies internally Block direct pulls from public repositories for production builds and require developers and automation to use an internal vetted mirror. Review and approve new libraries before they enter the mirror so the build process stays reproducible and controlled.

Key takeaways

• The main risk is not simply old code, but a release model that makes secure change too hard to sustain.
• SBOMs, VEX, and dependency monitoring only work when they are tied to controlled build access and repeatable release governance.
• Medical software teams should reduce validated release latency so patching, provenance, and auditability improve together.

Key terms

• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
• Vulnerability Exploitability Echange: A machine-readable way of saying whether a known vulnerability is actually exploitable in a specific product or environment. It helps security teams reduce noise by prioritising issues that affect deployed code paths, rather than assuming every published CVE needs the same response.
• Validated release latency: Validated release latency is the delay between identifying a necessary software fix and safely shipping that fix through a regulated approval process. It reflects how much friction exists between security intent and actual delivery, and it can become a material risk factor when delays preserve known exposure.
• Secure development environment: A secure development environment is a controlled set of tools, access policies, and audit mechanisms used to create and release software. It reduces the chance of unauthorised changes, untracked dependencies, and weak provenance in production artefacts.

What's in the full article

Kusari's full article covers the operational detail this post intentionally leaves for the source:

• Concrete examples of how medical manufacturers can organise secure development environments for regulated software
• Step-by-step guidance for generating SBOMs at build time and using them in dependency monitoring workflows
• Practical handling of VEX documents when a vulnerability exists but the shipped code path is not exposed
• How internal mirrors of open source ecosystems can standardise vetting and reduce supply-chain risk across a portfolio

👉 The full Kusari article covers secure development, SBOM generation, VEX handling, and internal dependency mirroring in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle controls. It gives security practitioners a structured way to connect privileged access, auditability, and lifecycle governance across modern programmes.