Notifications
Clear all
Topic starter
19/08/2026 3:31 pm
TL;DR: Legacy medical applications are difficult to update because validation, approval, and supply-chain controls slow change, according to Kusari. The security problem is not only patch backlog but the absence of repeatable build, dependency, and release governance that lets regulated software evolve safely.
NHIMG editorial — based on content published by Kusari: securing legacy medical applications for postmarket safety and resilience
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Pair vulnerability data with VEX statements Maintain VEX documentation that explains whether a disclosed vulnerability affects the shipped code path.
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
👉 Read Kusari's guidance on securing postmarket medical software updates →
Legacy medical apps: what secure update pipelines change for teams?
Explore further
19/08/2026 4:14 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Legacy medical applications need secure update pipelines, not patch delay
