The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Removing a dependency from a manifest does not prove it is absent from the resolved dependency tree, a built artifact, a package cache, a deployment, or a running system. Those are different states, and each needs evidence of its own. “Dependency residue” is a useful name for the gap between removing a declaration and verifying the software that still exists; it is not a formal standard. The risk can be costly, but no universal dollar cost has been established.
What does “dependency residue” mean?
A direct dependency is one your project references itself. A transitive dependency is brought in because another dependency requires it. Remove a direct entry and its transitive packages may disappear from the next resolution—or a package may remain because another part of the project still needs it.
As an Amazon Associate I earn from qualifying purchases.
A lock file records resolved versions for a particular dependency resolution. It is more informative than a manifest alone, but it describes neither every old package-manager cache nor every artifact and deployment already produced. Google Cloud explains how direct and transitive relationships, manifests, and lock files fit into dependency management in its dependency guidance.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsThe phrase “dependency is gone” therefore needs a scope. It might mean the manifest no longer declares it, the current lock file no longer resolves it, a new artifact excludes it, a cache has been cleaned, or deployed instances no longer contain it. Evidence for one does not prove the others.
Why might it still appear after you remove it?
Another package still requires it
If a remaining direct dependency has the removed package in its transitive dependency path, the package manager can continue to resolve it. Inspect the path rather than treating a package name in a dependency list as an isolated entry. GitHub’s dependency graph documentation describes path inspection for transitive components and the graph’s relationship to manifests and lock files: dependency graph data.
The build resolves more than the static files show
Some ecosystems resolve indirect dependencies during a build. A source-code graph based only on manifests and lock files can miss dependencies introduced at that stage; GitHub says build-time dependency submissions can provide additional visibility. The reverse problem also occurs: a static list may describe declared or resolvable dependencies without proving exactly what was packaged.
Code or binaries were copied into the project
A library can be vendored as loose files or included inside an archive rather than installed as an ordinary package. GitHub’s troubleshooting documentation says these copied-in files are not automatically detected as standard manifest or lock-file dependencies. A clean dependency graph is not proof that such code is absent. See GitHub’s dependency graph troubleshooting guidance.
Recommended Free Tools
An artifact, cache, or deployment predates the change
Even when a fresh resolution no longer includes a package, previously built software and cached packages remain separate copies. Deployed services may still be running an older artifact. For a malicious component, Microsoft Security Engineering says cleanup may need to include developer machines, the package caching solution, and production software or services that consumed it. Its open-source security practices treat inventory and remediation as lifecycle concerns, not just manifest edits.
Static analysis cannot always see how code is used
Reflection, dynamic proxies, class loading, generated code, and edge cases can make a dependency’s role difficult to establish from ordinary static references. A package flagged as unused is a lead to investigate, not a guarantee that removing it is harmless.
Does an “unused” finding prove a dependency can be removed?
No. A 2022 peer-reviewed study by Chuang, Cruz, van Dalen, Mikovski, and van Deursen examined dependency-removal recommendations, including one industrial Java application and histories from three open-source projects. In that study, the authors’ decision framework produced one-third fewer false positives than the compared state-of-the-art approach in the industrial case. That result is specific to the study and should not be treated as a general rate for other languages or projects. The paper and institutional record also describes 12 dependencies initially flagged as unused that became used after the researchers augmented the call graph with critical OPAL edges.
The researchers’ selective tests illustrate why a recommendation needs review: all three tested dependencies classified as used caused functionality-test failures when removed. Among six selected recommendations that required additional developer steps, half failed tests; one selected unused dependency passed. These are small, selected counts from that study—not predicted failure rates for a different project. The authors also discuss reasons developers declined some recommendations, including transitive relationships, future upgrades, edge cases, and required functionality.
Use static analysis to narrow the investigation. Before removal, consider dynamic loading and indirect relationships, then have a developer familiar with the project assess the finding and test relevant behavior.
How can you verify that a dependency is really gone?
- Define the claim. Write down whether you need to prove a manifest entry was removed, the resolved dependency tree changed, a newly built artifact excludes the component, a cache was cleared, or deployed and runtime systems no longer contain it. Choose evidence from that same stage.
- Trace its former path. Check direct and transitive relationships in the lock file or equivalent, build-resolved snapshots where available, vendored files and archives, and relevant platform or plugin relationships. If using GitHub’s dependency graph, inspect the dependency path and check whether build-time submission is appropriate for your ecosystem.
- Challenge an “unused” result. Look for reflection, proxies, class loading, generated code, dynamic invocation, edge cases, and uses that are not obvious from the package’s name. Run tests that exercise the relevant features; ordinary tests cannot establish behavior for paths they never exercise.
- Review the proposed change before merging. Removing or updating one direct package can alter indirect dependencies too. GitHub’s dependency review can surface added, removed, or updated components and known vulnerability information in pull requests.
- Build and inspect the new artifact. Confirm the resolved output and the contents of the software produced by the build. Where supported, use a build-time dependency submission to add visibility into dependencies resolved during the build. If the concern is a deployed service, check its deployed inventory rather than assuming a source-tree change updated it.
- Use runtime evidence for runtime questions. Runtime observation can help identify components loaded during execution, but it reflects the paths exercised and conditions observed. Pair it with source, build, or deployed evidence as appropriate; no single inventory view establishes every lifecycle stage.
- For a malicious component, locate and remediate every relevant copy. Include developer machines, package caches, produced software, and production services where the component may remain. Preserve versions and provenance information useful to incident response.
- Keep a version-specific record. Associate inventory information with the software version or update it describes, and state known gaps rather than implying a complete list when it is not. This gives later reviewers a way to assess what was checked and what remains uncertain.
Which inventory view answers which question?
Software inventories are snapshots of different stages, not interchangeable certificates of absence. CISA’s taxonomy distinguishes source, build, analyzed, deployed, and runtime SBOMs and describes their different visibility and limitations. A source inventory may miss components loaded only at runtime; a runtime inventory depends on the system being exercised. Treat these views as complementary evidence. See CISA’s SBOM types document.
Rank #4
| Inventory view | Useful for | What it does not establish by itself |
|---|---|---|
| Source | Reviewing declared dependencies and relationships visible in project source files. | That every build-resolved, copied-in, deployed, or runtime-loaded component is represented. |
| Build | Inspecting dependencies resolved or included during a particular build; build-time submissions can add visibility to a dependency graph where supported. | That older artifacts, caches, or deployed instances have been replaced. |
| Analyzed | Recording components identified through analysis of software or artifacts. | That analysis detected every component or every way it can be loaded. |
| Deployed | Checking inventory associated with software installed in a target environment. | That all deployed instances match a source change or that every component will be observed at runtime. |
| Runtime | Observing components loaded during execution in the conditions exercised. | That unexercised features or other runtime conditions would load no additional components. |
The table describes the kinds of questions these views can help answer, not a guarantee that every tool implements each view identically. When evaluating an inventory approach, check its stage coverage, treatment of transitive and dynamic components, version and artifact specificity, compatibility with your actual build process, and disclosure of omissions.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What should an SBOM say about gaps?
NTIA defines a software bill of materials (SBOM) as “a formal record containing the details and supply chain relationships of various components used in building software.” The definition is useful, but an SBOM is scoped to particular software and information available to its creator; it does not prove that a component is absent from every cache, artifact, or running system. Read the NTIA minimum-elements report alongside the inventory’s version and lifecycle context.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
CISA’s August 2025 minimum-elements update calls for covering transitive dependencies and identifying “known unknowns” when dependency information is incomplete. It also calls for an SBOM associated with each software version or update. A candid record of gaps is more useful than a complete-sounding list that conceals what was not observed. See the 2025 CISA SBOM Minimum Elements.
Why can dependency residue be expensive?
Unused dependencies increase dependency footprint and potential exposure to compromise, as Google Cloud notes in its dependency guidance. A component that remains after a removal may also create maintenance work or complicate incident response. If it is malicious, responders may need to find and clean several copies across development, caching, and production environments—not just edit a manifest.
“Most expensive” is a risk framing, not a measured ranking. The cost depends on what remains, where it remains, whether it is vulnerable or malicious, and what systems depend on it. No general dollar figure establishes that dependency residue is always more costly than another software risk.
What can you safely claim after removal?
Make the claim match the evidence: “removed from the manifest,” “absent from the lock-file resolution,” or “not present in the inspected build artifact” says more accurately what was verified than “gone.” If deployed or runtime absence matters, verify those states separately and record the version, environment, and limits of the check. The distinction is operationally important: package relationships and inventories describe particular stages, while a removal decision needs evidence from the stages where the component could still exist.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
