Include the engine version, the resolved packages, plugins with sources, native libraries, web template scripts, the date and result of the last scan, and a named owner. One page, generated at release time, answers most partner and platform questions without a scramble.
Why a pack helps
Publishers, platform holders, enterprise customers and auditors may ask what a build contains and how you check it. Their wording varies, and this post does not say what any given party requires. A ready page lets you answer truthfully and quickly, and the same page serves your own incident response when an advisory lands.
The sections
- Build identity: game, build number, date, platform, engine and version.
- Packages: resolved versions from the lock file. Unity says its lock file records the resolution so the same packages install every time, which makes it the right source.
- Plugins and addons: name, version or tag, source, license, reviewer. Epic's documentation says plugins with Source folders compile with your game, so these are part of your code.
- Native libraries and middleware: name, vendor, version, and whether a component list was obtained. See native plug-in inventory.
- Web template scripts for browser builds.
- Third party SDKs and the data they receive. See third party SDKs in games.
- Scan record: tool, date, scope, what was excluded and why. Mention honestly that console SDK paths were excluded if they were.
- Open risks: accepted findings with owner and review date.
- Contacts: engineering owner and a security contact.
How to produce it
Generate sections two to five from files in the repository during CI, so they cannot drift. Fill the rest from your inventory. Store the page with the build artifacts, keyed by build number.
What to leave out
Do not claim certifications or attestations your studio does not hold. Do not paste NDA material. Do not include secrets. Keep the wording factual: this is what we scanned, when and what we found.
A note on file formats
An SBOM in a standard format such as CycloneDX or SPDX can carry sections two to four for tools to read. The one pager is for people. Keep both, generated from the same data.
A short example
A filled in pack for a small studio might read: Build 218, Windows and Android. Engine version recorded. Fourteen packages from the lock file. Three plugins, all in the project folder, each with a tag and reviewer. Two native libraries, one with a vendor component list and one without, noted as an open risk. Last scan dated on the build day, scope and exclusions stated. Two accepted findings with owners and review dates.
Nothing in that is impressive, and that is the point. It is plain, checkable and fast to produce, which is what a partner or auditor wants to see.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through to see how one piece of evidence can be mapped to several questions at once. Your one pager works the same way.
Quick check
How often should the pack be regenerated?
At every release build, and again after a major advisory affecting something listed.
Should it list findings we accepted?
Yes, with an owner and a review date. Hiding them makes the page less useful and less honest.
Sources
Last reviewed: 19 October 2026.
