Backstage threat model: a hardening checklist for operators

Check the project's current documentation and repository for threat model or security material, and record the version you read, because location and wording change between releases. Start with the backstage/backstage repository and the Backstage documentation, then search for security, trust boundary and threat model topics. Treat the project's material as the starting list for your own checklist. Add items for your network design, identity provider, storage, plugin set and internal templates, since no generic model can know those. Where the project's material is thin for an area you depend on, record that gap as an open item for your review.

Assign each item to one accountable team before work starts, because unowned items tend to stay open. Typically the platform team owns deployment, network exposure, patching, upgrades, token signing keys and secrets storage. The identity team owns sign-in providers and resolvers. The security team owns plugin approval, permission policies, audit log review and the SIEM feed. Application or plugin owners own their custom plugins, templates and actions. The catalog owners own registration rules and trusted data sources. Your organization's split will differ, so record each owner, the review cadence and the evidence that proves the control works.

No. The Backstage authentication documentation advises against offering guest access in production. Guest sign-in is useful for local development and evaluation, but a production portal should require sign-in through a real identity provider. Configure sign-in resolvers so every provider you enable resolves to the same user identity, which prevents one person from appearing as several catalog users. Then confirm that guest sign-in is disabled in the production configuration, and keep that setting in version control so a later change is visible in review. Ask your identity team to test sign-in with a user who has no catalog entry to confirm the resolver behaves as you expect.

The versioning policy says high and critical severity vulnerabilities will always be backported to releases from the last six months where feasible, and other security fixes may be backported. That means you must stay within that window to receive the backport, so plan upgrades as a recurring task rather than a one-time project. The policy describes a main release line shipped monthly and a next release line shipped weekly, so a monthly upgrade rhythm keeps you current with minimal drift. Confirm the current policy text before you set your own deadlines, and track the security advisories for the packages your deployment uses.

Vet each plugin before installation, because the project's backport commitment covers its own packages, not every community plugin. Check who maintains the plugin, how recently it was updated, which Backstage versions it supports, and which external services it calls. Review what permissions and tokens it asks for, and whether it exposes routes or proxies to upstream APIs. Pin versions, install through your normal change process, and keep an owner for each plugin who tracks its advisories. Expect some third-party plugins to lag behind core upgrades, and decide in advance whether you will fork, replace or remove a plugin that stops keeping pace.

The main drivers are the number of plugins you run, the number of integrations with source control, identity, cloud and ticketing systems, the complexity of your sign-in setup, and how much internal review capacity you have. Each additional provider, custom plugin or scaffolder action adds checks, and each integration adds credential handling to review. Your own capacity matters because a review stalls when owners cannot answer questions or approve changes. Ask any partner for a quote that lists each component: discovery, configuration review, testing, remediation support and handover, and whether each is one-time or recurring. No price is given on this page, so the figure depends on your written scope.

DeployOpen plans, implements, hardens and supports self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks, and it runs security testing for applications, APIs and infrastructure. A review of a Backstage deployment against a checklist like this one can be quoted from a written scope that names the systems, the checklist items and the deliverables. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen prepares systems and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, so independent auditors and certification bodies still perform those steps.

The cost depends on the written scope, not on a standard rate. DeployOpen works from a fixed scope agreed in writing before work starts, and a quote follows from that scope. The main drivers are the number of plugins to vet, how many auth providers and identity sources you run, whether scaffolder templates run on the host, how many upstream APIs sit behind the proxy, and whether audit events must reach a SIEM. Ask for the quote to split one-time work (threat model review, configuration changes, sign-in resolver design, key setup) from recurring work (patching, advisory tracking, periodic review). Backstage itself is open source under the Apache License 2.0, so the spend is services and internal staff time, not licenses.

Duration follows the number of items in scope and how many teams must make decisions. A review that covers only the configuration of one instance moves faster than one that also vets third-party plugins, rebuilds sign-in resolvers and wires audit logs into a SIEM. Ask for a timeline in the written scope with milestones for each checklist area and the points where your security, platform and identity teams must sign off. No duration is stated here because none has been supplied for this work.

Plan to provide access and decisions, not just documents. The inputs usually include the app-config files for each environment, the list of installed plugins and their versions, the auth providers and sign-in resolvers in use, the catalog locations and who may register entities, the scaffolder templates and actions, the upstream APIs reached through the proxy, and the logging and SIEM destinations. You will also need named owners for each control area and a staging environment where changes can be tested before production.

Yes, if the team has the time and the skills to read the threat model, test configuration changes and maintain them after each upgrade. The Backstage project publishes its versioning policy and upgrade guidance, so a capable team can start there. A partner adds most value on the items that need cross-team decisions, such as who may create Users, Groups and Templates, how URL readers are allow-listed, and how plugins are vetted before installation. Ask whether your team will own the result after handover and what documentation you will receive.

Ownership should be written into the checklist before work starts. Platform engineering usually owns network exposure, deployment, keys and secrets. Identity teams own auth providers and sign-in resolvers. Security owns the threat model, audit logging, plugin vetting approval and advisory tracking. Template authors and catalog maintainers own the content they publish, within limits set by the platform team. Each item should name one accountable owner and a review cadence so that gaps do not sit between teams.

Recurring work includes applying Backstage releases and security fixes, reviewing new or updated plugins, rotating keys and integration tokens, reviewing permission policies after catalog changes, and checking audit output. The Backstage versioning policy says high and critical vulnerabilities are backported to releases from the last six months where feasible, so an instance that falls behind that window must move to a supported release. Ask whether a retainer covers upgrades and continuous testing, and what is excluded.

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. A hardening review helps your team show how the portal is configured, who controls it and what evidence exists, which is useful input for whichever assessment you face.