Treat a community Backstage plugin as code that will run inside your portal backend and browser app. Check who maintains it, read what it does with tokens and network calls, inspect its dependencies, confirm it supports the permission framework, and test it in a sandbox portal before production.
Why the stakes are higher than a typical library
Backstage's documentation shows that adding functionality means installing a package into your own repository, for example with yarn --cwd packages/backend add and then registering the module with the backend. After that the code runs in your backend process, alongside the catalog and any integration tokens you configured. The plugin directory helps you find community plugins, but a listing is discovery, not a security review.
Integrations are especially sensitive. The GitHub integration configuration takes a token that is passed along with all calls to that provider, and without one access is anonymous. A plugin that talks to source control, CI or a cloud account is going to want something similar.
A vetting checklist
| Check | What you are looking for |
|---|---|
| Source and maintainers | Public repository, named maintainers, recent commits, responsive issues |
| Package contents | The published package matches the repository; no surprising install scripts |
| Dependencies | A short, recognizable list; no abandoned or typosquat-looking names |
| Credentials | What tokens it needs and the narrowest scope that works |
| Network behavior | Which hosts it calls, and whether any call is unexplained |
| Permission support | Declares resources and actions so your policy can gate them |
| Upgrade path | Compatible with your Backstage version and its backend system |
Steps
- Find the repository from the package page and compare versions. Do the tags line up with what npm serves?
- Read the entry points. Backend modules are where network and credential handling live. Search for
fetch,axios,child_process, environment variable reads and any dynamic code loading. - List the dependency tree and run a scanner. Our post on dependency inventories explains why transitive packages matter more than the one you named.
- Decide the token scope. If the plugin asks for a broad personal token, look for a narrower option. GitHub's docs recommend fine-grained personal access tokens over classic ones where possible, and note that either type is tied to the user who created it and becomes inactive if that user loses access.
- Check permission integration. The permission framework lets plugin authors declare resources and actions, but only if they implement it. A plugin without it will be reachable by anyone who can reach the portal.
- Install in a throwaway Backstage instance first. Watch outbound traffic and the logs.
- Record the decision: who approved it, which version, what it can access, review date.
Maintenance matters as much as install
A plugin that is fine today can be abandoned in six months. Put each community plugin on a short owner list and revisit it when you upgrade Backstage. If the maintainer disappears, you should know whether you can fork it or replace it.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how many packages sit under the one you chose to add.
Where Safeguard fits
Safeguard's SBOM and dependency scanning, with reachability analysis to show which findings your code can actually hit, applies to a portal repository the same as any other. The free scan is at gold.safeguard.sh/scan.
Quick check
Does being in the Backstage plugin directory mean a plugin is reviewed?
The directory is a place to find plugins. Nothing in the documentation we read describes a security review, so do your own.
Where does a backend plugin run?
In your own backend process, after you add the package and register it. That is why its dependencies and tokens belong in your review.
Sources
- Introduction to plugins, Backstage documentation
- Built-in actions and installing action modules, Backstage documentation
- GitHub locations, Backstage documentation
- Permissions overview, Backstage documentation
- Managing your personal access tokens, GitHub Docs
Last reviewed: 19 October 2026.
