A private generator is a program you wrote that runs in your build and writes code into your product. Secure it like any internal build tool: keep the source reviewed, version every release, store the artifact in your own registry, scan its dependencies and pin it wherever it is used.
How custom generators work
The customization docs describe creating a new generator, compiling it with Maven, and running it by adding its JAR to the Java classpath next to the CLI JAR and calling the main class. They also describe installing it into a local Maven repository and listing it as an additional dependency of the Maven plugin, then using its name as the generator name.
That means your generator JAR becomes executable code inside the build, with the same permissions as the build itself.
The checklist
| Area | Check |
|---|---|
| Source | Lives in a repository with required reviews and protected branches |
| Versioning | Each release has a unique version, never overwritten |
| Build | Built by CI from a tagged commit, not from a laptop |
| Storage | Published to your internal registry, not copied by hand |
| Consumers | Every project pins the exact generator version |
| Dependencies | The generator's own libraries are inventoried and scanned |
| Templates | Embedded templates reviewed like production code |
| Output | Generated code goes through the same scans and review as other code |
| Access | Few people can publish a new release |
| Rollback | Previous versions stay available |
Walking through the important rows
Never overwrite a version. If consumers pin 1.0.0 and you republish different bytes under that number, pinning proves nothing. Use a new version for every change.
Build in CI. A laptop build can include local files and tools you cannot reproduce. A CI build from a tag is traceable.
Scan the generator itself. The generator is a Java project with dependencies. A vulnerable library inside it can matter in your pipeline even though it never ships to customers. The code runs where your credentials and source live.
Review embedded templates. They decide what ends up in every consumer. See custom templates and who to trust.
Limit publishing rights. Whoever can publish to the registry can change what every pipeline runs next time it updates. Protect it like a release key.
For consumers of a private generator
- Record the generator version in the repository and make CI check it.
- Treat an upgrade as a normal dependency change with its own pull request, as in how to upgrade without surprises.
- Keep the generator out of any step that holds deploy credentials.
- Run the regenerate-and-compare check described in commit or generate at build time.
Where Safeguard fits
Safeguard's SBOM and dependency scanning can cover the repository that builds your generator, and policy gates apply to changes to it. Asset discovery helps you find which repositories use it.
Quick check
Is a private generator more risky than the public one?
Not inherently. The difference is that you own its review, release and scanning, which the public project's maintainers otherwise handle.
Do I need to scan a tool that never ships to customers?
Yes. It runs in your build, where credentials and source code are available.
Sources
Last reviewed: 19 October 2026.
