Once a quarter, list every package, app and script on the store, mark what nothing uses, remove it in small groups, test checkout after each group and record the result. OWASP lists removing unused dependencies, features, components and files as the first step in its prevention advice.
Why pruning reduces risk
Every component you keep needs patches, review and an owner. A package that nothing calls still sits in your inventory, still appears in scan results and can still be reached through its own install or load path.
The OWASP entry on Vulnerable and Outdated Components starts its prevention list with removing unused dependencies, unnecessary features, components, files and documentation. It is also the cheapest fix: a deleted package has no advisory to triage.
Where unused code gathers
| Area | Typical leftovers |
|---|---|
| Package manifest | Libraries from a redesign or a prototype |
| Theme | Old sliders, zoom plugins, unused snippets |
| Platform apps | Apps installed for a trial and never removed |
| Tag manager | Paused tags from past campaigns |
| Server modules | Extensions for features that were switched off |
| Build tooling | Plugins for a step that no longer exists |
The routine
- List. Pull the current inventory: SBOMs for builds, the app list, the tag list, the theme file list.
- Mark usage. For each item, find the code path or page that uses it. Search imports and template references, and check page captures. Items with no use are candidates.
- Ask the owner. Confirm with the person listed for each item. If there is no owner, that is a finding.
- Group the removals. Remove a handful at a time, ordered from lowest risk to highest.
- Test. Run your regression checklist for cart, checkout, login and account pages after each group.
- Ship and record. Release through normal review, and note what was removed, the date and who agreed.
- Watch. Keep an eye on errors for a few days after release before the next group.
Handling items you cannot remove yet
Some components are needed but unsupported. OWASP advises monitoring for libraries that are unmaintained or do not produce security patches for older versions, and says that where patching is not possible you can consider a virtual patch to monitor, detect or protect against the issue. Put these on a dated replacement plan so that "later" has a date.
Use pruning to speed up peak season
A smaller store is easier to freeze and easier to test. Run the prune well before your busiest period, so the freeze starts from a clean list. Our dependency freeze plan for peak season pairs well with this routine.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how an inventory gives you the list to start marking usage against.
Where Safeguard fits
Safeguard's SBOM and dependency scanning produces the package list for step 1, and reachability analysis shows which vulnerable code your app actually calls. Deciding what to remove stays with your team. A free scan is at gold.safeguard.sh/scan.
Quick check
How often should we prune?
Quarterly is a sensible start. Also prune after any redesign, replatform or vendor change.
What if we are afraid to remove something?
Remove in small groups on staging first, test checkout, and keep the previous release ready for a quick rollback.
Sources
Last reviewed: 19 October 2026.
