They should freeze reliance on new uses of the dependency, assess reachable exposure, and move to a replacement roadmap with clear ownership. If the component protects a trust boundary, the migration should be treated as a security programme, not a normal engineering refactor. Delay only increases the number of systems inheriting the same risk.
Why This Matters for Security Teams
When a critical dependency has no planned fix, the problem is not just technical debt. It becomes an exposure-management decision that can affect availability, integrity, and downstream trust. Security teams often underestimate how quickly a “known issue” turns into a permanent part of the attack surface, especially when the dependency sits inside authentication, signing, orchestration, or data-processing paths.
The right response is to classify the dependency by business criticality, reachability, and trust boundary impact, then decide whether the organisation can contain the risk while a replacement is built. That work should map to a formal control structure such as the NIST Cybersecurity Framework 2.0, because the issue is as much about governance and recovery as it is about code. If the dependency can be invoked by external inputs, embed it in a service that handles credentials, or influence security decisions, the tolerance for continued use should be very low.
Teams also get this wrong by treating “no fix planned” as an acceptable temporary state. In practice, many security teams encounter the blast radius only after the dependency has already been copied into multiple services, rather than through intentional risk acceptance.
How It Works in Practice
Start by identifying where the dependency is used, whether the vulnerable path is reachable, and what compensating controls already exist. A dependency that is present but not reachable may be tolerable for a short period if there is strong isolation, monitoring, and a credible migration plan. A dependency that is reachable across internet-facing systems, privileged workflows, or high-value data paths should usually be treated as urgent.
A practical response usually has four tracks:
- Freeze new adoption so the problem does not spread to more services or product lines.
- Inventory every application, pipeline, image, and package that consumes the component.
- Apply compensating controls such as isolation, feature disablement, stricter input validation, WAF rules, or privilege reduction where they are genuinely effective.
- Build and execute a replacement roadmap with a named owner, a target date, and explicit exit criteria.
For open-source components, teams should also review maintainer status, transitive dependencies, and whether a safe fork is viable. For commercial or embedded components, legal, procurement, and vendor-management teams need to be involved early, because the fix may depend on contract leverage or supported upgrade paths. Guidance from resources such as the CISA Known Exploited Vulnerabilities Catalog can help prioritise urgent exposure when exploitation is active or likely.
If the dependency supports identity, token validation, secret handling, or trust establishment, the migration should be treated as a security programme, not a normal refactor. These controls tend to break down when the dependency is deeply embedded in legacy monoliths or infrastructure images because replacement requires coordinated changes across build, deployment, and runtime layers.
Common Variations and Edge Cases
Tighter containment often increases operational overhead, requiring organisations to balance immediate risk reduction against delivery speed and engineering capacity. That tradeoff is especially visible when the dependency is used everywhere, because every workaround adds friction to testing, release, and support.
Not every “no planned fix” situation means immediate removal. Current guidance suggests that if a component is not reachable in practice, is strongly isolated, and does not sit on a critical trust boundary, temporary acceptance may be defensible with documented risk ownership. Best practice is evolving here, and there is no universal standard for how long a team can rely on compensating controls alone.
Edge cases include firmware, embedded systems, air-gapped environments, and regulated platforms where replacement may take months or years. In those settings, the decision often becomes whether the organisation can safely segment the dependency, monitor for exploitation, and prove that business continuity remains acceptable. Where the dependency affects secrets, signing, or authentication flows, the risk is often closer to an identity compromise than a simple software defect, so the migration plan should reflect that higher consequence. For broader governance alignment, the NIST Cybersecurity Framework 2.0 remains useful for structuring ownership, risk treatment, and recovery priorities.
The hardest cases are when teams inherit the dependency through a vendor product and cannot patch it directly. In those environments, the real control is often reducing exposure and planning replacement, because risk acceptance without a date becomes permanent.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Risk acceptance needs explicit ownership and treatment decisions. |
| MITRE ATT&CK | T1195 | Compromised software supply chain is relevant when a dependency is unmaintained or unsafe. |
Check whether the dependency could be abused through the software supply chain and harden delivery paths.
Related resources from NHI Mgmt Group
- Should organisations allow pull_request_target for automated dependency workflows?
- How can organisations decide which identity risks to fix first?
- How should organisations modernize authentication in critical infrastructure without breaking operations?
- What should organisations do when passwords are still needed for critical access?
