Use risk, business criticality, and release integrity together. Patch when a safe fix exists, replace when the package is abandoned or the fix is unavailable, and freeze only as a short-term exception with a documented plan. The decision should be owned by engineering and security together.
How to decide whether patching is the right move
Patching is the default when the dependency still has an active maintainer, a safe fix exists, and the change can be validated without breaking the calling code. The real question is not whether a patch is available, but whether the upgrade path preserves release integrity, test coverage, and operational stability. If the fix is low-risk and the dependency is still part of the supported ecosystem, patching is usually the cleanest option.
Speed matters, but so does confidence. A patch that closes the security issue while introducing behavioural drift can create a larger operational problem than the original defect, especially in production systems with weak regression coverage.
When replacement is the safer decision
Replacement becomes the better answer when the package is abandoned, the vulnerable version cannot be fixed promptly, or the dependency is so embedded that repeated emergency patches would become a recurring maintenance burden. At that point, the issue is no longer just vulnerability management, it is dependency governance and long-term maintainability.
Replacement is also the right call when the package creates unacceptable supply-chain exposure, such as unclear ownership, poor release hygiene, or a history of unsafe publishing practices. In those cases, keeping the dependency may preserve short-term continuity, but it increases the chance that the organisation will inherit the next problem too.
For open source dependencies, it is useful to compare the package against ecosystem signals such as the NIST National Vulnerability Database and the CISA Known Exploited Vulnerabilities Catalog when assessing whether the vulnerability is already being actively exploited.
Why freezing should stay temporary, not strategic
Freezing a dependency can be justified when there is no safe patch and replacement would take longer than the business can tolerate, but it should be treated as an exception with an expiry date. A frozen dependency is a deliberate acceptance of residual risk, not a stable operating model.
The practical danger is drift. Once a team freezes one component, adjacent upgrades become harder, compatibility windows narrow, and security debt accumulates across the stack. That is why a freeze should always be paired with a documented owner, a target date, and a clear exit route.
The same logic applies to prioritisation signals from sources such as FIRST EPSS and OpenSSF, which help teams judge whether a temporary freeze is tolerable or whether the dependency deserves accelerated remediation.
Risk and Threat Considerations
Dependency decisions are attractive to attackers because vulnerable or abandoned packages can become persistent entry points into otherwise well-defended systems. The main exposure is not only direct exploitation, but also the blast radius created when many services consume the same component and inherit the same weakness at once.
Failure mechanism: Teams defer patching because the change seems small, then discover that the dependency is either already exploited in the wild or too unstable to update safely. In that window, the same package can be used as a repeatable foothold across multiple applications, especially when release governance is weak.
Impact: The result can be code execution, credential exposure, service disruption, or a forced emergency migration under time pressure. A frozen dependency without an exit plan also creates compounding risk, because every future release must work around the same unresolved weakness.
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 addresses the attack and risk surface, while CIS Controls v8, OWASP SAMM, SLSA and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Prioritizes patching and remediation of vulnerable software dependencies. |
| Recommendation — Track dependency exposure continuously and remediate vulnerable packages based on risk. | ||
| OWASP SAMM | Dependency Management — Dependency Management | Covers governance for third-party components across the software lifecycle. |
| Recommendation — Define an explicit dependency governance process for patch, replace, and exception decisions. | ||
| SLSA | Supply Chain Levels for Software Artifacts | Supports release integrity and provenance checks when updating or replacing dependencies. |
| Recommendation — Require provenance and integrity checks before adopting a patched or replacement dependency. | ||
| NIST CSF 2.0 | PR.IP-1 — Configuration Management | Maps to controlled handling of software changes and approved configurations. |
| Recommendation — Maintain approved dependency versions and controlled change records for each exception or update. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | Dependency decisions rely on knowing where components are used and how widely they are exposed. |
| Recommendation — Inventory where the dependency is deployed before deciding to patch, replace, or freeze it. | ||
Practitioner Guidance
What to prioritise: Treat patch, replace, and freeze as different risk decisions, not as technical preferences. The first step is to assess whether the dependency is actively maintained, whether the fix is safe, and whether the package is business-critical enough that downtime or regression would outweigh the security exposure.
Decision rule: Patch when the update is supported and testable, replace when the maintainer or remediation path is no longer credible, and freeze only when the business accepts a temporary exception with explicit ownership and a retirement date. If the freeze cannot be time-boxed, it is usually a deferred replacement problem rather than a valid control choice.
What to verify: Confirm who owns the decision, what evidence supports the safety of the change, and whether the release pipeline can prove the dependency version in production. Practitioners should also verify that the exception will be revisited before the next major release, not after an incident forces the issue.
Practitioner takeaway: The best decision is the one that reduces risk without pretending the dependency will remain unchanged forever; short-term stability is acceptable only when there is a credible path back to supported, maintainable software.
Related resources from NHI Mgmt Group
- What is the difference between patching a vulnerability and reducing identity blast radius?
- How should organisations decide between patching first and redesigning architecture first?
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?