Treat the SBOM search as your checklist. Find every service that contains the library, assign each to an owner with a replacement and a date, and close an item only when a fresh SBOM for that service no longer lists it. Then add a rule to stop it returning.
Why a search beats a message to all teams
Announcing that a library is deprecated and asking people to remove it produces uneven results. Some teams never read it, others think they are done when one import is gone but a transitive copy remains. A search across stored SBOMs gives a complete list and a way to verify. It also finds the services nobody remembers.
The checklist
- Define what retired means. Is it a library, a version range, or a whole family of packages? Write the exact package names and ecosystems.
- Search all SBOMs. Record service, version, direct or transitive, and environment.
- Pick the replacement. One recommended option, with a short migration note. Several options produce several migrations.
- Assign owners and dates. One ticket per service, linked to the search result.
- Handle transitive copies. If another package brings the library in, the owner may need to upgrade or replace that package. See why is this package in my build.
- Verify with a new SBOM. Generate after the change and search again.
- Prevent return. Add a policy that flags or blocks the package in new builds.
- Close the programme. When the search is empty for all services, record the date and the evidence.
Tracking table
| Service | Path | Owner | Target date | Verified by new SBOM |
|---|---|---|---|---|
| Service A | Direct | Team 1 | Set it | Yes or no |
| Service B | Transitive via a shared package | Team 2 | Set it | Yes or no |
Handling exceptions
Some services cannot move quickly: a frozen product, a vendor controlled component, a customer contract. Allow an exception, but make it explicit. Record the reason, the owner, a review date, and any compensating control. An exception with no expiry date is a permanent decision made by accident. Our post on linking SBOM diff exceptions to components and expiry covers the pattern.
Common failure modes
- Declaring victory after the code import is removed while the lockfile still pins the old version.
- Not checking container images, where the library may live in an OS package.
- Forgetting scheduled jobs and internal tools, which rarely appear in anyone's architecture diagram.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one finding can be tracked across the items it affects.
Safeguard's SBOM and dependency scanning, with policies and gates, support both the search and the guardrail that keeps a retired package out. A free scan shows a repository's components.
Quick check
How do I know the library is really gone?
Generate a new SBOM for the service and search it. A removed import is not proof.
What about services I cannot change?
Record an exception with an owner, a reason and an expiry date, and revisit it.
Last reviewed: 19 October 2026.
