# Backstage Scaffolder Template Review

> Use this skill when reviewing Backstage Scaffolder software templates. Trigger when the user asks whether a template is safe for developer self-service, whether template RBAC gates are in place, whether input parameters are validated, whether a step action has excessive blast radius, or whether template outputs expose secrets.

- Skill: `vincentchuwaichow/backstage-scaffolder-template-review` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add vincentchuwaichow/backstage-scaffolder-template-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vincentchuwaichow/backstage-scaffolder-template-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: VincentChuWaiChow (https://skillmd.com/u/vincentchuwaichow)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/vincentchuwaichow/backstage-scaffolder-template-review

---


# Backstage Scaffolder Template Review

## Purpose

Review Backstage Scaffolder `Template` kind resources for action blast-radius, input parameter injection risk, RBAC permission gate coverage, integration secret scope, catalog entity poisoning via `catalog:register`, and plaintext secret exposure in `output:` stanzas. Backstage Scaffolder gives developers a curated UI to trigger powerful backend actions — without RBAC gates and input validation, every authenticated developer effectively has write access to whatever the Scaffolder integration credentials can reach.

## Lean operating rules

- Prefer user-provided sanitized Template YAML as primary evidence; official Backstage docs are the authoritative fallback.
- Treat any `steps:` action that provisions real cloud infrastructure (Terraform, Crossplane CRD apply, CloudFormation deploy, `kubectl apply`) with no RBAC permission gate as a CRITICAL finding.
- Treat input parameters flowing unsanitized into `publish:github.repoUrl`, file-path actions, or shell-exec actions as a HIGH finding — path traversal and injection are realistic.
- Treat `publish:github` with `visibility: public` as the default or without an `allowedHosts` constraint as a HIGH finding.
- Treat `output:` stanzas exposing plaintext generated credentials, connection strings, or API keys in the Backstage UI as a HIGH finding.
- Treat the absence of `@backstage/plugin-permission-backend` policies for infrastructure-provisioning templates as a HIGH finding — any authenticated Backstage user can trigger them.
- Treat `catalog:register` accepting arbitrary user-supplied YAML without server-side entity schema validation as a MEDIUM finding — catalog poisoning overwrites ownership and lifecycle metadata.
- Keep the answer scoped: report what was reviewed, the evidence level, and exactly which steps or fields triggered each finding.

## References

Load these only when needed:
- [Workflow and output contract](references/workflow-and-output.md)

## Response minimum

- Scoped target (Template `metadata.name`) and evidence level
- Each `steps:` action type and its provisioning blast radius
- Input parameter validation gaps (missing `maxLength`, `pattern`, `enum`)
- RBAC permission gate verdict (present / absent / partial)
- Integration secret scope assessment
- `output:` stanza exposure assessment
- Safe next actions and open questions