If a vulnerable dependency is already scheduled for removal, a short suppression tied to that removal ticket is reasonable. If the plan is vague, remove it now or fix it, because the suppression will outlive the intention. Date, owner and ticket turn "we will drop it" into something checkable.
The common trap
"We are replacing that library next quarter" is one of the most renewed sentences in security. Roadmaps slip. The suppression stays. A year later the library is still there and the original author has changed teams.
Decide with four questions
- Is a removal ticket in a real backlog, with an owner and a target date?
- Is the vulnerable code reachable in the meantime?
- Can you apply a compensating control, or a quick upgrade, today?
- Is removal smaller than the suppression's paperwork?
If the answer to the last is yes, just remove it. Many unused or lightly used dependencies take under an hour to drop. Our article on finding unused dependencies with an SBOM helps you check.
A decision table
| Situation | Action |
|---|---|
| Not imported anywhere | Remove now |
| Used in one place, easy replacement | Replace this sprint |
| Used widely, replacement planned with a date | Suppress to the date, with ticket and mitigation |
| Used widely, no plan | Treat as normal remediation, not removal |
| Reachable and exploited | Fix or mitigate immediately, do not wait |
Writing the tied suppression
Make the record say:
- The removal ticket ID and the planned date.
- The reason, typically a time limited deferral.
- The mitigation in place until then.
- An end date a little after the planned removal, not months after.
- An owner who is on the removal work.
Add a check: when the ticket closes, the suppression should be deleted in the same pull request. Some teams automate this by failing CI if a suppression refers to a closed ticket.
What if the date slips
A slip is a new decision. Require a reason for the delay and a fresh look at reachability. Count it as a renewal. After two slips, escalate to whoever owns the roadmap, because the real issue is priority, not security.
Do not suppress, then forget the cleanup
Removal has leftovers: lockfile entries, configuration, imports in comments, documentation and any exceptions in other tools. Search for the package name across the repository and delete the suppression last.
A worked example
A team finds a vulnerable date parsing library used in one report job. A replacement takes two days. They schedule it for next sprint, suppress for 30 days with the ticket linked and a note that the report job reads only internal files, and delete the entry in the same pull request that removes the package. Nothing lingers.
Where Safeguard fits
Safeguard's dependency scanning and SBOM data show where a package is used across projects, which helps size the removal. The free scan at gold.safeguard.sh/scan gives a quick inventory.
Make removal the default
When in doubt, drop the package. Every dependency you keep is a standing cost of scanning, triage and updates, so the cheapest suppression is the one you never need.
Quick check
How long should a suppression for a pending removal last?
Until a little after the planned removal date, usually 30 to 90 days, with the ticket linked.
What if the removal keeps slipping?
Treat each slip as a renewal with fresh evidence, and escalate after the second one.
Last reviewed: 19 October 2026.
