Patch now if the vulnerable code is reachable, the component is exposed to the internet, or the flaw is known to be exploited. Waiting for the rewrite is defensible only for low exposure findings with a firm retirement date and a compensating control.
Why "it will be replaced soon" is risky
Modernization schedules slip. Microsoft's guidance says the original system can continue to exist for an extended period of time during migration. Fowler makes a related point: replacing a serious system takes a long time. A component planned for retirement in six months may still be in production in eighteen.
Attackers do not check your roadmap. If a flaw is exploited in the wild, the retirement date does not matter.
A decision guide
Answer these questions in order for each finding.
- Is it on CISA's Known Exploited Vulnerabilities list? CISA describes the catalog as an input to prioritization, since it lists flaws exploited in the wild. If yes, fix or mitigate now.
- Is the vulnerable code reachable from your application? If no, the urgency falls.
- Is the component reachable from outside your network, directly or through the facade? If yes, urgency rises.
- Does a safe fix exist? If a patched version is available and tests pass, applying it is usually cheap.
- When exactly will the component be retired, and who has committed to that date? A vague "next year" is not a plan.
| Situation | Suggested action |
|---|---|
| Exploited, exposed | Patch or mitigate immediately |
| Reachable, internal only | Patch within your normal window |
| Not reachable, exposed | Patch when convenient, add monitoring |
| Not reachable, internal, retiring within weeks | Accept with expiry |
Compensating controls when you cannot patch
- Block the vulnerable path at the facade or a web application firewall rule
- Restrict network access to the component
- Disable the unused feature that contains the flaw
- Add detection for the known exploit pattern
These are stopgaps. Record an owner and a review date for each one.
Keep the effort proportional
Patching the legacy app does not have to mean a large upgrade. Often the fix is a minor version bump of a single transitive library. Low effort fixes are worth taking even on code that is being retired, because they close real exposure for little cost.
Avoid the opposite trap as well. Rewriting a library call in a module that will be deleted next sprint wastes effort. Let the decision guide above separate the two.
Document the decision
Whichever way you go, write down the finding, the decision, the owner and the date. Auditors and customers ask about exceptions, and a clear record is far better than a memory. Our post on legacy SAST debt burn down shows one way to schedule this work.
Safeguard's reachability analysis and policies help with steps two and three, and fix pull requests, which are off by default, can propose safe version bumps for review when you turn them on.
Quick check
Can we skip patching if the module is being deleted?
Only for low exposure findings with a committed, near term deletion date. Otherwise patch or mitigate.
What counts as a compensating control?
Anything that blocks or detects exploitation without changing the vulnerable code, such as restricting network access.
Sources
- Strangler Fig pattern, Azure Architecture Center
- Strangler Fig, Martin Fowler
- Known Exploited Vulnerabilities Catalog, CISA
Last reviewed: 19 October 2026.
