A good plugin intake form for a game studio has about twelve fields and takes five minutes. It records what the plugin is, its source, whether it runs in the editor or the game, native code, signature or lifecycle state, and an owner with a review date.
The form
| Field | Example answer | Why you ask |
|---|---|---|
| Name and version | Asset X 2.1.0 | Needed to match advisories |
| Engine and version | Unity 6.3, Godot 4.x, Unreal 5.x | Behavior differs by version |
| Source URL | Official store page or publisher site | Provenance |
| Publisher | Named organization or person | Who to contact |
| Form | Source, precompiled, or both | Decides review method; see source or precompiled |
| Runs where | Editor only, game, or both | Editor code and runtime code carry different exposure |
| Native code | Yes or no, which platforms | Native libraries are binary |
| Auto-run on open | Startup script, init script, editor load hook | Open is an execution event |
| Signature or package state | Unity signature status; Unity lifecycle state | Unity documents both |
| Network and data | Hosts contacted, data collected | Privacy and store forms |
| License | Named license, redistribution allowed | Shipping rights |
| Owner and review date | Named person, date | Without this the entry rots |
Where each field comes from
Several of these map to documented items.
- Runs where. Unity says Editor scripts are not available in Player builds, and Epic says a plugin can have editor-only and runtime modules.
- Auto-run on open. Epic documents
init_unreal.pyand project startup scripts that run when the editor opens a project. - Signature or package state. Unity documents signature statuses from 6.3 onward and package lifecycle states for Unity's own packages. See package states.
- Native code. Unity documents native plug-ins as precompiled libraries or source.
- Distribution packs. Godot documents packs that can hold scripts.
How to use it
- Put the form in your issue tracker as a template so it gets filled in at the time of the request.
- Require it before a new plugin is merged to a main branch.
- Keep the filled forms in one folder or table. That is your plugin register.
- Review the table quarterly. Remove anything unused, and check each owner is still on the team.
- When an advisory arrives, search the register by name, then by publisher.
A five minute form will not find every problem. It makes sure someone looked, wrote down what they saw, and can be asked later.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which fields an inventory records for each package, and compare them with the form above.
Safeguard's SBOM and dependency scanning builds an inventory of declared dependencies automatically, and you can try a free scan at gold.safeguard.sh/scan. The form covers what a scan cannot see, such as whether you trust a publisher.
Quick check
Who should fill the form in?
The engineer asking for the plugin. A reviewer then checks it, so one person is not marking their own work.
Is twelve fields too many?
If it takes more than five to ten minutes, trim it. A form people skip protects nothing.
Do I need the form for every asset?
Use it for anything with scripts, native code or network access. Pure art and audio can use a shorter check for license and source.
Sources
- Unity Manual: Introduction to package signatures
- Unity Manual: Package states and lifecycle
- Unity Manual: Native plug-ins
- Epic Games: Plugins in Unreal Engine
- Epic Games: Scripting the Unreal Editor using Python
Last reviewed: 19 October 2026.
