Backstage security hardening starts before the portal holds real credentials
Hardening a Backstage instance means deciding three things before engineers log in: who can read and change what in the catalog and templates, how each integration authenticates to GitHub or GitLab, cloud accounts and other systems, and how security patches reach production. These decisions are easier to make on an empty instance than after the portal already holds tokens and has been shared with hundreds of users. A platform or security team about to put Backstage in front of engineers should treat them as a design review, with written answers that the team can later check against the running configuration.
The work is harder than it looks for three reasons. First, the portal aggregates access. A single instance can read repository metadata, show pipeline and deployment state, reach Kubernetes clusters through the Kubernetes plugin, and expose TechDocs, so a weak permission model in one place exposes many systems. Second, software templates can create infrastructure. A template that opens a repository, a pipeline or a cloud resource runs with whatever credentials the scaffolder holds, so the scope of those credentials and the actions a template may call are security decisions, not only developer experience choices. Third, Backstage is open source under the Apache License 2.0, with no paid edition from the project itself. Your team owns the configuration, the authentication setup and the patch cadence. Nobody else will tighten those settings for you.
Patch timing is part of the design. The Backstage release and versioning policy ships a main release line monthly and a next release line weekly. The project states that high and critical severity vulnerabilities will always be backported to releases from the last 6 months where feasible, and that other security fixes may be backported. That makes the last six months of releases the window where you can expect a backport, not a guarantee for older lines. Ask your team to confirm which release line you run, who watches the GitHub releases page and the security advisories, and how long a critical fix may take to reach production in your change process. Those answers set how far behind your instance can safely drift.
Before the portal holds real credentials, record the decisions in a short hardening baseline: the sign-in providers and the resolver that maps each one to a single identity, the decision to disable guest access in production, the permission policy for catalog reads and writes and for template execution, the integration tokens and their scopes, the secret store that supplies them, and the owner and schedule for version bumps. Then verify each item in a non-production environment with test accounts that have the lowest privileges you plan to grant. A baseline written this way gives auditors, security reviewers and future maintainers the same facts to check.
Two inputs decide how much of this work is needed in your environment: the number of integrations that receive credentials and the number of templates that can create infrastructure. Each integration adds a token to rotate, a scope to justify and a failure mode to test. Each template that touches cloud accounts adds a review step to design. When you request a quote for this work, ask the partner to list the integrations, templates and permission rules in scope, the verification steps for each, and what remains your team's responsibility after handover.
Which Backstage components carry the security risk
A Backstage instance concentrates identity, credentials and write access in a handful of components. Each card below names one of them, what it does and the control a hardening review should confirm before the portal serves real users.
Permission framework
The permission framework decides which signed-in user can read, change or run each catalog entity, template and plugin action. Without it, any authenticated user can see or modify more than their role requires. Review the permission policy for every plugin that exposes data, and confirm that deny is the default for anything not explicitly granted.
Authentication providers and sign-in resolvers
Backstage ships 19 built-in authentication providers, and each one can admit a user under a different identity. Sign-in resolvers map the provider's identity to a catalog user, so a weak resolver lets one account impersonate another. Confirm that every provider resolves to the same identity and that guest access is disabled outside development.
Backend and service-to-service calls
The backend hosts every plugin and calls other services on its own behalf and on behalf of users. Those calls need their own authentication, separate from the user session, so a plugin cannot reach another plugin's endpoints by accident. Map which backend services call which, and confirm each call is authenticated and scoped.
Proxy endpoints that forward credentials
The proxy plugin forwards requests from the portal to internal systems and can attach stored credentials to them. A misconfigured route can expose an internal API to any signed-in user or leak a token to an unintended host. Review every proxy route for its target, its allowed methods and the credential it injects, and keep the list short.
Integration credentials for source control and cloud
Catalog ingestion, TechDocs and scaffolder actions use tokens for source control hosts and cloud accounts. Broad or long-lived tokens turn a portal compromise into access to every repository or account the token reaches. Issue each integration the narrowest scope it needs, record its owner, and plan rotation before go-live.
Scaffolder actions that write repositories and pipelines
Software Templates run scaffolder actions that create repositories, pipeline definitions and infrastructure from a form. Because these actions write to production-adjacent systems, a template change or a custom action can change far more than the form suggests. Limit which actions each template may run, require review for templates that write to shared repositories, and log every action run.
PostgreSQL database and plugin databases
Backstage uses PostgreSQL in production and gives each backend plugin its own logical database through Knex. Those databases hold catalog data, plugin state and, for some plugins, credentials or session data. Confirm that each plugin role can reach only its own database, that connections use encryption, and that backups are protected to the same standard as the live data.
Cache layer
Backstage supports Redis, Memcache, Infinispan or in-memory caching. A shared cache can hold API responses and session-related values that some users should not see. Confirm which data the cache holds, that it is reachable only from the backend network, and that it requires authentication in production.
Decisions to make before hardening settings
This table compares the five decisions that shape a Backstage security posture, with the options on each side and what each one asks of your team to run. Read each row as a choice you make once and then live with, and note who owns the ongoing work for every option.
| Decision | When it fits | What it costs you operationally |
|---|---|---|
| Permission policy scope | Allow-all during early rollout, when the catalog and templates are still being shaped and few users depend on them | Allow-all gives no gating of catalog reads, template runs or actions, so you must plan a switch to a custom policy before production use |
| Permission policy scope (custom) | Production portals where template runs and actions touch repositories, cloud accounts or pipelines | A platform engineer owns the policy file, must test it against each plugin upgrade, and must answer access requests as teams change |
| Sign-in model: one provider | One corporate identity provider with a single sign-in resolver mapping users to catalog entities | One resolver to write and maintain, and changes to the identity provider or group structure must be reflected in that resolver |
| Sign-in model: several providers | Teams that already use more than one provider, such as a code host login alongside corporate SSO | Every provider needs a resolver that maps to the same identity, so each added provider is another mapping your team must test and keep consistent |
| Integration credential type: personal tokens | Short pilots run by one engineer where speed matters more than ownership | Tokens tied to one person break when that person leaves, and rotation falls to whoever holds the token, often with broad scope |
| Integration credential type: GitHub Apps or service accounts | Production integrations that read catalog sources or create repositories with narrow, auditable permissions | Someone must provision the app or account, scope its permissions, store its key and rotate it on a schedule your security team sets |
| Scaffolder governance: open templates | Small groups where every engineer is trusted to create repositories and pipelines from any template | Fewer review steps, but template changes can reach production without an owner, and actions run with the portal's credentials |
| Scaffolder governance: owner-approved templates | Organizations that want golden paths to meet security, naming and pipeline standards before use | A named template owner approves changes, review adds lead time to each update, and owners must keep templates aligned with policy |
| Secrets source: environment variables in deployment config | Early environments or small deployments where the platform already injects configuration securely | Values sit in deployment manifests or CI settings, so rotation means redeploying, and access to the deployment system equals access to the secrets |
| Secrets source: external secret manager | Production deployments that already run a secret manager and need audited access and central rotation | Platform engineers wire app configuration to secret references, and the secret manager becomes a dependency your on-call team must cover |
How to harden a Backstage deployment step by step
This sequence moves a Backstage deployment from default settings to a configuration you can test against its own access, credential, and patching decisions. Each step closes with a check you can run and record. The result is a documented baseline that your security team can verify and your platform team can keep current.
Inventory credentials and assign owners
Before changing any settings, list every integration, plugin, and software template that holds or uses a credential, such as source control tokens, cloud keys, Kubernetes access, or database connections. Record the owning team and the external system each credential reaches. Build the list from the app configuration files and the secret store, not from memory, by searching both for each integration name. Your platform team carries out this step with input from the teams that own each integration. It is done when every entry has a named owner and a reviewer has signed off on the list. Steps 4 through 7 use this inventory as their work list.
Disable guest access and check sign-in
Remove the guest provider from production configuration and confirm that the identity provider you chose is the only sign-in path. Then review each sign-in resolver so that every provider maps a person to the same user entity, and so that a user who signs in through one provider cannot claim the identity of another. In staging, sign in with two test accounts through each provider, record the resolved user reference, and attempt to link one test identity to a second provider. Full identity integration is covered in the SSO topic, so this step checks the controls only. It is done when guest sign-in is refused and the resolved identities match the expected entities.
Define a deny-by-default permission policy
Write the permission policy with the Backstage permission framework so that any action not explicitly allowed is refused. Scope the rules to four areas: catalog reads, catalog changes, template runs, and plugin actions. Grant broad access to administrators only where the relevant owner has approved it, and document each exception. Test every rule with a sample non-admin account in staging, recording the expected and actual outcome for both allowed and denied actions. Keep the policy file in version control so changes go through review. It is done when each rule has a passing allow test and a passing deny test, and a second engineer has reviewed the policy.
Replace broad integration tokens with scoped credentials
For each credential in the inventory, issue a narrower replacement, such as a fine-grained token or app installation limited to the repositories, projects, or namespaces the plugin needs. Remove write permissions where the plugin only reads data. Check each new credential by calling the integration from the plugin's context, confirming it reaches the intended repositories and fails on a repository outside its scope. Confirm the rotation procedure for each credential is written down, and then revoke the old broad token. It is done when every replacement passes both the allowed and denied checks and the old token no longer works.
Review proxy endpoints and backend calls
List every proxy entry and every backend-to-backend call. For each one, confirm it forwards only the headers and credentials it needs, and that a user's session token is never passed to a third-party host. Remove or restrict any forwarded authorization that does not have a documented purpose. Then test from an external browser session by requesting each internal backend path directly, and confirm the request is refused. Your security team or a qualified tester should run this check, since it depends on network placement. It is done when each proxy entry has a documented purpose, the forwarding behavior is verified, and internal routes refuse browser requests.
Restrict templates and scaffolder actions by owner
Limit each software template to the owner group that maintains it, and allow only the scaffolder actions that template requires. Add a review step to any template that creates infrastructure, so a person approves the generated change before it is applied. Run a template as an unprivileged user in staging and confirm it fails at the expected point, with the refusal recorded in the logs. Then run the same template as a member of the owner group and confirm it succeeds. It is done when the unprivileged run is refused, the owner run succeeds, and every infrastructure template includes its review step.
Move secrets out of configuration and logs
Move every secret value from committed configuration files into the secret store you selected, and reference it by environment variable or secret reference. Then search the output for exposure. Scan logs, catalog entities, and TechDocs builds for each secret value and for common token patterns, and fix the source of any hit rather than only deleting the output. Your platform team carries out this step, and the security team verifies the scan. It is done when the committed configuration contains no secret values, the scan of the repository and generated outputs finds none, and the rotation procedure is documented.
Set a patch intake and security release path
Name the person or team who watches Backstage releases and security advisories, and define how those notices reach the platform team. Track the Node.js runtime against the Backstage versioning policy, which supports two adjacent even-numbered Node.js releases; as of Backstage 1.46.0, these are Node.js 22 and 24. The policy ships the main release line monthly and the next line weekly, and says high and critical vulnerabilities are backported to releases from the last 6 months where feasible. Apply each security release to staging first, rerun the permission and credential checks, and then promote it to production. It is done when the owner, the review cadence, and the staging-first promotion are written down, and one test release has passed through the path.
What drives the effort of a Backstage security review
This table lists the factors that change how much work a security review of a Backstage portal takes, why each one matters and how to keep it manageable. Read each row against your own environment, then use the largest drivers to decide which parts of the review to scope first. Most reviews grow fastest where credentials, templates and identity mapping overlap.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Integrations and plugins holding credentials | Each plugin that stores a token for GitHub, cloud accounts, CI or ticketing needs its scope, storage and rotation checked, so effort rises with every credential-holding plugin. | Start with a short list of high-risk integrations, such as those with write access to source or cloud, and review the rest later in a second pass. |
| Templates that create infrastructure or pipelines | Scaffolder templates can open repositories, write pipelines and provision resources, and each action they call must be reviewed for the permissions it runs under. | Limit template governance to infrastructure-creating templates first, and leave documentation-only or static templates for a later phase. |
| Identity providers and groups that need mapping | Every sign-in provider needs a resolver that maps to one identity, and every group must map to the right catalog owner and permission role, so more providers and groups mean more mapping cases to test. | Confirm the number of providers in use, retire unused ones, and map groups from a single source of truth such as your directory. |
| Teams that need distinct permission rules | Each team with its own access rules adds conditions to the permission policy, and conflicting rules are harder to find and prove correct. | Reuse a single permission policy template and add team-specific conditions only where a team's data or actions truly differ. |
| Existing governance such as a CMDB or access approval | If access must be approved in a ticketing system or recorded in a CMDB, the review must confirm that Backstage decisions match those records and that exceptions are traceable. | Ask which system is the record of ownership and approval, and point Backstage data at it rather than duplicating it by hand. |
| Environment count (development, staging, production) | Each environment has its own configuration, secrets and sign-in settings, and drift between them is a common source of findings. | Keep one configuration structure across environments and review only the differences between them. |
| Compliance scope requiring logged access decisions | If a framework requires evidence that access decisions are logged and reviewable, the review must confirm audit events are emitted, stored and retained for the required period. | Confirm the evidence the assessor expects before the review starts, and test one sample of each log type end to end. |
| Air-gapped or restricted networks | Where the portal cannot pull updates directly, security patches and dependency updates must be transferred manually, which adds steps to every patch cycle and to the review of each transfer. | Agree a patch intake procedure in advance, and confirm with your upgrade partner which Backstage release lines are supported for offline use. |
How hardening changes by deployment model
A single-instance deployment runs one backend process with one database connection path, so most hardening work concentrates on the host and the process. Secrets usually reach the process through environment variables or a mounted file managed by the host, and the main question is who can read that host, its process environment and its configuration directory. Session and cache state live in the one process, which simplifies correctness but means a restart clears in-memory state and a compromised host exposes everything the process holds.
The areas to check for this model:
- Secret delivery: confirm secrets are loaded from a store the host controls and are not written into committed configuration files or container images.
- Host access: limit shell and file access to the portal host, and log administrative access to it.
- Network exposure: restrict inbound traffic to the frontend and API paths users need, and keep the database reachable only from the backend.
- Patch path: plan how a security release reaches the single process, including a maintenance window, because there is no second replica to take traffic during the restart.
- Backend-to-backend traffic: with one process there is little internal traffic to limit, but any separately deployed plugin backend still needs an explicit allow rule.
Confirm the exact configuration keys for secrets and authentication in the Backstage documentation for your installed version before you write deployment manifests.
A high-availability deployment runs several backend replicas behind a load balancer, so every replica must produce the same answers for the same user. That makes shared state a security concern as well as an availability concern: session data, cache entries and scheduled task coordination must be shared through components that are themselves secured, not left in local memory where one replica could serve stale permissions. Secrets must be identical across replicas and rotated without a partial rollout that leaves some replicas on old credentials.
The points that change in this model:
- Secret injection: deliver the same secret set to every replica from one managed source, and plan a rotation that updates all replicas in one controlled change.
- Shared cache and sessions: choose a shared cache backend, restrict its network access to backend replicas, and require authentication to it.
- Backend-to-backend traffic: restrict which replicas and plugin backends can call each other, and deny traffic from unrelated workloads to the cache and database.
- Patch rollout: roll replicas one at a time so a bad release is caught before it affects every user, and keep the previous image available for rollback.
- Session consistency: verify that a permission change takes effect on every replica within the cache lifetime you accept.
Confirm the cache and session configuration keys, and which components are supported as shared backends, in the Backstage documentation for your version.
In a Kubernetes deployment, many hardening controls move into cluster objects. Secrets are typically delivered through the Kubernetes secret mechanism or an external secret operator, and access to them is governed by role-based access control and namespace boundaries. Network policy becomes the main tool for limiting backend-to-backend traffic, because every pod can otherwise reach other pods in the cluster by default, depending on your cluster network plugin. Container image provenance and admission controls also become part of the patch process.
The items to design for this model:
- Secret injection: prefer an external secret source that syncs into namespaced secrets, and restrict which service accounts can read them.
- Network policy: define ingress rules so only the frontend, the approved plugin backends and the monitoring stack can reach each backend pod, and confirm your network plugin enforces these policies.
- Service account scope: give the portal pods only the Kubernetes permissions the Kubernetes plugin needs, and review them against the plugin's read requirements.
- Image patching: rebuild and redeploy images from a pinned base, and verify image signatures or digests before admission if your cluster enforces them.
- Pod hardening: run as non-root with a read-only root filesystem where the application allows it, and confirm this against your image.
Verify network policy with real connection tests from non-permitted pods, and confirm the Kubernetes plugin and secret configuration keys in the Backstage documentation for your version.
In an air-gapped or restricted network, the portal cannot pull packages, images or vulnerability data from public registries, so the patch process depends on what your team brings across the boundary. Dependencies, container images and Backstage release packages must be mirrored or transferred through an approved path, and each artifact should be verified against the source before it is installed. Secrets often cannot be fetched from a cloud service, so they are delivered through an internal secret store or a controlled file process. Outbound connections for authentication providers, telemetry or plugin data sources may be blocked, which changes how sign-in and integrations are tested.
What changes in this model:
- Secret delivery: use an internal secret store reachable only from the portal network, and document how secrets are issued and rotated without internet access.
- Patch intake: mirror the Backstage release tags, Node.js runtime and package dependencies through an approved transfer process, and record the checksum or digest of each transferred artifact.
- Verification: check each transferred release against the published release notes and the versioning policy before promotion, including high and critical fixes that Backstage states it will backport where feasible.
- Egress and integrations: block outbound traffic by default, then open only the internal sources and identity providers the portal needs, and test each path.
- Backend-to-backend traffic: enforce allow lists between internal services, since no external dependency is available to mask a misconfiguration.
Confirm which Node.js and Backstage versions your mirror must hold, and the offline configuration options available, in the Backstage documentation for your release.
Access control and secrets handling for the portal
These controls decide who can change what in the portal, which credentials it holds, and whether anyone can later reconstruct what happened. Each card names the control, the failure it prevents and the team that should own it, so the access model can be reviewed as part of the Backstage security hardening work rather than after an incident.
Permission policy ownership and review
Assign one named owner to the Backstage permission policy and require a second reviewer for every change to it. The failure this prevents is a quiet policy edit that lets a group read or run templates it should never reach. Owner: the platform team lead, with security reviewing changes to access rules.
Least-privilege integration credentials
Give each integration token, such as those for source control, cloud accounts or ticketing, only the scopes its plugin needs, and record which plugin uses which credential. The failure this prevents is one broad token being reused across catalog ingestion, scaffolding and TechDocs publishing, so a leak exposes everything. Owner: the platform engineering team, with each integration's system owner approving scopes.
Secrets stored outside repository configuration
Keep credentials in a dedicated secrets store and reference them from app configuration at runtime, so the app-config files in version control contain no live values. The failure this prevents is a secret committed to a repository, where it persists in history even after deletion. Owner: the platform team, with the security team confirming the store and access policy.
Credential rotation schedule
Document a rotation interval and procedure for every integration credential and confirm the portal can pick up a rotated value without a rebuild. The failure this prevents is a credential that never changes after it is first issued, so one exposure stays valid indefinitely. Owner: the platform team, with the rotation schedule agreed by the security team.
Network restriction on internal backend endpoints
Limit which networks and services can reach internal backend endpoints, and keep them off public ingress unless a specific route requires it. The failure this prevents is an internal API being called directly from outside the portal's trust boundary, bypassing sign-in. Owner: the infrastructure team, with the platform team listing the required routes.
Separation of production and non-production credentials
Use separate credentials, and separate integration targets, for development, staging and production portals. The failure this prevents is a test deployment with production write access, where a template run or plugin error changes live systems. Owner: the platform team, with the cloud and source control administrators maintaining the accounts.
Audit of template runs and permission decisions
Retain logs of software template executions and permission decisions, and confirm who can read them and for how long. The failure this prevents is being unable to explain who created a repository or granted access during an investigation. Owner: the security team for retention and access, with the platform team ensuring the logs are emitted.
Patch intake tied to the backport statement
Set a patch intake rule that treats high and critical fixes as urgent, using the versioning policy's statement that these are backported to releases from the last six months where feasible. The failure this prevents is running a release line that no longer receives the security fix you are waiting on. Owner: the platform team, with security approving the upgrade window for urgent fixes.
How to test that Backstage hardening works and fails safely
A hardening change is only finished when a tester has tried to break it and recorded what happened. For a Backstage portal, the test plan should cover five areas: authorization, sign-in, integration credential scope, secrets exposure and failure behavior. Each area needs a named test, an expected result written before the test runs, and an evidence record that a later reviewer can trace back to the configuration version that was tested. Treat the plan as part of the hardening deliverable, not as a final check that happens once the portal is live. Start with negative authorization tests. Create an unprivileged test user who belongs to no privileged group, then attempt catalog edits, Software Template runs and plugin actions that the permission framework is meant to block. Each attempt should return a denial, and the denial should be confirmed in the backend logs and in the response the user sees. Repeat the same attempts with a user in the intended owner group so the tests also prove that legitimate access still works. A denial that only appears because the test account is misconfigured proves nothing. Sign-in tests need one case per identity provider you have enabled. For each provider, confirm that a real user from your directory signs in, that the sign-in resolver maps that user to the expected catalog identity, and that a second provider login for the same person resolves to the same identity rather than creating a duplicate. Separately, confirm that guest access is unavailable: the guest sign-in path should not appear in the login page, and a direct request to the guest endpoint should fail. Confirm the exact provider versions and resolver code with your own team, since the set you run depends on your environment. Credential scope tests are the most often skipped and the most useful. For each integration token the portal holds, such as a source control, cloud or CI token, call the integration from the portal's backend with that token against a resource outside its intended scope. The call should fail. Record the request, the scope or permission the token was issued with, and the failure response. Then run one in-scope call to show the integration still works. Secrets scans should cover the configuration repository, backend and proxy logs, and the rendered TechDocs site. Any credential string found in those places is a failed test, and the finding should be traced to the code path that produced it. The last two tests exercise behavior under change and failure. Run a Software Template in staging with a deliberately unapproved change and confirm that the review step blocks it before any repository or pipeline is created. Then run a failure drill: revoke one integration credential in staging and observe the portal. It should show a neutral degraded state, and the error page and logs should not reveal token values, internal hostnames or stack traces to ordinary users. Keep each test's inputs, expected result, observed result, timestamp, tester and the commit or configuration version under test. Those records let auditors and internal reviewers trace a control to its evidence without relying on memory.
What to monitor, back up, patch and document after hardening
This table lists the recurring work that keeps a hardened Backstage deployment secure after go-live, with the area, the action it requires and a suggested review rhythm. Frequencies are suggestions for your team to set, so adjust them to your change volume and risk appetite. The main takeaway is that patch timing depends on the monthly and weekly release lines, the backport statement and the Node.js versions the policy supports, so track all three against your upgrade schedule.
| Area | What to do | How often to review |
|---|---|---|
| Permission policy changes | Log each change to the permission policy with its requester and approver. Confirm the running policy matches the approved version. | Each change, plus a recurring check your team sets |
| Integration credentials | Inventory every token and key used by integrations, with its owner and expiry date. Rotate before expiry and record the rotation. | Expiry dates tracked continuously, rotation on a schedule your team sets |
| Sign-in and audit logs | Review sign-in failures, denied permission decisions and sign-in resolver errors. Forward logs to your central log store. | Alerts as they occur, with a recurring review your team sets |
| Backstage releases | Track the monthly main release line and the weekly next line. Check the versioning policy's backport statement for each security fix. | Monthly for main, weekly for next, and on each published high or critical advisory |
| Node.js version support | Confirm the running Node.js version is one of the two adjacent even-numbered releases the policy names for your Backstage version. | At each Backstage upgrade and whenever the policy's supported versions change |
| Plugin database and secret references | Back up the PostgreSQL database that holds plugin data. Back up configuration that references secrets, not the secret values, encrypted and separately controlled. Test restores. | Backup schedule and restore test cadence set by your team |
| Documentation | Keep the permission policy, credential inventory and patch runbook current, with named owners and last review dates. | After each policy or credential change and at each Backstage upgrade |
Questions teams ask before hardening Backstage
How much does Backstage security hardening cost?
The cost follows from the scope agreed in writing, not from a standard package. Backstage is Apache-2.0 open source with no paid edition from the project, so the spend is almost entirely people time and the infrastructure you already run. One-time work includes the baseline review, permission policy design, service-to-service authentication, integration token scoping, scaffolder action limits, and moving secrets out of configuration. Recurring work includes reviewing each upgrade, checking new plugins, and re-testing after changes. Costs rise with the number of plugins, identity providers, templates that call external systems, and undocumented existing configuration. Ask for a quote that lists each workstream, the systems in scope, the evidence delivered, and which items are optional. DeployOpen does not publish a price list, and a quote follows from the written scope.
How long does Backstage security hardening take?
The duration depends on scope: how many plugins are installed, how many sign-in providers are configured, how many templates run custom actions, and how far the current deployment already matches the documentation. The work usually moves through discovery, a baseline review, changes in staged environments, verification, and handover. Ask for a plan with milestones, dependencies, and named client actions, such as access to identity provider administration or cloud accounts. Confirm with the partner how long each phase is expected to take in your environment, and what happens if a dependency slips. Keep in mind that hardening does not end at handover. Monthly main releases mean the work needs a cadence after the project closes, so ask how the first upgrade cycle is handled.
What does a Backstage hardening project need from our team?
Expect to name an accountable owner, plus several people with specific access and decisions. Identity: someone who administers your sign-in provider, so sign-in resolvers can map every provider to the same identity. Platform: engineers who own the hosting, deployment pipeline, and secrets store. Security: a reviewer who approves authorization decisions and integration token scopes. Plugin and template owners: people who confirm the intended behavior of what they run. You also need a non-production environment that mirrors production closely enough to test changes. Ask the partner to list these roles and time commitments in the written scope, and to state which decisions your team must make before implementation starts.
Can our own engineers harden Backstage without a partner?
Yes, many teams can. The code is open source, and the project publishes its authentication and upgrade documentation. The deciding factors are skills and capacity: Node.js and TypeScript, the hosting platform, identity protocols, and the security review needed to make authorization decisions. The trade-off is ongoing ownership. Your team learns the configuration, but it also carries every future upgrade, plugin review, and security patch. A partner can run the initial hardening and transfer knowledge through documentation, pairing, and runbooks. Ask for a clear list of what would be handed over, including configuration records, test cases, and an upgrade procedure your staff can run without outside help.
Do we need a permission policy on day one?
Not for every feature on day one, but you need authorization decisions before the portal holds production-facing data or lets people run templates that create resources. The authentication documentation advises against offering guest access in production, which removes one common gap. Start with deny-by-default decisions for the most sensitive actions: running templates, editing catalog entities, changing ownership, and reading integration data. Expand the policy as plugins mature. Before you commit, confirm which permissions each plugin you plan to use supports, and document any gap as a named risk with an owner. Ask the partner to show how policy changes are tested before they reach production.
How do we keep up with Backstage security releases?
The project ships a main release line monthly, on the Tuesday before the third Wednesday of each month, and a next release line weekly on Tuesdays. Its versioning policy says high and critical vulnerabilities will always be backported to releases from the last six months where feasible, and other security fixes may be backported. That means an installation that falls outside the window may not receive fixes. Node.js support is also limited to two adjacent even-numbered releases, which are Node.js 22 and 24 as of Backstage 1.46.0. Upgrades move @backstage packages together with versions:bump, and the Upgrade Helper shows template changes. Agree on a cadence, an owner for each release, and a test process before go-live.
Does Backstage security hardening make us compliant?
No. Hardening does not make any organization compliant, and DeployOpen does not issue audit reports, attestations, or certifications. Independent auditors and certification bodies make those determinations. What DeployOpen can do is prepare systems and evidence for assessment: documented access controls, configuration records, test results, and change history that your auditor reviews. Before the work starts, ask your assessor which frameworks and evidence they accept, then map those requirements to the scope in writing. Confirm with your assessor how they want evidence packaged and retained. Treat hardening as one input to your compliance program, not as the outcome of it.
How DeployOpen scopes, hardens and hands over Backstage
DeployOpen plans, hardens, documents and supports self-hosted Backstage inside your own infrastructure, starting from a written scope that names the permission, authentication, token, template and secrets controls to be reviewed. Work is delivered as a fixed-scope engagement, with optional retainer support for ongoing upgrades and testing after handover.
How we scope
- We review your current Backstage version, plugin list and deployment to identify which hardening areas apply.
- The written scope lists the permission policies, auth providers, token scopes and scaffolder actions to be covered.
- We agree which components are out of scope, such as custom plugins you own, so the boundary is clear before work starts.
How we build
- We configure the permission framework and sign-in resolvers so each provider maps to one identity and guest access is removed.
- We narrow integration and proxy token scopes, restrict scaffolder actions and move secrets into your approved secrets store.
- We test each control in a non-production environment and record the results against the agreed scope.
How we hand over
- You receive configuration documentation covering policies, resolvers, token scopes, scaffolder limits and secrets locations.
- Your team walks through the controls and the verification steps so they can reproduce checks after handover.
- We provide a runbook for keeping Backstage patched, including how to track high and critical security backports on your Node.js version.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
- Retainer work can cover applying Backstage security releases and re-checking hardened controls after version bumps.
- Ask any provider to confirm which items the retainer covers and how quickly security fixes are handled before signing.
