A Backstage software template can fetch a code skeleton, fill in variables, publish a new repository to a source host and register it in the catalog. Custom scaffolder actions are code, so they can do whatever you write into them. Review templates and actions the way you review a CI pipeline.
Definition
Software templates are the part of Backstage that helps people create components. The documentation describes them as loading skeletons of code, templating in variables, then publishing the result to locations such as GitHub or GitLab. A template is a series of steps, and each step can take its own inputs. Each run is a task with its own ID, and you can see past runs in the task list.
Built-in actions cover fetching content, registering in the catalog, and creating and publishing a git repository. Extra action modules exist for other hosts and tools, and you can write your own.
Where the risk sits
| Part | What it can do | Review focus |
|---|---|---|
| Template YAML | Chooses steps and passes user inputs into them | Which actions it calls, which inputs reach which fields |
| Skeleton files | Becomes the starting code of every new repo | Insecure defaults copied everywhere |
| Built-in publish actions | Creates repositories with the portal's credentials | Which org, which visibility, which token scope |
| Custom actions | Arbitrary Node.js code on the portal backend | Everything: filesystem, network, secrets |
| Action modules from packages | Third-party code added to the backend | Same checks as any plugin |
The skeleton deserves special attention. If it ships a permissive workflow file or an old dependency, you have just replicated the problem into every new service. We cover safe skeleton content in a separate post on secure defaults for Backstage templates.
Custom actions are backend code
The documentation's example action writes a file using a helper that resolves a path safely inside the task workspace. That helper exists for a reason. An action that joins user input into a path without checking it can write outside the workspace. The same applies to shelling out with user input, fetching URLs the user supplies, and logging values that might be secrets.
Review steps
- List every template and the actions each one calls. The portal shows registered actions at the create/actions page.
- For each user input, trace where it ends up. Names and descriptions are low risk. Repository URLs, branch names and file paths are not.
- Read custom actions as you would a privileged service. Look for path joins,
execcalls, outbound requests and secret handling. - Check what credential the publish step uses. A token that can create repositories in an entire organization is more than most templates need.
- Restrict who can run which template with the permission framework, and who can edit template definitions through their source repository.
- Review changes to templates in pull requests with the same rigor as pipeline changes. A template change is a change to every future repo.
- Keep an eye on the task list for unexpected runs.
Controls around the template
Because templates are defined in repositories, branch protection and code owners on the template repo are your main control over what the portal can do. The docs also note that you can disable the Register Existing Component button through route bindings if you want fewer ways to add things to the catalog.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a change is checked before it can merge, the same place a template change should be checked.
Where Safeguard fits
Safeguard's policies, gates and guardrails can check dependency and configuration changes in repositories before merge, and SBOM scanning covers the packages in a template skeleton. The free scan is at gold.safeguard.sh/scan.
Quick check
Can a scaffolder action run arbitrary code?
Custom actions are code you or a package author writes and runs on the backend, so yes. That is why the review treats them as privileged code.
Why review the skeleton and not only the YAML?
Because the skeleton becomes the starting point of every new repository, any insecure default is copied each time a template runs.
Sources
- Backstage Software Templates
- Builtin actions, Backstage documentation
- Writing custom actions, Backstage documentation
Last reviewed: 19 October 2026.
