A game build pipeline should build from committed lock files and pinned plugins, fetch large files fully, scan declared dependencies on every pull request and store a record of what shipped. The checklist below turns that into eight checks you can add one at a time.
The checklist
| Check | What it protects | Source of truth |
|---|---|---|
| Lock file committed and used | Same packages every build | Unity lock file |
| Git dependencies pinned to full hash | No moving branch | manifest.json |
| Plugins in the repository | Visible, reviewable code | Project Plugins folder |
| LFS content fetched | Scanner sees real files | .gitattributes |
| Declared dependencies scanned | Known flaws caught | Manifests and lock files |
| Pull request gate | New risk is visible | CI status check |
| Build record stored | You can answer what shipped | Build artifacts |
| Third party scripts reviewed | Web builds stay clean | Template folder |
Why each check exists
Unity says its Package Manager saves its resolution in a lock file so that the same packages install reliably every time. If the lock file is not committed, or CI ignores it, two builds of the same commit can differ. See why versions differ.
Unity's Git dependency documentation says branches and tags can point to different commits over time, while a full commit hash names one commit. See how to pin a Git package.
Epic's documentation says plugins with Source folders are compiled automatically when you compile the project. Keeping them under the project's Plugins folder means the code that builds is the code in your repository.
Git LFS stores text pointers in the repository, so a scan on an unfetched checkout reads pointers. See the LFS post.
Order of adoption
- Commit the lock file and make CI fail if it changes during the build.
- Replace branch based Git URLs with hashes.
- Move plugins into the repository.
- Fetch LFS content in the build job.
- Add a scan step in report-only mode.
- Turn the scan into a pull request check with a narrow blocking rule.
- Store the build record: engine version, lock file, plugin versions, scan report and build number.
- Add a template script review for web builds.
What not to put in the pipeline
Do not give a scan step your signing keys or platform credentials. Run it before those secrets exist in the job. Keep any console SDK material out of shared runners unless your agreements allow it, as covered in the NDA post.
A sample record for one build
For build 1042 of a mobile game, the record might hold the engine version, the lock file as committed, the list of plugins with tags, a note that two native libraries were listed by hand, the scan date, the tool used, zero blocking findings and two accepted findings with owners. That is a page, not a project, and it is produced by the pipeline.
When the next advisory arrives, you open the record for the live builds, search for the package and know within minutes whether to act. That is the payoff of every check in the table.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch what the pull request check reports and where the merge decision sits. That is your step six.
Quick check
Why fail the build if the lock file changes?
A change during the build means the build resolved different packages than the ones reviewed. Fail it and review the change.
Should the scan block merges immediately?
Start in report-only mode, then block on one narrow rule.
Sources
- Package dependency and resolution, Unity 6.0 Manual
- Introduction to Git dependencies, Unity 6.0 Manual
- Plugins in Unreal Engine, Epic documentation
- Git Large File Storage
Last reviewed: 19 October 2026.
