Dependency graph

What it is

A dependency graph is the map of every package and library an application (or repository) depends on, including their transitive (nested) dependencies. Tools that produce a dependency graph inspect manifest/lock files (e.g. package.json+lockfile, *.csproj+packages.lock.json, requirements.txt, pom.xml) and record the full tree of direct and indirect packages and their versions.

Why it exists

A single package you add can pull in dozens of transitive dependencies you never see. To secure the supply chain (know what runs in your app), audit licenses, and detect vulnerable packages, teams need a complete, current map of every dependency and its version. The graph is the foundation for vulnerability scanning and version-pinning decisions.

Key ideas

• Direct vs. transitive — direct deps are declared in your manifest; transitive deps are their dependencies, recursively.
• Lock files — package-lock.json, yarn.lock, packages.lock.json, poetry.lock pin exact versions so the graph is reproducible.
• Dependency graph on GitHub/GitHub Enterprise — GitHub’s dependency graph surfaces dependencies and is tied to Dependabot alerts (dependency vulnerabilities).
• Feed analytics in Azure Artifacts — per-feed package usage/analytics show which packages consumers rely on.
• Vulnerability context — the graph links each package to known CVE databases (e.g. via Dependabot, OSV, or Azure’s dependency scanning).

How it fits

Exam notes

• The dependency graph is what lets you answer “what packages is this app using, and are they safe?”
• Lock files pin transitive versions — committing them makes dependency resolution reproducible.
• GitHub’s Dependabot uses the dependency graph to detect outdated and vulnerable dependencies and open PRs.
• Know that vulnerability fixes require bumping and re-publishing the affected package version.

Related

dependency-management · dependency-vulnerabilities · pipeline-integration · azure-artifacts · package-feed

📘 Source: Microsoft Learn — Dependency Graph