To know what is in a game build, list more than package manager dependencies. Include the engine version, native plugins, middleware, asset store packs, SDKs and the build tools that produced the binary. Record version and source for each, and tie the list to a specific build.
Why games are hard to inventory
A web service usually has a lockfile. A game often has several worlds mixed together: engine code, scripts, native libraries copied into a folder, downloaded asset packs, art tools, and vendor SDKs added by hand. Many of these never appear in a package manager, so a normal dependency scan sees only part of the picture.
What to record for each item
- Name, version and where it came from, such as a store page, vendor site or repository.
- License, since asset packs and middleware often carry terms that limit redistribution.
- Whether it runs in the shipped client, the server, the editor only, or the build only.
- Who owns updating it.
- The hash of the file you actually shipped, when practical.
Categories to walk through
- Engine and its editor version, including any custom fork or patches.
- Package manager dependencies for scripts and backend services.
- Native libraries and plugins in the project, which are easy to forget.
- Store bought or downloaded asset packs that include code.
- Third party SDKs for analytics, ads, payments and login. See third party SDKs in games and creator apps.
- Mods and plugin systems you expose to players. See mod and plugin safety.
- Build and CI tools, and the container images used for dedicated servers.
Make the list useful
An inventory in a spreadsheet goes stale. Generate it from the build where you can, in a standard format such as an SBOM, and store one per released build. When a vulnerability in some library is announced, you want to search all builds and answer in minutes whether you ship it, and where.
For items that tools cannot read, such as a copied binary, keep a manual register and review it each release. A short, honest manual list beats an unknown.
Update rules
Pin versions. Review changes to engine and SDK versions as deliberately as code changes. Keep old build inventories, since players may stay on old versions for a long time.
Try it yourself
Open the demo and look at how a dependency inventory lists packages and versions. Notice which entries are direct and which came in through another package.
Click through it at your own pace, or open it full screen.
Safeguard provides SBOM and dependency scanning for the package based parts of this inventory. You can start with the free scan at https://gold.safeguard.sh/scan.
Quick check
Is a lockfile a complete inventory of my game?
No. It covers package manager dependencies only, not engine plugins, copied binaries or asset packs.
Do editor only tools belong in the inventory?
Yes, but mark them as editor only. They still affect developer machines and the build.
Last reviewed: 19 October 2026.