Treat it as trusted build code, not as a passive plugin. Unity's documentation says a source generator runs during compilation and creates source code that becomes part of your program, and that analyzers and generators are imported as managed plugins. Anything that takes part in your compile deserves a supply chain review.
Definitions
A code analyzer examines source code and reports diagnostics to help find errors or enforce rules. A source generator runs during compilation and creates additional source code that becomes part of the program. Unity's manual notes both are built on the Roslyn compiler platform, and that analyzers are typically called Roslyn analyzers.
You can write your own, or import existing third party libraries. They are brought into a project as managed plugins, which means a DLL sits in your Assets or in a package.
Why this deserves a closer look
Because generators emit code that is compiled into your game, the output ships to players. A generator that is changed, or a version that has a defect, changes your build without any line of your own source changing. Reviewers reading a pull request will see only the DLL or a version bump, not the generated code.
Analyzers are lower impact on the build output, but they still run as part of the compile process on developer machines and CI. Code that runs there has the access your build has.
This is not a claim that analyzers are dangerous by nature. Most are useful. The point is that they sit in a position of trust, so you apply intake discipline.
A review table
| Question | What a good answer looks like |
|---|---|
| Who publishes it | A named maintainer or organization you can identify |
| Where did you get the DLL | From the publisher's official release, not a forum attachment |
| Is source available | Yes, and you can build it and compare |
| What does it generate or report | Documented, and you can view the generated output |
| Does a package signature or hash exist | Record it; verify on update |
| Who owns updates | A named person on your team |
Steps
- Download from the official source and record the exact version and file hash.
- If source is available, build it and compare the hash to the published DLL, or at least read what it does.
- Add it in a branch and commit the generated output for review if your tooling allows. Reviewing a diff of generated code once is cheap.
- Pin the version. Do not use floating references.
- Limit its scope. The Unity manual lists analyzer scope and rule set files for controlling which parts of your code are subject to analysis.
- Add the DLL to your plugin register with an owner and a review date. See the plugin register template.
Unity's own caveat
The manual notes that Roslyn analyzers are only compatible with the IDEs that Unity supports. So an analyzer that works in one editor setup may be silent in another. If you rely on an analyzer as a safety net, check that it actually runs in every environment your team uses, including CI.
Safeguard's SBOM and dependency scanning covers packages and libraries declared in your repository, and you can try a free scan at gold.safeguard.sh/scan. A loose DLL dropped into Assets needs a manual register entry as above.
Quick check
Does a source generator change what ships in my game?
Per Unity's manual, the code it creates becomes part of your program, so yes.
Are analyzers and generators packages or plugins?
Unity's manual says both are imported as managed plugins to your project.
How do I limit what an analyzer checks?
Unity documents analyzer scope and rule set files for controlling which code is analyzed and diagnostic levels per assembly.
Sources
Last reviewed: 19 October 2026.
