TL;DR: Medical device submissions need vulnerability context, not just component lists, and RunSafe Security says the FDA is beginning to expect VEX alongside SBOMs so reviewers can judge exploitability, not merely count CVEs. SBOM governance now has to prove risk disposition continuously, or review and remediation will drift apart.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on RunSafe Security's blog post: Medical device SBOMs are no longer enough on their own, and VEX is becoming the practical evidence layer that explains exploitability and reviewable risk.
Why it matters: IAM, NHI, and security teams should read this as a shift from inventory-driven compliance to disposition-driven governance, where each disclosed component needs a defensible status and lifecycle owner.
Context
Software bills of materials are inventory records, not risk judgments. In regulated environments, that distinction matters because a list of components does not show whether a known vulnerability is reachable, mitigated, or irrelevant in a specific product. The same problem appears in identity governance when organisations track assets but fail to prove the access or exposure state that reviewers actually need.
Vulnerability Exploitability eXchange adds that missing judgment layer by stating whether a known issue in an SBOM-listed component affects the product in practice. For medical device manufacturers, that turns cybersecurity documentation into a lifecycle control rather than a one-time filing. The starting position here is increasingly typical of regulated software, not an edge case.
Key questions
Q: What should teams do first when an SBOM lists a vulnerable component?
A: Teams should first verify whether the vulnerable component is actually present in the shipped product, then map it to the affected version and usage path before deciding remediation. If the issue is real, record the disposition, such as fixed, not affected, under investigation, or mitigated, so downstream consumers know the exposure and any compensating control.
Q: Why does an SBOM need VEX context for regulatory review?
A: An SBOM lists components, but VEX context explains whether a listed vulnerability affects the product, is exploitable, or has been mitigated. For regulatory review, that status helps assess exposure without treating every disclosed component as an active defect, and it supports consistent evidence for patching, exceptions, and risk acceptance decisions.
Q: What is the difference between SBOM and VEX?
A: An SBOM lists the software components in a product, while VEX states whether a known vulnerability affects that product and under what conditions. SBOM helps with inventory and exposure discovery; VEX helps with triage and prioritisation. Security teams should use both together, because a component being present does not always mean the vulnerability is exploitable in the deployed environment.
Q: When should manufacturers update vulnerability dispositions?
A: Manufacturers should update vulnerability dispositions when new information changes whether the issue applies, is exploitable, or has been mitigated. That includes changes from testing, triage, patch release, workaround availability, or component replacement, so the disposition stays aligned with the product’s current security state and downstream consumers do not rely on stale status.
Technical breakdown
Why SBOMs alone stop short of regulatory evidence
An SBOM tells you which components are present, but not whether a listed vulnerability is reachable in the deployed environment. That gap matters because vulnerability counts can be inflated by transitive dependencies, unused code paths, compensating controls, or product architecture that removes the attack surface. Reviewers then have to infer risk from a flat list of CVEs, which creates inconsistency and slows decision-making. The issue is not the completeness of the inventory, but the absence of disposition metadata that connects component presence to real exploitability. See the [[L1|SBOM guide]]. See the SBOM Guide.
Practical implication: Treat the SBOM as an input to risk disposition, not as the final cybersecurity artifact.
How VEX encodes exploitability and mitigation status
VEX adds structured statements that answer whether a vulnerability affects a specific product, and if it does, what the status or mitigation is. That can include not affected, affected, fixed, under investigation, or a similar disposition model, depending on the format used. The value is not in repeating the vulnerability record, but in binding the vulnerability to product context so downstream reviewers and internal teams can reuse the same determination. In regulated software, that makes the difference between evidence that can be audited and analysis that lives in someone’s inbox. See the [[L12|VEX guide]]. See the VEX Guide.
Practical implication: Maintain a repeatable disposition model so exploitability judgments survive review, audit, and future vulnerability updates.
Why continuous vulnerability monitoring changes the submission model
Premarket documentation is only one checkpoint. Once a product ships, newly disclosed CVEs can change the risk picture without any change to the software itself. That is why continuous monitoring matters: the SBOM remains static while the vulnerability landscape changes around it, and VEX becomes the living layer that tracks those changes. For regulated products, this is a governance problem as much as a technical one, because the organisation needs a durable process for reassessing exposure, documenting remediation, and preserving the reasoning behind each disposition decision.
Practical implication: Build a process that refreshes exploitability determinations whenever new vulnerability intelligence appears.
Breaches seen in the wild
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
VEX is becoming the evidence layer that makes SBOMs usable in regulated cybersecurity. A component inventory answers what is in the product, but not what is actually exposed, reachable, or compensating-controlled. In a regulated submission context, that distinction decides whether reviewers get a defensible risk story or a raw vulnerability dump. Manufacturers that cannot express disposition in a repeatable way will keep forcing humans to reconstruct the same judgment over and over.
The governance failure is not missing data, but missing exploitability context. The article points to a familiar control gap: organisations assume the presence of a vulnerability is enough to trigger action, but reviewers need to know whether the issue is exploitable in this device. That is a named concept worth carrying forward: exploitability disposition gap: the gap between knowing a CVE exists and proving whether it matters in a specific deployed product. When that gap persists, compliance turns into delay.
Regulated software now needs lifecycle evidence, not point-in-time filing discipline. FDA expectations are moving toward continuous vulnerability monitoring, which means documentation has to be maintained as conditions change, not assembled once at submission time. That is a broader signal for any security programme handling software in regulated environments. The operational burden shifts from packaging artifacts to sustaining their accuracy across the product lifecycle.
SBOM and VEX together are shaping a more reviewable form of software governance. This is less about creating more paperwork and more about making security decisions traceable, reusable, and defensible. For teams building regulated products, the practical consequence is that vulnerability triage must become a managed record, not an ad hoc analyst judgment. The organisations that standardise that record will move faster when regulators ask hard questions.
What this signals
Exploitability disposition gap: regulated software teams will increasingly be judged on whether they can prove that a vulnerability matters in context, not just whether they can list it. That shifts the control objective from inventory completeness to decision traceability.
For product security programmes, the operational challenge is to keep SBOM and vulnerability disposition records synchronised as new CVEs emerge. Without that lifecycle discipline, submissions age quickly and review responses become harder to defend.
For practitioners
- Document exploitability dispositions for every SBOM-listed vulnerability Record whether each known issue is affected, not affected, mitigated, or under review, and require a reasoned justification that can be reused in submission packages.
- Tie vulnerability triage to the product build and release record Keep SBOM versions, component changes, and VEX dispositions aligned so reviewers can trace each status decision back to the exact software state.
- Automate refreshes when new CVEs appear Trigger reassessment when vulnerability feeds update so exploitability judgments do not depend on manual re-analysis after every disclosure cycle.
- Prepare reviewer-ready submission packages Package the SBOM, VEX artifact, and prioritisation rationale together so deficiency responses can be answered without recreating the analysis from scratch. See the Supply Chain Compromise Response Playbook.
Key takeaways
- Medical device cybersecurity review is moving beyond component inventories toward evidence that explains which vulnerabilities are exploitable in context.
- The key failure mode is the gap between listing a CVE and proving whether it matters in the specific product and deployment environment.
- Teams that maintain living SBOM and VEX records can answer regulatory questions faster and reduce the risk of review delay.
Related NHI Mgmt Group resources: SBOM Guide · VEX Guide · Supply Chain Compromise Response Playbook · Reachability Analysis Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Missing exploitability context in regulated software submissions reflects incomplete security configuration evidence. |
| Recommendation — Document product security state clearly enough that reviewers can distinguish real exposure from theoretical vulnerability. | ||
| MITRE ATT&CK | TA0007 — Discovery | Vulnerability review is tied to discovering which components and exposures are actually present in the product. |
| Recommendation — Map component inventory and exposure analysis to discovery workflows so risk judgments stay grounded in observed state. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The article is fundamentally about keeping vulnerability status current across the product lifecycle. |
| Recommendation — Operationalise continuous vulnerability management so newly disclosed CVEs trigger fresh disposition decisions. | ||
| NIST CSF 2.0 | PR.DS-10 — Data-in-Transit is Protected | The article does not materially concern data-in-transit protection, so this framework is weakly relevant. |
| Recommendation — Protect submission data in transit when sharing regulated cybersecurity evidence. | ||
| SLSA | L2 — Build Integrity | SBOM and VEX workflows depend on trustworthy build and release provenance for the artifacts they describe. |
| Recommendation — Preserve build provenance so SBOM and VEX records remain tied to verifiable release artifacts. | ||
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 eXchange (VEX): Vulnerability Exploitability eXchange (VEX) is a standard way to state whether a known software vulnerability can actually be exploited in a specific product or component. It gives machine-readable status for security teams, tying vulnerability findings to package, build, or component evidence so prioritization focuses on real exposure.
- Known Exploited Vulnerability: A Known Exploited Vulnerability is a flaw that has confirmed active exploitation in the wild and is tracked for urgent remediation. In governance terms, KEV status turns patching from a general hygiene task into a time-bound operational obligation.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect identity control to broader assurance and review processes.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org