What should organisations do when third-party software has not yet released a fix for a vulnerable dependency?

What “wait for the vendor” gets wrong

When a third-party product embeds a vulnerable dependency, the problem is not just the missing patch. The organisation still owns the exposure created by its deployment choices, inventory gaps, and runtime trust assumptions. If the vendor has not yet shipped a fix, treat the issue as an active risk management problem, not a passive support ticket.

That means deciding whether you can safely remediate the embedded library yourself, whether you need to isolate the affected product, and how much business exposure you are willing to carry until the vendor catches up. The right response depends on whether you control the dependency, the build, or only the deployment.

In practice, this is where supply chain hygiene matters. Organisations that already track what they run, where it is exposed, and which versions are embedded can respond quickly; those that do not often spend their time just identifying impact while the vulnerable component stays live. The fastest reduction in risk is usually to remove reachable exposure, not to wait for perfect upstream timing.

Reduce exposure without breaking supportability

If operationally safe and contractually supportable, updating the underlying library yourself can be the best short-term move. That is especially true when the vendor product is slow to patch, the dependency is common, and the vulnerable code is already embedded in your runtime. The key judgement is whether you can apply the fix without creating a maintenance fork you cannot sustain.

Where self-remediation is not safe, limit the blast radius. Prioritise the products that face the internet, process sensitive data, or sit on privileged internal paths. If you cannot remove the vulnerable dependency immediately, reduce reachable attack surface through segmentation, access restriction, feature disablement, tighter egress controls, or temporary compensating controls that actually reduce exploitability rather than simply documenting the issue.

For organisations that need a structured view of this problem, NHI Mgmt Group’s Ultimate Guide to NHIs is useful for the broader control themes involved, including visibility, rotation, and third-party exposure. The same exposure logic also appears in supply chain guidance such as NIST SSDF (SP 800-218) and SLSA, which both reinforce the need to understand provenance and dependency integrity.

Risk and Threat Considerations

The main danger is prolonged exposure while teams assume the vendor will fix the issue “soon enough.” During that window, attackers target the easiest reachable deployment, not the largest vendor. A vulnerable dependency can become exploitable across many customers at once, so the risk scales with how widely the software is deployed and how exposed the affected systems are.

Failure mechanism: The embedded library remains reachable in production because the organisation does not control the vendor release cycle, does not know where the dependency is embedded, or cannot safely constrain the affected service quickly enough. That creates a gap where known vulnerable code stays in use even after the problem is understood.

Impact: The result can be compromise of the product, lateral movement into connected systems, or broad exposure if the software processes sensitive data or has privileged integration paths. The longer the delay, the more likely the vulnerable version persists across multiple environments and becomes an avoidable incident rather than a temporary issue.

Practitioner Guidance

What to verify: Confirm whether you control the build artefact, the embedded library, or only the deployed product. That distinction determines whether direct patching, a vendor workaround, or temporary isolation is the fastest defensible action.

Decision rule: If the fix can be applied safely without breaking support, patch the dependency and validate the product; if not, treat affected internet-facing or high-value systems as the first containment priority and apply compensating controls until the vendor releases an update.

What good looks like: You can identify every product carrying the vulnerable dependency, rank them by exposure, and show a clear owner for each remediation path. That is the difference between managed delay and unmanaged drift.

Practitioner takeaway: Do not confuse vendor ownership with risk ownership, because the organisation that runs the software owns the exposure until the vulnerable dependency is removed, contained, or convincingly neutralised.

Related resources from NHI Mgmt Group

• What should teams do when a third party product has not yet released a fix for a vulnerable mail component?
• What breaks when organisations do not control third party access in software delivery pipelines?
• What breaks when organisations assume a language package update is enough to fix a vulnerable native dependency?
• Why does a software bill of materials matter when organisations rely on third-party code and open source libraries?