Platform Engineering Security:
When the Golden Path Leads to Your Crown Jewels.

The IDP Explosion

Platform engineering has moved from a Spotify-scale novelty to a mainstream practice in a handful of years. The premise is straightforward: instead of every team solving the same infrastructure, CI/CD, and secrets problems independently, a dedicated platform team builds an Internal Developer Platform — a self-service layer that lets developers provision environments, deploy services, and manage secrets without needing deep platform expertise.

The most visible manifestation is the developer portal (Backstage is the dominant open-source option), but the IDP is more than a UI. It encompasses the scaffolding templates that generate new services, the pipeline templates that build and deploy them, the secrets management integration that injects credentials, and the RBAC system that controls who can do what. All of that capability in one place creates a security challenge that most platform teams have not fully modelled.

Centralised Blast Radius

Traditional application security focuses on limiting the blast radius of individual service compromises. Platform engineering inverts this — by design, the IDP has broad permissions because it needs to act on behalf of all the services it manages. The Backstage service account typically has write access to every GitHub repository in the organisation. The pipeline execution engine has credentials for every deployment target. The secrets broker has read access to every vault path.

When security teams audit individual microservices, they rarely audit the platform itself with the same rigour. The platform is treated as trusted infrastructure rather than as an application that can be attacked. In 2025, several high-profile breaches followed a pattern of compromising the platform layer to gain access to downstream services — a pattern the Gartner Platform Engineering Security report identified as an emerging threat class.

Service Account Scope Creep

Platform service accounts accumulate permissions over time. A Backstage integration that initially needed read access to the GitHub organisation slowly acquires write access (to create repositories), webhook access (to register CI triggers), and eventually admin access (to manage teams). Each addition is justified by a new platform feature. The result is a service account with near-admin permissions across the entire VCS that lives in a Kubernetes secret and is used by a web application accessible to all developers.

An attacker who gains code execution in the Backstage pod — through an XSS in the plugin UI, an SSRF in a scaffolder template, or a supply chain compromise of a Backstage plugin — inherits all of these permissions instantly.

Plugin Attack Surface

Backstage's plugin architecture is its strength and its weakness from a security standpoint. The plugin ecosystem has hundreds of community-maintained integrations. Each plugin runs in the same Node.js process as Backstage itself, with access to the same service account credentials and the same backend API. There is no sandbox boundary between plugins.

A malicious or compromised plugin can read every secret stored in the Backstage configuration, make API calls using the platform's service accounts, access the software catalog including internal service topology, and exfiltrate credentials to external endpoints. Plugin supply chain attacks are a realistic threat — several popular npm packages used as Backstage plugin dependencies have been found to contain malicious code in their transitive dependency trees.

SSRF via Scaffolder Templates

Backstage's scaffolder allows platform teams to create templates that developers use to bootstrap new services. Templates can include actions that make HTTP requests, execute scripts, and interact with external APIs. If template inputs are not sanitised, an attacker who can create or modify a template can inject SSRF payloads that cause the Backstage backend to make requests to internal services — including the cloud metadata endpoint at 169.254.169.254.

Golden Path Abuse

The "golden path" is platform engineering's term for the opinionated, supported way of doing something — a scaffolder template that creates a correctly configured service, a pipeline template that enforces security scanning, a deployment template that applies the right RBAC. The golden path is meant to encode best practices. But it also encodes trust: developers assume that if something came from the platform, it is secure by design.

An attacker who can modify a scaffolder template or a pipeline template can inject malicious steps that affect every service created or deployed using that template. Unlike a supply chain attack against a single package, a compromised platform template propagates to every new service that uses it — potentially hundreds of services across the organisation. The malicious step looks like legitimate platform tooling because it is in the platform.

Secrets in Scaffolding Templates

Scaffolding templates frequently need to include configuration that references secrets — API endpoints, default environment variable names, vault paths. The line between referencing a secret and embedding a secret is easy to cross accidentally. Platform teams under time pressure commit template files that contain actual credentials rather than placeholders, and those templates end up in version control repositories that are accessible to the entire engineering organisation.

A subtler problem is default values. A template that sets DATABASE_URL=postgres://admin:changeme@db:5432/app as a default value in a configuration file will propagate that default to every service scaffolded from it. Developers who do not change the default — and many do not in development environments that later get promoted to production — create a uniform credential across hundreds of services that is effectively public knowledge within the organisation.

Securing the Platform

1. Treat the IDP as a high-value target: Threat-model your IDP with the same rigour you apply to payment systems. Map every credential it holds, every system it can modify, and every action it can take. Produce a blast-radius diagram and review it with your security team quarterly.
2. Scope platform service accounts to minimum viable permissions: Audit every permission your Backstage GitHub App, CI service account, and cloud provisioner role holds. Remove permissions that are not actively used. Prefer separate service accounts for separate functions rather than one omnipotent account.
3. Pin and audit plugin versions: Lock every Backstage plugin to a specific version in your package.json. Run SCA scanning against the Backstage dependency tree on every update. Review the changelog and maintainer history before upgrading plugins that have broad backend access.
4. Require signed commits for template changes: Apply branch protection and required review to any repository containing scaffolder templates, pipeline templates, or platform configuration. Changes to the golden path should require security team sign-off in addition to platform team review.
5. Scan scaffolding templates for secrets and insecure defaults: Include template directories in your secrets scanning pipeline. Flag any default values that look like credentials, tokens, or sensitive endpoints. Enforce placeholder patterns for values that must be replaced before deployment.
6. Audit platform action logs continuously: Every template instantiation, every pipeline trigger, and every secrets access made by the IDP should produce an audit log entry. Alert on actions that deviate from the normal pattern — template modifications outside business hours, scaffolding from unusual network origins, or bulk service provisioning.
7. Isolate plugin execution where possible: For plugins that do not need backend access, configure them to run as frontend-only plugins. For plugins with backend components, consider running them in separate processes with limited access to the main Backstage configuration.