Inventory dependencies in the release you actually ship
Connect declared packages, resolved dependency paths, and shipped components. Record direct owners, transitive paths, build-only use, and inventory gaps.
A dependency inventory should identify the components in a particular release, not simply copy the top-level manifest. A direct package can introduce several nested packages, while a development dependency may participate in the build without appearing in the deployed runtime. Both can matter, but they require different review questions.
OWASP's dependency management guidance provides context for managing third-party component risk. The inventory below is a proposed release worksheet that separates declared intent, resolved versions, and observed shipment.
Start with a fixed release identity
Record the source commit, package-manager version, lockfile digest, build configuration, and resulting artifact digest. Use the package manager's structured dependency output where available. Do not infer the full graph by searching for package names in source text.
| Component field | What to record | Why it matters |
|---|---|---|
| Package identity | Ecosystem, namespace, name | Avoid matching similarly named packages |
| Resolved version | Exact version or immutable source revision | Match the installed component |
| Dependency path | Root package through each parent | Find the maintainer who can update it |
| Use phase | Build, test, runtime, or multiple | Locate the relevant authority and exposure |
| Shipment evidence | Artifact path or inspection result | Distinguish resolved from actually included |
Keep multiple versions as separate occurrences. Collapsing them to the highest version can hide an older copy that still ships.
Reconcile the graph with the artifact
Inspect containers, bundled assets, native libraries, plugins, and vendored code that the package manager may not fully describe. Record the inspection method and its limitations. A missing entry is an inventory gap, not proof that the component is absent.
For a monorepo, identify the workspace that owns each deployed artifact. A root lockfile may include packages for services that are not part of this release. Preserve that distinction rather than reporting every workspace package as a production dependency.
Assign a maintainable owner
Map each direct dependency to a team or service owner. Attach transitive components through their actual parent paths. If several parents introduce the same vulnerable version, record every path that must change.
Store the inventory with the release evidence and regenerate it when the artifact changes. Keep unknown versions visible for follow-up. The useful result is a graph that lets an engineer answer which release contains a component, how it arrived, and who can change it. It is not a claim that every listed package has been reviewed or that unlisted software is safe.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.